On 31-mei-2006, at 9:00, Josiah Carlson wrote: > > Ronald Oussoren <[EMAIL PROTECTED]> 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 > _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com