A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-June/079978.html below:

[Python-Dev] PEP 371 Discussion (pyProcessing Module)

[Python-Dev] PEP 371 Discussion (pyProcessing Module) [Python-Dev] PEP 371 Discussion (pyProcessing Module)Nick Coghlan ncoghlan at gmail.com
Mon Jun 2 11:12:17 CEST 2008
skip at pobox.com wrote:
>     Nick> We fixed the module names that used mixed case - the amount of
>     Nick> work that turned out to be involved in just doing that much for
>     Nick> PEP 3108 makes me shudder at the thought of trying to fix all of
>     Nick> the standard library APIs that currently don't follow the style
>     Nick> guide...
> 
> 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.)

Updating application code to deal with a module name change is easy - 
just use an "import x as y" statement. Catching the ImportError for the 
3.0 name and falling back to the 2.6 name (or vice-versa) even makes it 
possible to support both names fairly easily.

Changing the names of actual objects within the modules is tougher 
though - there are many more ways to access those.

Cheers,
Nick

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4