What stays the same? What changes?
The patterns are the same. The language techniques change.
Are there guiding principles like SOLID,
Yes. Indeed, they remain the guiding principles. Nothing changes.
or canonical patterns (perhaps entirely new ones) that a dynamic language newbie should know?
Some things are unique. Mostly the impact is that the implementation techniques change.
A pattern is -- well -- a pattern. Not a law. Not a subroutine. Not a macro. It's just a good idea that gets repeated because it's a good idea.
Good ideas don't go out of style or change dramatically.
Other notes. Python is not "weakly typed". It's more strongly-typed than Java or C++ because there's no cast operation. [Yes, there is a way to fudge the class associated with an object, but it's not the kind of thing that's done except to prove a fussy, legalistic point.]
Also. Most design patterns are based on different ways to exploit polymorphism.
Look at State or Command or Memento as examples. They have class hierarchies to create a polymorphic states, commands or mementos of state changes. Nothing changes significantly when you do this in Python. Minor changes include the relaxation of the precise class hierarchy because polymorphism in Python depends on common methods not common ancestors.
Also, some patterns are simply an attempt to achieve late binding. Most Factory-related patterns are an attempt to allow easy change to a class hierarchy without recompiling every C++ module in the application. This isn't as interesting optimization in a dynamic language. However, a Factory as a way to conceal implementation details still has huge value.
Some patterns are an attempt to drive the compiler and linker. Singleton, for example, exists to create confusing globals but at least encapsulate them. Python singleton classes aren't a pleasant prospect. But Python modules already are singletons, so many of us just use a module and avoid trying to mess with a Singleton class.
No, they aren't the same.
Patterns are common solutions to object-oriented programming problems. (I'm not aware of any similar books for functional or declarative programming.) The idea was crystallized in the famous "Design Patterns" book by the Gang of Four in 1995.
As Andre points out, patterns are common in every paradigm. I'll reiterate my previous statement: I'm not aware of any similar books for functional or declarative programming, but Andre has remedied my ignorance with the link he provided below. (Thank you, Andre.)
Principles are less about particular languages or paradigms, more general. "Don't Repeat Yourself" - DRY principle - is true for all programming.
Best Answer
One of the most popular design pattern among the community here is the strategy pattern. And yes, if you build some example code around this pattern, you can demonstrate all the SOLID principles:
Note that the pattern itself does not guarantee your code to be SOLID, it is more that the SOLID principles help you to implement the pattern correctly. You may consider to show your students not only correct examples for applying the SOLID principles, but also counter-examples in context of a strategy pattern, showing code which breaks each of the five principles. Or even better: make this an exercise for them.