It seems like many OO discussions use Java or C# as examples (e.g. Head First Design Patterns).
Do these patterns apply equally to Python? Or if I follow the design patterns, will I just end up writing Java in Python (which apparently is a very bad thing)?
The biggest differences are that Python is duck typed, meaning that you won't need to plan out class hierarchies in as much detail as in Java, and has first class functions. The strategy pattern, for example, becomes much simpler and more obvious when you can just pass a function in, rather than having to make interfaces, etc. just to simulate higher order functions. More generally, Python has syntactic sugar for a lot of common design patterns, such as the iterator and the aforementioned strategy. It might be useful to understand these patterns (I've read Head First and found it pretty useful), but think about Pythonic ways to implement them rather than just doing things the same way you would in Java.
Python has it's own design idioms. Some of the standard patterns apply, others don't. Something like strategy or factories have in-language support that make them transparent.
For instance, with first-class types anything can be a factory. There's no need for a factory type, you can use the class directly to construct any object you want.
Basically, Python has its own design idioms that are somewhat different largely because it's so dynamic and has incredible introspection capabilities.
Example:
x = list
my_list = x(range(0,5)) #creates a new list by invoking list's constructor
By assigning the class-type to a callable object you can essentially remove any 'factory' types in your code. You are only left with callables that produce objects that should conform to some given conventions.
Furthermore, there are design patterns in Python that just can't be represented in other statically-typed languages efficiently. Metaclasses and function decorators are good examples of this.
It depends on the pattern. Some things are difficult to do in Python: Singleton is an example. You replace this pattern with another, such as, in the case of Singleton, Borg.
It's not insane to use design patterns in Python-- the Iterator pattern, for instance, is integrated into the syntax. However, many things simply aren't done as OO- or pattern-heavy stuff. Python is made to be procedural or functional when it best suits the task, and OO too.
Overall, I'd just say to use your best judgment. If it seems like using Design Pattern Alpha-Gamma is overkill and overcomplication, then it probably is. If it seems like the pattern is perfect for what you want, it probably is.
Design patterns are little more than duct-tape to fix a languages deficiencies.
Short answer: Yes; Python is an OO language.
Slightly longer answer: Yes; you can design using OO principles and then implement in any language (even assembler).
The benefit of using an OO language is that it incorporates support for many common OO concepts, so you don't risk unnecessary bugs having to simulate them by convention. Of course there will always be language-specific details with greater or lesser applicability; you asked about "design principles", which should be expressed above that level of detail.
Long, verbose, boring answer: (The development of programming languages isn't a simple linear progression, but let me oversimplify and ignore that fact to make an observation that spans about 40 years' of programming experience.)
There's always going to be a role for language features vs. design principles and patterns. At every stage, attentive practitioners have noticed:
"Here's a problem we keep solving by hand in our current language(s)."
"Here's a bug we keep writing in our current language(s)."
"Here are some good practices we keep observing in our best programs."
And so the next generation of language(s) tend provide support for observed good behavior, tend to incorporate concepts so they don't have to be done by convention/agreement (or accidentally broken by the same), and enforce practices that prevent easily avoidable errors.
Regardless of how sophisticated, specialized, or generalized our tools, there are always programmers who "just turn the crank" and others who keep looking watching for how the "best and brightest" (in the mind of the beholder) use the tools. They then describe and promote those practices. Correctly defined (and whether called "style", "guidelines", "patterns", "principles", etc.), those practices end up forming "the next level" that we're always trying to reach, regardless of where we are currently standing.
On further thought, some patterns, such as Borg, may be more specific to Python (though similar things can be said about other patterns and languages).
The iterator pattern is also used in Python, albeit in a slightly different form.
Duncan Booth has written an article on patterns in python.
I'd say they apply to Python once you're already doing object-oriented programming with Python. Keep in mind that Python can do a lot more than OOP, and you should use common sense in choosing the appropriate paradigm for the job. If you decide that your program is best represented as a collection of objects, then sure, go ahead and use the design patterns, but don't be afraid to do something completely different if it's called for.
yes, of course they apply. But as noted above, many patterns are built into the language, or made irrelevant by higher level features of the language.
The use of Java or C# is probably due to the mainstream popularity of the language.
But design principle and/or design patterns apply irrespective of the language you use. The implementation of the same design pattern in Python would obviously be different than in Java or C#.
Yes, you can use plenty of design patterns in Python. A design pattern is just a repeatable implementation of a higher level task. The reason why Python & design patterns don't work the same as other languages is because Python includes most of the basic patterns built in. This means that patterns that emerge in Python are likely to be higher level design patterns instead of the menial tasks for which patterns are usually needed.
