[Python-3000] stdlib reorganization

[Ronald Oussoren]

On 31-mei-2006, at 9:00, Josiah Carlson wrote:

>
> Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>>
>>
>> On 30-mei-2006, at 19:49, Josiah Carlson wrote:
>>> Though I'm probably a bit strange in that I almost want a top level
>>> "py"
>>> package, and a separating of site-packages from the sys.path and
>>> into a
>>> top level package named "site".
>>>
>>> The former would make clear that you expect the module to be in the
>>> standard library, and the latter would make clear that you want a
>>> site-packages-specific module/package.
>>
>> I can understand the wish for a toplevel package that contains the
>> stdlib, although I don't think I agree with that. Stuffing site-
>> packages in another toplevel package seems wrong to me. If I
>> understand you correctly I'd have to do 'import site.wx' to import
>> wxPython and that doesn't feel right.
>
> I believe people would tend to use 'from site import wx', because  
> using
> 'wx.Frame' is much preferrable to 'site.wx.Frame'.
>
> Do you disagree with the desire to make Python all in 'py' in addition
> to site-packages as 'site'?
>
> Note that by having top level 'py' and 'site' packages, the  
> sys.modules
> naming of subpackages and modules necessarily get a 'py.' or 'site.'
> prefix, which I believe would reduce the amount of name intersections
> with user code.

I'm definitely opposed to having a toplevel package "site" that  
contains what's currently in site-packages. My first reaction to this  
was that 3th-party packages get stuffed into a ghetto. A method to  
selectively add packages to sys.path, such as the multi-version- 
install feature of setuptools, would be a much better solution than  
that. This would allow scripts to control which 3th-party code it  
wants to use.

I'm not sure about the toplevel package "py". I usually pick toplevel  
package name for applications to keep them nicely selfcontained. That  
combined with requiring full package names in import statements seems  
to take away the need for a toplevel package for the standard library.

>
> There was also a proposal that I was supposed to work on getting
> formalized somewhat over a year ago about getting __main__ relative
> imports to have __main__.XXX names, which would further reduce (if not
> remove entirely) name collisions in sys.modules, but I got caught  
> up in
> my attempt at a relative import hook.

That would really suck.

Ronald

>
>  - Josiah
>