by Alan Franzoni for
Find the video for this talk here
Python is quite a powerful language; sometimes, it’s a too much powerful language.
Very often, little scaffolding is provided, and many choices are left to the programmer even when there’s no need to; while an expert programmer will probably know how to handle things, possibly because of past trial and errors, novice programmers may just go stray with strange implementations, and Python newbies coming from other languages will just try mimicking such languages’ approach.
Other people may just crawl mailing lists looking for answers or ask their about their own doubt, but quite often there’s no clear answer even on focused questions, because details are left to the programmer “by design”.
What happens after a while is that, as soon as the lone programmer goes into a wider team or shares his work with the world, friction begins; different practices, albeit common-sense driven, often lead to issues and incompatibilities.
Or maybe that a programmer who has grown in experience finds his own previous ideas terrible and error-prone, and yet hard to fix once a lot of code is already in place.
In this talk I introduce a set of issues I experiences and that I still see many experience, along with a proposed solution, ranging from architecture, to packaging, to everyday programming.
Please note I don’t try to estabilish best practices when I don’t think there’s a clear one: I just aim for a good solution, which somebody may not agree with.
