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.
For my money, I think everyone's missing the point of design patterns. It's rare that I sit wondering which pattern I should use in a given situation. Also, I was using most of those patterns long before I knew they had names.
The power of design patterns is in communication. It is much quicker for me to say "use a Strategy for that" than to describe in detail what I am suggesting. It is much easier for us to debate the benefits of fat domain models vs. transaction scripts if we all know what those two terms mean. And so on.
And most powerfully of all, if I have named a class FooBuilder then you know that I'm using the Builder pattern to generate my Foo.
Even if you don't know what I'm talking about when I say "Observer pattern is ideal for that," you will be able to go off and google it pretty easily.
In that sense, the power of design patterns will never fade.
Best Answer
Peter Norvig demonstrates that 16 out of the 23 design patterns found in the GOF book are invisible or simpler in dynamic languages (he focuses on Lisp and Dylan).
Since you mentioned Python, there is a nice presentation by Alex Martelli about the topic. Also related with Python, there is a nice blog post demonstrating six design patterns in idiomatic Python.
I also keep a github repository with implementations (by other people) of the most common design patterns in Python.