Friday, April 16, 2004
How to write large-scale applications with Python
I was hoping this talk was going to explain how to go about managing a code base of hundreds / thousands of modules in python highlighting strategies and gotchas particular to the Python language. However this was not to be. Instead it was a general talk about how to structure an application (sub components etc) and about general design patterns to use.
I'm get the impression from both this talk ("in python we don't use patterns") and others that most python projects / developers (who have come to python directly) ignore the body of design knowledge that other languages have built up. Python certainly makes it easy to get around the strict pattern-influenced interfaces, but essentially it's the same thing, not recognising this means the vocabulary is denied (which is largely the purpose of patterns).
ah - last 5 mins the goods:
And then...
I was hoping this talk was going to explain how to go about managing a code base of hundreds / thousands of modules in python highlighting strategies and gotchas particular to the Python language. However this was not to be. Instead it was a general talk about how to structure an application (sub components etc) and about general design patterns to use.
I'm get the impression from both this talk ("in python we don't use patterns") and others that most python projects / developers (who have come to python directly) ignore the body of design knowledge that other languages have built up. Python certainly makes it easy to get around the strict pattern-influenced interfaces, but essentially it's the same thing, not recognising this means the vocabulary is denied (which is largely the purpose of patterns).
ah - last 5 mins the goods:
- keep import deps low -- avoid from .. import *
- use absolute import paths (ie full namespace) -- unpickling is a particular gotcha with relative package paths
- use python pacakges
- import loops can be nasty
And then...
- use data objects for data encapsulation rather than simple types tuples/lists/dictionaries etc
- use methods for simple tasks
- use method groups for more complex ones
- use mix-in classes if method groups can be deployed in more than one class context
- use PyChecker to find hidden typos and possible bugs