>> If the 3.0 API of a module is going to involve breakage which
>> requires authors to update their applications wouldn't this be a good
>> time to PEP-8-ify the module? (Not suggesting that threading would
>> fall into this category.)
Nick> Updating application code to deal with a module name change is
Nick> easy - just use an "import x as y" statement. Catching the
Nick> ImportError for the 3.0 name and falling back to the 2.6 name (or
Nick> vice-versa) even makes it possible to support both names fairly
Nick> easily.
Nick> Changing the names of actual objects within the modules is tougher
Nick> though - there are many more ways to access those.
I think you misunderstood what I wrote. Suppose you decided that the API
for the threading modules needs significant rework, changes which will break
much, if not all current usage. I'm only suggesting that if you decide the
API change is worthwhile that you take the opportunity to make the class,
method and data names PEP8-compliant. I'm not talking about gratuitous
change to the identifier names, but situations where the user is going to
have to rework their code anyway.
Skip
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
