[Python-Dev] PEP 371 Discussion (pyProcessing Module) (original) (raw)
skip at pobox.com skip at pobox.com
Mon Jun 2 14:09:14 CEST 2008
- Previous message: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
- Next message: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>> 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
- Previous message: [Python-Dev] PEP 371 Discussion (pyProcessing Module)
- Next message: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]