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/2005-June/054113.html below:

[Python-Dev] Thoughts on stdlib evolvement

[Python-Dev] Thoughts on stdlib evolvement [Python-Dev] Thoughts on stdlib evolvementReinhold Birkenfeld reinhold-birkenfeld-nospam at wolke7.net
Tue Jun 7 19:40:40 CEST 2005
Fernando Perez wrote:
> Skip Montanaro wrote:
> 
>> I wouldn't mind a stdlib that defined a set of top-level packages (some of
>> which might be wholly unpopulated by modules in the standard distribution)
>> It might, for example, define a gui package and gui.Tkinter and gui._tkinter
>> modules, leaving the remainder of gui namespace available for 3rd party
>> modules.  Such a scheme would probably work best if there was some fairly
>> lightweight registration/approval process in the community to avoid needless
>> collisions.  For example, it might be a bit confusing if two organizations
>> began installing their packages in a subpackage named gui.widgets.  An
>> unsuspecting person downloading an application that used one version of
>> gui.widgets into environment with the conflicting gui.widgets would run into
>> trouble.
> 
> I've wondered if it wouldn't be better if the std lib were all stuffed into its
> own namespace:
> 
> from std import urllib
> 
> If a more structured approach is desired, it could be 
> 
> from std.www import urllib

One may want to look at the "py.std" approach of "the py lib", found at
http://codespeak.net/py/current/doc/misc.html#the-py-std-hook

Reinhold

-- 
Mail address is perfectly valid!

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