Thursday, 17 July 2008

python-dev: unittest changes and language changes

When new releases of Python are being developed, I start browsing the python-dev mailing list in order to keep up to date on when the alpha versions, beta versions, release candidates and final versions will be released. I do this in order to try and synchronise releases of Stackless Python, as it helps me (and hopefully others) feel like it is a relevant and current project. Maintaining its currentness has been my primary driving force in spending the time I have maintaining the project itself.

However, in browsing python-dev I find myself actually reading all the posts, and I find this rather disappointing. Features are proposed and seem to get accepted and integrated arbitrarily - at least in my opinion. I don't want that statement to get conflated with a dissatisfaction with the Stackless Python features never having gotten into the Python language, that is not an interest of mine. In any case, I feel that the Python language is drifting away from what I originally liked about it, especially in terms of approachability and readability.

One particular aspect which is being discussed at the moment is revising the unittest module for a later release of Python 3000. Modifying all the assertion method names away from camel case to suit the style guideline PEP. Going with the assert* naming and dropping the fail* naming. And more.

Personally find the fail* naming easiest to interpret and tend to just use the failUnless method for most of my unit tests. The feeling I get from the mailing list is that there is a desire to make everyone use the assert* methods, so that those who prefer them can have any test they encounter fit their preference given that the other approach is redundant.

I hope that the fail* aliases make it in - but I don't expect them to.

1 comment:

  1. Features are not added arbitrarily. But some don't make it because the person proposing it just doesn't stick with it. Python-dev is a tough crowd to please.

    And you need to separate the language from the standard library in terms of barrier of entry. The language is something every Python programmer uses, but stuff in the stdlib is used only by a subset. Plus you don't expect every Python programmer to know everything about the stdlib compared to the language.