Pittsburgh Python: distribute and other Python community controversies
I was very interested to attend this month’s Pittsburgh Python User Group meeting because Nick Sloan was going to give a talk about packaging with
distribute: packaging in Python has been a huge source of confusion to me, both as a user and as a developer.
Since my use of Python at work or for personal purposes has not been very large scale, I have limped along with settling on a clean setup to use for packaging my code. This is in stark contrast to my management of libraries in Perl, Ruby, and Java, where I think there has been more of a consensus in adoption of certain tools and conventions.
Also, Joe Esposito sent around some links to interesting discussions and news in the global Python community, so I looked forward to hearing what everyone thought.
The problem with Python packaging
OK, so the big problem I faced when trying to nicely set up packaging for a personal project a while ago was that there are many options. The paradox of choice is insidious, and it is surprising to me in the Python community, which has generally prided itself on a general consensus on a philosophy of “There’s Only One Way To Do It”, in sharp and deliberate contrast to the Perl community’s philosophy of “There’s More Than One Way To Do It” (TIMTOWTDI).
Nick Sloan on packaging with
Nick summarized the situation of existing packaging systems for Python:
distutilsis lacking in features
distributeis a fork of
setuptoolsand aims to replace it
He then illustrated the basics of packaging with writing
setup.py, referencing Kenneth Reitz’s recommendations on repository structure, based on
Kenneth Reitz’s recommendations on repository structure
The most interesting thing about Kenneth Reitz’s recommendations was that he advocated separating out tests from the code of a module, to reduce dependencies for the installer and user of the module. I definitely prefer to have a separate directory tree for tests, as is standard by convention when I write tests for projects in many other languages. For example:
spec/when using RSpec
src/test/when using JUnit
src/test/when using Specs2 and ScalaCheck
I don’t really like his
tests/context.py system of imports, as it is too dynamic in chasing down imports, and therefore may not play well by default with standard tools:
import os import sys sys.path.insert(0, os.path.abspath(..)) import sample
from .context import sample
That said, I decided to give his recommendations a shot.
Meanwhile, Nick noted that there is also a
distutils2 project now, to improve
distutils, and that nobody is working on
distribute any more. This sounds like a crazy soap opera in the Python world.
Python community debates and news
Joe opened up the discussion on Python community news.
“Start Writing More Classes”?
In the Python community, there has always been some controversy over whether to go all-out object-oriented with classes or write in a more functional style. The language supports both styles, although classes were a fairly late addition to the language.
“Stop Writing Classes”?
Last year, at PyCon 2012, there was a talk, “Stop Writing Classes”, that made waves:
I thought it was a good talk, because it exposed how many things done with classes are superfluous, creating code bloat and deeply nested hierarchies: often you can just use a functional style with data that is not all wrapped into classes.
Just two weeks ago, someone wrote a post on how Python programmers should be writing more classes, not less.
I was not happy about this post because it set up a straw man. Really, he was simply arguing for modular code vs. monolithic code, and observing that some people who don’t use classes end up writing monolithic code. He even states as much at the end of his post. So the title of his post is misleading.
There were various other smaller topics discussed, but
distribute and classes dominated this evening.
(Updates after the meetup)
After I went home, I updated one of my sample Python projects to adhere to Kenneth Reitz’s guidelines.
Also, some weeks later, I noticed an announcement that
distribute were going to merge efforts. Hooray!