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.