[Oops, replied privately again. Resending to list.]
On Tue, Jul 22, 2008 at 8:14 PM, David Goodger <goodger@...> wrote:
> On Tue, Jul 22, 2008 at 10:01, Alan G Isaac <aisaac@...> wrote:
>> - import ``configparser as ConfigParser`` if cannot import ``ConfigParser
> Because the module name was changed?
This is moot because I assume 2to3 does (or else *should*) handle
renamed std modules. But I want to comment anyway because it's a
good example of the pythonic approach to language rot:
Don't add workarounds for new versions -- rewrite for the newest
version (and add workarounds for old versions)!
In this case, it'd be better to ``import ConfigParser as
configparser`` if cannot ``import configparser`` (and change all code
to refer to ``configparser``).
1. Early adoption of language changes gives your code more
time until language rot breaks it again. Allowing this is why
Python PEPs always allow new coding styles (through
__future__ if needed) before they deprecate old styles!
2. Some day you'll have to rewrite anyway. If you don't do it
now, your workarounds will begin to pile one upon the other.
Like dirty socks.
3. Newer Python coding styles are always more pythonic than
old ones _, so this way your code looks better _.
..  by definition of Pythonic == current Python style
..  by definition of Pythonic == looks good ;-)
Of course if you need really a lot of re-writing, as in the 2.x->3.0
transition, a 2to3 tool is better than manual re-writing. And given
an automatic tool the only works in the forward direction, it's better
to keep old code until you switch.