Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Steve Holden [EMAIL PROTECTED] wrote: The idea that users would /program their own computers/ was totally alien to the Windows mindset. Actually, the alien idea is that more than one person would use the same (Windows) computer. Not surprising as these were *personal* computers. It's Windows as a server OS that's the bizarre idea... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Reed O'Brien wrote: On Jan 9, 2008, at 1:48 AM, Jeroen Ruigrok van der Werven wrote: -On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote: Python's _winreg module and pywin32 expose several functions to get the paths from the registry but I don't think it has a simple function like get_mydocuments(). Careful with the name though. Microsoft Windows Vista did away with 'My Documents Settings'. It is now C:\Users. So you get: C:\Users\name\AppData\Local\ (former Local Settings\Application Data) C:\Users\name\AppData\Roaming\ (former Application Data) C:\Users\name\Documents(former My Documents) C:\Users\name\Music(former My Music) C:\Users\name\Pictures (former My Pictures) C:\Users\name\Videos (former My Videos) yay, next up posix support I suspect that the whole thing was done to make sure that developers of applications could: A: cope with stupidly long path names. V: cope with spaces in path names. I bet they never intended to keep the huge names, just to make you cope with them. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Jeroen Ruigrok van der Werven wrote: -On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote: Python's _winreg module and pywin32 expose several functions to get the paths from the registry but I don't think it has a simple function like get_mydocuments(). Careful with the name though. Microsoft Windows Vista did away with 'My Documents Settings'. It is now C:\Users. So you get: C:\Users\name\AppData\Local\(former Local Settings\Application Data) C:\Users\name\AppData\Roaming\ (former Application Data) C:\Users\name\Documents (former My Documents) C:\Users\name\Music (former My Music) C:\Users\name\Pictures (former My Pictures) C:\Users\name\Videos(former My Videos) Somewhat off topic, but hooray, it looks like someone at MS rediscovered the command line and why Long and Wordy Names with lots of spaces are really annoying. Easier access to the application data directory is a good thing too. I guess moving to Vista wouldn't be all bad then ;) To get marginally back on topic, I would actually prefer to have a function like os.gethomedir() that takes on optional user name. (I don't want it enough to write a patch to make it happen though) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Nick Coghlan wrote:
Jeroen Ruigrok van der Werven wrote:
-On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote:
Python's _winreg module and pywin32 expose several functions to get the
paths from the registry but I don't think it has a simple function like
get_mydocuments().
Careful with the name though. Microsoft Windows Vista did away with 'My
Documents Settings'. It is now C:\Users.
So you get:
C:\Users\name\AppData\Local\(former Local Settings\Application Data)
C:\Users\name\AppData\Roaming\ (former Application Data)
C:\Users\name\Documents (former My Documents)
C:\Users\name\Music (former My Music)
C:\Users\name\Pictures (former My Pictures)
C:\Users\name\Videos(former My Videos)
Note today's Coding Horror blog entry: Don't Pollute User Space
http://www.codinghorror.com/blog/archives/001032.html
Keep your dirty, filthy paws out of my personal user space!
Take a look in your Documents folder right now. Go ahead. Look. Do you
see any files or folders in there that you personally did not create? If
so, you've been victimized. Applications should never create or modify
anything in your documents folder without your permission.
{snip...]
If applications need to store shared files, that's what the \AppData and
\Application Data folders are for.
Sentiments I agree with...
Michael
http://www.manning.com/foord
Somewhat off topic, but hooray, it looks like someone at MS rediscovered
the command line and why Long and Wordy Names with lots of spaces are
really annoying. Easier access to the application data directory is a
good thing too.
I guess moving to Vista wouldn't be all bad then ;)
To get marginally back on topic, I would actually prefer to have a
function like os.gethomedir() that takes on optional user name. (I don't
want it enough to write a patch to make it happen though)
Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Michael Foord [EMAIL PROTECTED] wrote: Note today's Coding Horror blog entry: Don't Pollute User Space http://www.codinghorror.com/blog/archives/001032.html Keep your dirty, filthy paws out of my personal user space! :-) Absolutely [...] If applications need to store shared files, that's what the \AppData and \Application Data folders are for. Sentiments I agree with... Yes, with the one proviso that Windows (XP, at least, maybe Vista is actually better in this regard) makes it extremely difficult for the user to manually do anything in these directories, so that I'd say this is only appropriate for fully application-maintained files. As far as I know, Windows lacks any really sensible place to store application configuration data which is meant to be user edited on occasion (e.g. rc/ini files, startup scripts, etc). That's often what I see ending up in %USERPROFILE% - even though as Christian points out, it's officially wrong. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 9, 2008, at 1:48 AM, Jeroen Ruigrok van der Werven wrote: -On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote: Python's _winreg module and pywin32 expose several functions to get the paths from the registry but I don't think it has a simple function like get_mydocuments(). Careful with the name though. Microsoft Windows Vista did away with 'My Documents Settings'. It is now C:\Users. So you get: C:\Users\name\AppData\Local\(former Local Settings \Application Data) C:\Users\name\AppData\Roaming\ (former Application Data) C:\Users\name\Documents (former My Documents) C:\Users\name\Music (former My Music) C:\Users\name\Pictures (former My Pictures) C:\Users\name\Videos(former My Videos) yay, next up posix support *dreams* ~ro -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Vae victis! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/reed% 40reedobrien.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: On 09/01/2008, Michael Foord [EMAIL PROTECTED] wrote: Note today's Coding Horror blog entry: Don't Pollute User Space http://www.codinghorror.com/blog/archives/001032.html Keep your dirty, filthy paws out of my personal user space! :-) Absolutely [...] If applications need to store shared files, that's what the \AppData and \Application Data folders are for. Sentiments I agree with... Yes, with the one proviso that Windows (XP, at least, maybe Vista is actually better in this regard) makes it extremely difficult for the user to manually do anything in these directories, Only because Windows XP uses a stupidly long path with spaces in it. It's not actually *hard* to navigate manually to these directories. If the windows installers created by the 'bdist' commands allow you to automatically put stuff there then it shouldn't be too much of a problem. so that I'd say this is only appropriate for fully application-maintained files. As far as I know, Windows lacks any really sensible place to store application configuration data which is meant to be user edited on occasion (e.g. rc/ini files, startup scripts, etc). What user editing is *meant* to be done with extension modules installed into a site directory. Programmer editing maybe... :-) Michael Foord That's often what I see ending up in %USERPROFILE% - even though as Christian points out, it's officially wrong. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Michael Foord [EMAIL PROTECTED] wrote: Only because Windows XP uses a stupidly long path with spaces in it. It's not actually *hard* to navigate manually to these directories. The directories are also hidden. That does make it hard to navigate there. I know you can un-hide hidden files, but I view the hidden attribute as useful - just badly misused in this case, unless you assume that these directories are intended to be left alone by the user. What user editing is *meant* to be done with extension modules installed into a site directory. Programmer editing maybe... :-) Sorry, I had drifted slightly off topic here. I don't have a problem with user-specific extensions going in appdata, on the presumption that we're talking code only (and excluding something obscure like distutils' distutils.cfg file). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Jeroen Ruigrok van der Werven wrote: Careful with the name though. Microsoft Windows Vista did away with 'My Documents Settings'. It is now C:\Users. So you get: C:\Users\name\AppData\Local\(former Local Settings\Application Data) C:\Users\name\AppData\Roaming\ (former Application Data) C:\Users\name\Documents (former My Documents) C:\Users\name\Music (former My Music) C:\Users\name\Pictures (former My Pictures) C:\Users\name\Videos(former My Videos) My latest version uses the SHGetFolderPathW() function from ShlObj.h. It's the preferred way to get shell folder paths like CLSID_PERSONAL (my documents). It's compatible with 2000 and newer (maybe even older, but we don't support ME, NT4 or older) and works on Vista, too. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: The directories are also hidden. That does make it hard to navigate there. I know you can un-hide hidden files, but I view the hidden attribute as useful - just badly misused in this case, unless you assume that these directories are intended to be left alone by the user. It's not an issue for experienced users. For the rest we can put a link in the start menu under Python 2.5 which opens a new explorer with the user package directory. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Christian Heimes [EMAIL PROTECTED] wrote: It's not an issue for experienced users. For the rest we can put a link in the start menu under Python 2.5 which opens a new explorer with the user package directory. Um, I'm an experienced user and it's an issue for me... The problem isn't so much knowing where the directory is, as that tools (quite rightly) ignore (ie, hide!) hidden directories. For example, 4NT (my command shell) doesn't auto-complete hidden directory names by default, many tools' wildcard matching ignores them (always, not just by default). Blast, I said I wasn't going to start a big flamewar over Windows behaviour. I haven't seen anyone propose that something intended to be edited by a user be stored in a hidden directory (appdata) on Windows. As long as that is the case, I don't care. If you are suggesting that a file intended to be viewed/edited by a user manually should go in AppData, then please be explicit. We can then argue the concrete issues, rather than just theoretical principles. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: If you are suggesting that a file intended to be viewed/edited by a user manually should go in AppData, then please be explicit. We can then argue the concrete issues, rather than just theoretical principles. I'm frustrated as well. Neither AppData nor MyDocuments fulfill our requirements. I don't argue for AppData, I only argue against UserProfile as the base directory for a user package directory. I'm open for any suggestion which doesn't violate MS' style guides. (I don't want to imply that I like the style guide but we don't make the rules :( ) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 09/01/2008, Christian Heimes [EMAIL PROTECTED] wrote: Paul Moore wrote: If you are suggesting that a file intended to be viewed/edited by a user manually should go in AppData, then please be explicit. We can then argue the concrete issues, rather than just theoretical principles. I'm frustrated as well. Neither AppData nor MyDocuments fulfill our requirements. For what? If you're talking about a per-user site-packages directory, I have no problem with AppData (as Michael said, there's no intention that users be able to edit the files). Of course, modules/packages/extensions don't really qualify as application *data*, so it is a somewhat odd usage certainly, but it's not disastrous. Windows doesn't really have a concept of a per-user application code directory. Come to that, if I use a bdist_wininst installer to install a package in my personal site packages, then I log off and you log on, would you expect to see my package when you look in add/remove programs? Would you expect to be able to uninstall it? Would you expect to be able to install a personal copy of your own? What would we see in add/remove programs *then*?? No matter how you cut it, Windows isn't designed for per-user installable programs. Maybe a per-user site-packages just isn't appropriate on Windows. Paul. PS This is mostly theoretical for me, as I don't have a personal need for a per-user site packages directory on any of the machines I use. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: [...] No matter how you cut it, Windows isn't designed for per-user installable programs. Maybe a per-user site-packages just isn't appropriate on Windows. This reminds me of the early days of Microsoft Terminal Service (read: X Window done wrong fifteen years later), when various applications had to be modified to stop saving per-user data in global locations. It underlines the fact that essentially Windows is still betrayed by its original conception as a single-user system. The idea that users would /program their own computers/ was totally alien to the Windows mindset. looking-at-Vista-and-thinking-very-hard-ly y'rs - steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 5:49 PM, Tristan Seligmann wrote: In that case how about: ~/.local/lib/pythonX.Y/site-packages or: ~/local/lib/pythonX.Y/site-packages I believe both of these locations are already in use by various systems / people, so it would fit in better with existing practice. I like the former path. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4VoJ3EjvBPtnXfVAQK9zQP/dup8RHQha0v9ZkYee+L5/8/fhvIHBEoP MGkBxZUv79SmtnY4WWovS66NYAuKHlChFN0VSZCUO8o7WE8b52lXhgeG2xGX/pU/ MZ6D6zjxZmFhQjLLNf5gRcvchYHM+18AYQFapnuCpV048cgmJ7DQcGqznpyYRhnm SvqTeBtstNw= =HYwR -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 08/01/2008, Christian Heimes [EMAIL PROTECTED] wrote: Paul Moore wrote: What would be used on Windows? It's likely to be of marginal use on Windows, but an appropriate equivalent should be defined. Possibly just replace ~ with %USERPROFILE%. I'd argue against anything under %APPDATA% as that directory is hidden. No, we shouldn't mess with the profile root directory on Windows. The data should either be installed under Application Data or under My Documents. You are right, the appdata directory is hidden by the installer could add a link to Application Data\Python\python2.x\ to the start menu. Not My Documents, please! That's for documents, not configuration. %USERPROFILE% is actually where most other applications put stuff. The alternative would be %HOMEDRIVE%%HOMEPATH% which is what os.path.expanduser uses. Apropos My Documents and other special directories on Windows. Python doesn't have an API to get the directories from the registry. Is somebody interested in having a module for the task? I've some code for the job on disk. It would probably be a good idea to have it in the core, although I'm sure it's in pywin32, and anyone coding Python on Windows will have that. Personally, I've no code that would benefit from this, so I'd be +0 on theoretical grounds only. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: Not My Documents, please! That's for documents, not configuration. %USERPROFILE% is actually where most other applications put stuff. The alternative would be %HOMEDRIVE%%HOMEPATH% which is what os.path.expanduser uses. On mys system only one application has put configuration data directly into USERPROFILE. It's Python's IDLE and I don't like it. It should store its configuration under APPDATA. I also don't agree that Python extensions are configuration data. They are code, maybe plugins and the files are user editable content. Ms products like Visual Studio store files like them in My Documents. It would probably be a good idea to have it in the core, although I'm sure it's in pywin32, and anyone coding Python on Windows will have that. Personally, I've no code that would benefit from this, so I'd be +0 on theoretical grounds only. Python's _winreg module and pywin32 expose several functions to get the paths from the registry but I don't think it has a simple function like get_mydocuments(). Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: Not My Documents, please! That's for documents, not configuration. %USERPROFILE% is actually where most other applications put stuff. The alternative would be %HOMEDRIVE%%HOMEPATH% which is what os.path.expanduser uses. http://msdn2.microsoft.com/en-us/library/bb762494(VS.85).aspx CSIDL_PROFILE (FOLDERID_Profile) Version 5.0. The user's profile folder. A typical path is C:\Documents and Settings\username. Applications should not create files or folders at this level; they should put their data under the locations referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-On [20080108 17:07], Christian Heimes ([EMAIL PROTECTED]) wrote: Python's _winreg module and pywin32 expose several functions to get the paths from the registry but I don't think it has a simple function like get_mydocuments(). Careful with the name though. Microsoft Windows Vista did away with 'My Documents Settings'. It is now C:\Users. So you get: C:\Users\name\AppData\Local\(former Local Settings\Application Data) C:\Users\name\AppData\Roaming\ (former Application Data) C:\Users\name\Documents (former My Documents) C:\Users\name\Music (former My Music) C:\Users\name\Pictures (former My Pictures) C:\Users\name\Videos(former My Videos) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Vae victis! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Sun, Jan 06, 2008 at 04:23:59PM -0800, Guido van Rossum wrote: I don't want py or python to be part of the stdlib package namespace. *If* (part of) the stdlib has to live under a single distinguished name, pick something like std or core. When I'm using Python I already know I'm using Python, I don't want to be reminded of that fact on every import line. When I'm using Jython - am I using Python of Java? After from java.lang import Class should it be from py import exceptions or from core import exceptions ? Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 2008-01-07 14:57, Fred Drake wrote: On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote: Next, we add a per-user site-packages directory to the standard sys.path, and then we could get rid of most of the setuptools import and sys.path hackery, making it a lot cleaner. PYTHONPATH already provides this functionality. I see no need to duplicate that. Agreed, but one of the main arguments for all the .pth file hackery in setuptools is that having to change PYTHONPATH in order to enable user installations of packages is too hard for the typical user. We could easily resolve that issue, if we add a per-user site-packages dir to sys.path in site.py (this is already done for Macs). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 07 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote: Next, we add a per-user site-packages directory to the standard sys.path, and then we could get rid of most of the setuptools import and sys.path hackery, making it a lot cleaner. PYTHONPATH already provides this functionality. I see no need to duplicate that. -Fred -- Fred Drake fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: We could easily resolve that issue, if we add a per-user site-packages dir to sys.path in site.py (this is already done for Macs). +1. I've advocated that for years. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4I4EHEjvBPtnXfVAQLpPwQAizIj/FBCc9tTNVoPRTghv37WVL0wAk8Z WtmDVpag8H/j7uNKKwMd7Ld0HdVMAwpDetdGPklDnhMDqD/jY5Da2551uKgawFnZ 57WfY5C/VvYbI8jofDEJxb2bEJyG2QILnqut+D8/9zU+z/G1ubL+jgTY03F7a71O JQAaGa6DxNU= =S5C/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote: On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: We could easily resolve that issue, if we add a per-user site-packages dir to sys.path in site.py (this is already done for Macs). +1. I've advocated that for years. I'm not sure what this buys given that you can do this using PYTHONPATH anyway, but because of that I also can't be against it. +0 from me. Patches for 2.6 gratefully accepted. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote: On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote: On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: We could easily resolve that issue, if we add a per-user site- packages dir to sys.path in site.py (this is already done for Macs). +1. I've advocated that for years. I'm not sure what this buys given that you can do this using PYTHONPATH anyway, but because of that I also can't be against it. +0 from me. Patches for 2.6 gratefully accepted. I think it's PEP-worthy too, just so that the semantics get nailed down. Here's a strawman proto-quasi-pre-PEP. Python automatically adds ~/.python/site-packages to sys.path; this is added /before/ the system site-packages file. An open question is whether it needs to go at the front of the list. It should definitely be searched before the system site-packages. Python treats ~/.python/site-packages the same as the system site- packages, w.r.t. .pth files, etc. Open question: should we add yet another environment variable to control this? It's pretty typical for apps to expose such a thing so that the base directory (e.g. ~/.python) can be moved. I think that's all that's needed. It would make playing with easy_install/setuptools nicer to have this. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4JSJ3EjvBPtnXfVAQIXfgP9HCi8PNwUbPTbeaf7JPHLTkguYwUAyLH2 vD31w76fnh3pChIZSY9CtP51qRmB22DChSQxaagLmnl9FXjdS1dmXOu7oT7lfj2z avTptyJ2MB8kFuGLK2In/mjbWxPUgAd19sbm4jtE5b3nauOBVyZh23TxFvH5uRdD bUaqRNib3vE= =P3p4 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 2008-01-07 17:24, Barry Warsaw wrote: On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote: On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote: On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: We could easily resolve that issue, if we add a per-user site-packages dir to sys.path in site.py (this is already done for Macs). +1. I've advocated that for years. I'm not sure what this buys given that you can do this using PYTHONPATH anyway, but because of that I also can't be against it. +0 from me. Patches for 2.6 gratefully accepted. I think it's PEP-worthy too, just so that the semantics get nailed down. Here's a strawman proto-quasi-pre-PEP. Python automatically adds ~/.python/site-packages to sys.path; this is added /before/ the system site-packages file. An open question is whether it needs to go at the front of the list. It should definitely be searched before the system site-packages. Python treats ~/.python/site-packages the same as the system site-packages, w.r.t. .pth files, etc. Open question: should we add yet another environment variable to control this? It's pretty typical for apps to expose such a thing so that the base directory (e.g. ~/.python) can be moved. I'd suggest to make the ~/.python part configurable by an env var, e.g. PYTHONRESOURCES. Perhaps we could use that directory for other Python-related resources as well, e.g. an optional sys.path lookup cache (pickled dictionary of known package/module file locations to reduces Python startup time). I think that's all that's needed. It would make playing with easy_install/setuptools nicer to have this. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 07 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 01:48 PM 1/7/2008 +0100, M.-A. Lemburg wrote: I also don't like the import mechanism hackery that's being used in setuptools to get namespace packages working. I believe you're mistaken: there is no import mechanism hackery in pkg_resources. (__path__ is a documented *hook*, not a hack, and it's the only import-related hook that pkg_resources uses). And, if you don't like namespace packages, perhaps you should be campaigning for this to be removed: http://python.org/doc/2.4.1/lib/module-pkgutil.html pkg_resources only updates the routine provided in pkgutil to be a bit more automatic, and to better support PEP 302 and zipfile importing. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 03:01 PM 1/7/2008 +0100, M.-A. Lemburg wrote: On 2008-01-07 14:57, Fred Drake wrote: On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote: Next, we add a per-user site-packages directory to the standard sys.path, and then we could get rid of most of the setuptools import and sys.path hackery, making it a lot cleaner. PYTHONPATH already provides this functionality. I see no need to duplicate that. Agreed, but one of the main arguments for all the .pth file hackery in setuptools is that having to change PYTHONPATH in order to enable user installations of packages is too hard for the typical user. We could easily resolve that issue, if we add a per-user site-packages dir to sys.path in site.py (this is already done for Macs). Actually, neither PYTHONPATH nor your proposal solve all of the problems that .pth files do. To date, nobody has proposed any real substitute for them. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 11:24 AM 1/7/2008 -0500, Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote: On Jan 7, 2008 6:32 AM, Barry Warsaw [EMAIL PROTECTED] wrote: On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: We could easily resolve that issue, if we add a per-user site- packages dir to sys.path in site.py (this is already done for Macs). +1. I've advocated that for years. I'm not sure what this buys given that you can do this using PYTHONPATH anyway, but because of that I also can't be against it. +0 from me. Patches for 2.6 gratefully accepted. I think it's PEP-worthy too, just so that the semantics get nailed down. Here's a strawman proto-quasi-pre-PEP. Python automatically adds ~/.python/site-packages to sys.path; this is added /before/ the system site-packages file. An open question is whether it needs to go at the front of the list. It should definitely be searched before the system site-packages. What about including the Python version in the directory name? C Extensions may not work correctly across versions, and bytecode will get recompiled a lot if you're using multiple versions. Also, if this is a 2.6/3.0 change, it's likely that the *source* won't be compatible across versions either. :) Python treats ~/.python/site-packages the same as the system site- packages, w.r.t. .pth files, etc. Open question: should we add yet another environment variable to control this? It's pretty typical for apps to expose such a thing so that the base directory (e.g. ~/.python) can be moved. I think that's all that's needed. It would make playing with easy_install/setuptools nicer to have this. Assuming that this is a true site directory (i.e., .pth files are recognized), then yes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 12:19 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Jan 6, 2008 8:28 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Jan 6, 2008 7:23 PM, Phillip J. Eby [EMAIL PROTECTED] wrote: At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: Regarding using common words, either the stdlib grabs these, or *nobody* gets to use them (for fear of conflicting with some other 3rd party package grabbing the same). This isn't quite true; a standalone Python application that isn't extensible doesn't need to worry about this. And it's standalone apps that are most likely to claim these common words. (For example, until recently, Chandler's database library packages were in 'repository.*'.) But of course this is still a pretty minor point overall. If the stdlib does go for deeper nestings, I have a slight preference for seeing them under std.* or some such rather than top level. But I don't really see a whole lot of point to doing a major re-org of the stdlib space to begin with, for the simple reason that package names are not really categories -- they're *names*. IMO 'from databases import sqlite' doesn't add any value over 'import pysqlite3' to begin with. Worse, it will likely be an attractive nuisance for people saying why don't we have databases.Oracle? and suchlike. And you still have to remember the names, only now they're longer. And was it database or databases? Greater uniqueness of names is just another reason flat is better than nested. :) Right. Packages are useful if it helps make the sub-names shorter. The email package is a good example: it uses lots of generic names like errors, charset, encoders, message, parser, utils, iterators. So only do the 'databases' package if we can change the modules names to make it worth it? So whichdb becomes databases.which, dumbdbm becomes databases.dumb, etc.? Bad example IMO; these are all about relatively simple dict-on-disk APIs, not about (relational) databases. I'd be +0 things like dbm.gnu, dbm.any, dbm.dumb, dbm.which. And then extend this to any other package that we consider creating? Otherwise leave it out? How would that follow for sqlite since that is not going to get any shorter thanks to a package? Should it still go into the package for organizational purposes? If you're asking me, the organizational purpose is 100% misguided. In other words, should the stdlib reorg only introduce new packages if the majority of modules that go into the package end up with a shorter name? See what others say. Another reason to have a top-level package would be if there are a lot of subpackages/submodules. This applies to the xml package for example. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 12:40 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Jan 7, 2008 12:19 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Jan 6, 2008 8:28 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Jan 6, 2008 7:23 PM, Phillip J. Eby [EMAIL PROTECTED] wrote: At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: Regarding using common words, either the stdlib grabs these, or *nobody* gets to use them (for fear of conflicting with some other 3rd party package grabbing the same). This isn't quite true; a standalone Python application that isn't extensible doesn't need to worry about this. And it's standalone apps that are most likely to claim these common words. (For example, until recently, Chandler's database library packages were in 'repository.*'.) But of course this is still a pretty minor point overall. If the stdlib does go for deeper nestings, I have a slight preference for seeing them under std.* or some such rather than top level. But I don't really see a whole lot of point to doing a major re-org of the stdlib space to begin with, for the simple reason that package names are not really categories -- they're *names*. IMO 'from databases import sqlite' doesn't add any value over 'import pysqlite3' to begin with. Worse, it will likely be an attractive nuisance for people saying why don't we have databases.Oracle? and suchlike. And you still have to remember the names, only now they're longer. And was it database or databases? Greater uniqueness of names is just another reason flat is better than nested. :) Right. Packages are useful if it helps make the sub-names shorter. The email package is a good example: it uses lots of generic names like errors, charset, encoders, message, parser, utils, iterators. So only do the 'databases' package if we can change the modules names to make it worth it? So whichdb becomes databases.which, dumbdbm becomes databases.dumb, etc.? Bad example IMO; these are all about relatively simple dict-on-disk APIs, not about (relational) databases. I'd be +0 things like dbm.gnu, dbm.any, dbm.dumb, dbm.which. OK. So an html package could have htmllib for its __init__ (or html.lib), and then have html.entities and html.parser for htmlentitydefs and HTMLParser, respectively. Another example is http: http.lib, http.server.cgi, http.server.base, http.server.simple. Both examples are grouped because they make sense, but primarily to make the tail module name simpler. And then extend this to any other package that we consider creating? Otherwise leave it out? How would that follow for sqlite since that is not going to get any shorter thanks to a package? Should it still go into the package for organizational purposes? If you're asking me, the organizational purpose is 100% misguided. Well that will make the reorg simpler. =) In other words, should the stdlib reorg only introduce new packages if the majority of modules that go into the package end up with a shorter name? See what others say. This will be interesting. Another reason to have a top-level package would be if there are a lot of subpackages/submodules. This applies to the xml package for example. The only place I can see that coming into play is if there is any desire to group OS-specific modules together. Otherwise I think Tk-specific stuff is the only place where this has not been done before. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 11:37 AM, Phillip J. Eby wrote: Python automatically adds ~/.python/site-packages to sys.path; this is added /before/ the system site-packages file. An open question is whether it needs to go at the front of the list. It should definitely be searched before the system site-packages. What about including the Python version in the directory name? C Extensions may not work correctly across versions, and bytecode will get recompiled a lot if you're using multiple versions. Also, if this is a 2.6/3.0 change, it's likely that the *source* won't be compatible across versions either. :) D'oh, yes of course. So make that: ~/.python/lib/pythonX.Y/site-packages Python treats ~/.python/site-packages the same as the system site- packages, w.r.t. .pth files, etc. Open question: should we add yet another environment variable to control this? It's pretty typical for apps to expose such a thing so that the base directory (e.g. ~/.python) can be moved. I think that's all that's needed. It would make playing with easy_install/setuptools nicer to have this. Assuming that this is a true site directory (i.e., .pth files are recognized), then yes. IMO, it should be a true site directory. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4KTN3EjvBPtnXfVAQI6twP9HUQ23I0KCGZy4CC9sA6vvM5xYfmEgKQb 7H9AP84nSqaaX0iyONmRqlPahzHaEkjkoMW68EA3AIkXagf72sNbyBMO1p7I7ZQ6 5X6dR78o8w+NywO6sgdgxqQq3ikXNEEAy2EICLamT94Um1QxR7OV7SlihdpDs20w MujSDYAr9CQ= =el6S -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 11:30 AM, M.-A. Lemburg wrote: Open question: should we add yet another environment variable to control this? It's pretty typical for apps to expose such a thing so that the base directory (e.g. ~/.python) can be moved. I'd suggest to make the ~/.python part configurable by an env var, e.g. PYTHONRESOURCES. Since we can't use PYTHONOHOME, this works for me. Perhaps we could use that directory for other Python-related resources as well, e.g. an optional sys.path lookup cache (pickled dictionary of known package/module file locations to reduces Python startup time). Sure, why not? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR4KTn3EjvBPtnXfVAQLQlAP/R887WX0k3VNPoiyVs3qerYBj0XQyP4DT leyFWInEamtgk1+5hL+Vu180k+EFcjEQ8d2yet3sMMVUZ4piFHEd6SdNJantVKrl YBVTHkhEBNX2qMFxYmyTwzvjaMttbIn5w9TuEG4PnNiYQv4E4HlZ9HOkRY9YuNDh UMr4e4DCZtw= =PI+B -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008, at 3:56 PM, Brett Cannon wrote: OK. So an html package could have htmllib for its __init__ (or html.lib), and then have html.entities and html.parser for htmlentitydefs and HTMLParser, respectively. Actually, I'd be inclined not to have both HTMLParser and htmllib (regardless of names); a single capable interface should be provided. But that's a separate discussion. -Fred -- Fred Drake fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
And then extend this to any other package that we consider creating? Otherwise leave it out? How would that follow for sqlite since that is not going to get any shorter thanks to a package? Should it still go into the package for organizational purposes? If you're asking me, the organizational purpose is 100% misguided. It is my hope that there will be a great deal of restraint in the effort to group modules into packages in Py3.0. For the most part, putting modules in packages only makes them more difficult to access and introduces an additional burden of remembering which package to invoke. The best existing indicator we have is the organization of the docs for the standard library. I, for one, have a hell of a difficult time finding modules via the organized table of contents in the Library Reference. Instead, I always go the the Global Module Index where the somewhat flat namespace makes it easy to go directly to the module of interest. I'm curious whether the other developers have had the same experience -- if so, then it is a bad omen for over-organizing the standard library. Another indicator of what lies ahead is the current organization of os vs os.path. While that split-out was well done and necessary, I routinely have difficulty remembering which one contains a function of interest. There are handful of groupings that are obvious (i.e. html and socket modules going into an internet package). Outside of those, I think it best to leave the rest of the modules in a flat namespace (I don't want to have to quess where to find queue, random, pickle, pprint, decimal, and collections. I think most of the concerns with the standard library revolve around module quality, duplication, and obsolence. In contrast, I do not think that introducing a hierarchy of namespaces is of interest to most users. That exercise may well make the language harder to use/learn, not easier. my-two-cents-ly, Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 07/01/2008, Raymond Hettinger [EMAIL PROTECTED] wrote: It is my hope that there will be a great deal of restraint in the effort to group modules into packages in Py3.0. +1 The best existing indicator we have is the organization of the docs for the standard library. I, for one, have a hell of a difficult time finding modules via the organized table of contents in the Library Reference. Instead, I always go the the Global Module Index where the somewhat flat namespace makes it easy to go directly to the module of interest. I'm curious whether the other developers have had the same experience -- if so, then it is a bad omen for over-organizing the standard library. Yes, I have the same problem. I had not considered this, but I agree that it's the best indication available of how a hierarchical organisation might end up, and what issues there might be. From the Zen of Python: Flat is better than nested. There are handful of groupings that are obvious (i.e. html and socket modules going into an internet package). One man's obvious is another man's confusing. I'd stick to Guido's principle, that packages should only be used where they simplify sub-names. And even there, use restraint. I know I was earlier tending more towards the side of having more packages. I've been convinced otherwise. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 05:24 PM 1/7/2008 -0500, Raymond Hettinger wrote: The best existing indicator we have is the organization of the docs for the standard library. I, for one, have a hell of a difficult time finding modules via the organized table of contents in the Library Reference. Instead, I always go the the Global Module Index where the somewhat flat namespace makes it easy to go directly to the module of interest. I'm curious whether the other developers have had the same experience -- if so, then it is a bad omen for over-organizing the standard library. I do this too. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
* Barry Warsaw [EMAIL PROTECTED] [2008-01-07 16:01:42 -0500]: On Jan 7, 2008, at 11:37 AM, Phillip J. Eby wrote: Python automatically adds ~/.python/site-packages to sys.path; this is added /before/ the system site-packages file. An open question is whether it needs to go at the front of the list. It should definitely be searched before the system site-packages. What about including the Python version in the directory name? C Extensions may not work correctly across versions, and bytecode will get recompiled a lot if you're using multiple versions. Also, if this is a 2.6/3.0 change, it's likely that the *source* won't be compatible across versions either. :) D'oh, yes of course. So make that: ~/.python/lib/pythonX.Y/site-packages In that case how about: ~/.local/lib/pythonX.Y/site-packages or: ~/local/lib/pythonX.Y/site-packages I believe both of these locations are already in use by various systems / people, so it would fit in better with existing practice. IMO, it should be a true site directory. This would be ideal. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 07/01/2008, Tristan Seligmann [EMAIL PROTECTED] wrote: D'oh, yes of course. So make that: ~/.python/lib/pythonX.Y/site-packages In that case how about: ~/.local/lib/pythonX.Y/site-packages or: ~/local/lib/pythonX.Y/site-packages What would be used on Windows? It's likely to be of marginal use on Windows, but an appropriate equivalent should be defined. Possibly just replace ~ with %USERPROFILE%. I'd argue against anything under %APPDATA% as that directory is hidden. Also, should bdist_wininst/bdist_msi installers be updated to offer the option of installing to this directory? What about python setup.py install (add a --user flag, for example)? Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
The best existing indicator we have is the organization of the docs for the standard library. I, for one, have a hell of a difficult time finding modules via the organized table of contents in the Library Reference. Instead, I always go the the Global Module Index where the somewhat flat namespace makes it easy to go directly to the module of interest. I'm curious whether the other developers have had the same experience -- if so, then it is a bad omen for over-organizing the standard library. I nearly always use my browser's search function to find the module of interest, so yes, I'm effectively using a flat namespace. Another indicator of what lies ahead is the current organization of os vs os.path. While that split-out was well done and necessary, I routinely have difficulty remembering which one contains a function of interest. I mostly remember, but there are some notable exceptions: exists (posix system call, expect to find it in os), walk (which is the old deprecated one? have to check doc). -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 12:56 PM, Brett Cannon [EMAIL PROTECTED] wrote: OK. So an html package could have htmllib for its __init__ (or html.lib), and then have html.entities and html.parser for htmlentitydefs and HTMLParser, respectively. I'd be very reluctant to have more asymmetric packages like os where the package contains functionality at the top level as well as submodules, because it means that anyone using one of the submodules will pay the price of importing the top-level package. In this example, I can easily see someone using htmlentitydefs without needing htmllib. Another example is http: http.lib, http.server.cgi, http.server.base, http.server.simple. That sounds like a good one. Both examples are grouped because they make sense, but primarily to make the tail module name simpler. [...] Another reason to have a top-level package would be if there are a lot of subpackages/submodules. This applies to the xml package for example. The only place I can see that coming into play is if there is any desire to group OS-specific modules together. Otherwise I think Tk-specific stuff is the only place where this has not been done before. Well, that's a little different -- plat-* and lib-tk are not subpackages but subdirectories. For the plat-* subdirs, this is done so that the same logical module name can have different implementations per platform. For lib-tk it was done to make it easier to create a distribution that didn't include any Tk stuff. But the test package structure doesn't follow this lead, and I'm not sure if it still makes sense for lib-tk. OTOH maybe lib-tk could be promoted to being a real package (named tkinter?), with the core tkinter functionality in __init__ and the rest in submodules with names conforming to PEP 8; this is one example where that type of organization actually makes sense. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Paul Moore wrote: What would be used on Windows? It's likely to be of marginal use on Windows, but an appropriate equivalent should be defined. Possibly just replace ~ with %USERPROFILE%. I'd argue against anything under %APPDATA% as that directory is hidden. No, we shouldn't mess with the profile root directory on Windows. The data should either be installed under Application Data or under My Documents. You are right, the appdata directory is hidden by the installer could add a link to Application Data\Python\python2.x\ to the start menu. I also don't like the idea to replace ~ with another string. Every OS is probably using a different path (~/.python/ on Linux, ~/Library/Python on Mac and APPDATA\Python on Windows). The distutils package should gain two methods: global_sitedir() and local_sitedir([username]). Also, should bdist_wininst/bdist_msi installers be updated to offer the option of installing to this directory? What about python setup.py install (add a --user flag, for example)? Sounds good to me. Apropos My Documents and other special directories on Windows. Python doesn't have an API to get the directories from the registry. Is somebody interested in having a module for the task? I've some code for the job on disk. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 3:47 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Jan 7, 2008 12:56 PM, Brett Cannon [EMAIL PROTECTED] wrote: OK. So an html package could have htmllib for its __init__ (or html.lib), and then have html.entities and html.parser for htmlentitydefs and HTMLParser, respectively. I'd be very reluctant to have more asymmetric packages like os where the package contains functionality at the top level as well as submodules, because it means that anyone using one of the submodules will pay the price of importing the top-level package. In this example, I can easily see someone using htmlentitydefs without needing htmllib. Fair enough. Then something like html.lib or html.tools could be had for miscellaneous code. Another example is http: http.lib, http.server.cgi, http.server.base, http.server.simple. That sounds like a good one. Great! I think I get what you are after then for the reorg in terms of any new packages coming about. Both examples are grouped because they make sense, but primarily to make the tail module name simpler. [...] Another reason to have a top-level package would be if there are a lot of subpackages/submodules. This applies to the xml package for example. The only place I can see that coming into play is if there is any desire to group OS-specific modules together. Otherwise I think Tk-specific stuff is the only place where this has not been done before. Well, that's a little different -- plat-* and lib-tk are not subpackages but subdirectories. For the plat-* subdirs, this is done so that the same logical module name can have different implementations per platform. For lib-tk it was done to make it easier to create a distribution that didn't include any Tk stuff. But the test package structure doesn't follow this lead, and I'm not sure if it still makes sense for lib-tk. OTOH maybe lib-tk could be promoted to being a real package (named tkinter?), with the core tkinter functionality in __init__ and the rest in submodules with names conforming to PEP 8; this is one example where that type of organization actually makes sense. If the platform-specific stuff is made into their own packages (e.g., unix, mac, win, tkinter, etc.) then this can apply generically across the stdlib (sans Modules, of course, unless we eventually change how we handle building extension modules such that they are kept in /Lib as well). I think that would be nice in terms of organization of the code and the documentation as it makes it more obvious which modules are platform-specific. Is applying this to OS-specific modules work for you like it does for tkinter stuff? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 7, 2008 2:24 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: And then extend this to any other package that we consider creating? Otherwise leave it out? How would that follow for sqlite since that is not going to get any shorter thanks to a package? Should it still go into the package for organizational purposes? If you're asking me, the organizational purpose is 100% misguided. It is my hope that there will be a great deal of restraint in the effort to group modules into packages in Py3.0. There will be. There is a reason why I am willing to let a committee get involved with this as that will make almost any added package difficult to pull off. For the most part, putting modules in packages only makes them more difficult to access and introduces an additional burden of remembering which package to invoke. The best existing indicator we have is the organization of the docs for the standard library. I, for one, have a hell of a difficult time finding modules via the organized table of contents in the Library Reference. Instead, I always go the the Global Module Index where the somewhat flat namespace makes it easy to go directly to the module of interest. I'm curious whether the other developers have had the same experience -- if so, then it is a bad omen for over-organizing the standard library. Another indicator of what lies ahead is the current organization of os vs os.path. While that split-out was well done and necessary, I routinely have difficulty remembering which one contains a function of interest. Yeah, 'os' could stand a reorganization, but I am not touching that one. There are handful of groupings that are obvious (i.e. html and socket modules going into an internet package). Outside of those, I think it best to leave the rest of the modules in a flat namespace (I don't want to have to quess where to find queue, random, pickle, pprint, decimal, and collections. I think most of the concerns with the standard library revolve around module quality, duplication, and obsolence. That is definitely a concern of mine and the removal of obsolete code is still the primary motivation for me for this reorg. But I also realize that if we can group reasonable modules together (as you and Guido have now both suggested based more on similarity and coming up with shorter names) then I think we should take the chance now. In contrast, I do not think that introducing a hierarchy of namespaces is of interest to most users. That exercise may well make the language harder to use/learn, not easier. I was never planning on organizing the entire stdlib into a complete, one-level deep hierarchy. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Hello! We are discussing name space packages on the stdlib reorg list. For Python 3.0 we plan to organize the packages by purpose, e.g. put all database related packages like sqlite and shelve in a 'databases' name space. Of course we want to have the name spaces extensible by 3rd party software. The Python world as currently two ways to create extensible name space packages: pkgutil and pkg_resource. pkgutil is part of Python 2.5. pkg_resource is scheduled for Python 2.6 and 3.0 in PEP 365 [1]. The PEP hasn't been accepted yet. Questions: * PJE: Is pkg_resource ready for Python 2.6 and 3.0? * GvR: Are you going to accept Phillip's PEP? * PJE: Does pkg_resource have an easy way to overwrite a package in a name space package? E.g. an user wants to overwrite Python's databases.sqlite with a newer version of sqlite. Can he simply do it by inserting a package into sys.path before Lib/ ? Christian [1] http://www.python.org/dev/peps/pep-0365/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 8:33 AM, Christian Heimes [EMAIL PROTECTED] wrote: * PJE: Does pkg_resource have an easy way to overwrite a package in a name space package? E.g. an user wants to overwrite Python's databases.sqlite with a newer version of sqlite. Can he simply do it by inserting a package into sys.path before Lib/ ? Do we really want to encourage this? Wouldn't that just introduce more pyxml-like nightmares? I've been bitten way too many times by pyxml overwriting the regular xml package and causing version incompatibilities. I'd hate for this kind of thing to become common practice. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Steven Bethard wrote: Do we really want to encourage this? Wouldn't that just introduce more pyxml-like nightmares? I've been bitten way too many times by pyxml overwriting the regular xml package and causing version incompatibilities. I'd hate for this kind of thing to become common practice. I like to give 3rd party software a chance to *extend* a name space package like xml rather then to overwrite it. As far as I understand your problem pyxml is overwriting the name space and claiming it for itself rather than extending it. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 11:34 AM, Christian Heimes [EMAIL PROTECTED] wrote: Steven Bethard wrote: Do we really want to encourage this? Wouldn't that just introduce more pyxml-like nightmares? I've been bitten way too many times by pyxml overwriting the regular xml package and causing version incompatibilities. I'd hate for this kind of thing to become common practice. I like to give 3rd party software a chance to *extend* a name space package like xml rather then to overwrite it. As far as I understand your problem pyxml is overwriting the name space and claiming it for itself rather than extending it. The most recent problem was that pyxml installs a different version of pyexpat so that ``xml.parsers.pyexpat`` != ``pyexpat``. This causes problems with mod_python: http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash What concerned me was your comment: E.g. an user wants to overwrite Python's databases.sqlite with a newer version of sqlite Maybe the situation is different here, but having someone installing a different version of sqlite behind my back makes me nervous. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 07:34 PM 1/6/2008 +0100, Christian Heimes wrote: Steven Bethard wrote: Do we really want to encourage this? Wouldn't that just introduce more pyxml-like nightmares? I've been bitten way too many times by pyxml overwriting the regular xml package and causing version incompatibilities. I'd hate for this kind of thing to become common practice. I like to give 3rd party software a chance to *extend* a name space package like xml rather then to overwrite it. As far as I understand your problem pyxml is overwriting the name space and claiming it for itself rather than extending it. Indeed. It should also be noted that namespace packages are actually a very mature technology at this point. Before setuptools, pkgutil already supported them, from the time of 2.3's release. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 04:33 PM 1/6/2008 +0100, Christian Heimes wrote: Hello! We are discussing name space packages on the stdlib reorg list. For Python 3.0 we plan to organize the packages by purpose, e.g. put all database related packages like sqlite and shelve in a 'databases' name space. Of course we want to have the name spaces extensible by 3rd party software. The Python world as currently two ways to create extensible name space packages: pkgutil and pkg_resource. pkgutil is part of Python 2.5. pkg_resource is scheduled for Python 2.6 and 3.0 in PEP 365 [1]. The PEP hasn't been accepted yet. Questions: * PJE: Is pkg_resource ready for Python 2.6 and 3.0? The extra feature proposed in PEP 365 isn't done yet. Without the PEP acceptance, I didn't feel the need to rush on finishing it. Apart from that, the pkg_resources module has been pretty darn stable. * GvR: Are you going to accept Phillip's PEP? * PJE: Does pkg_resource have an easy way to overwrite a package in a name space package? OverRIDE, yes; overWRITE, no. E.g. an user wants to overwrite Python's databases.sqlite with a newer version of sqlite. Can he simply do it by inserting a package into sys.path before Lib/ ? As long as the 'databases' package hasn't been imported or had its namespace declared yet, yes. (I'm making the assumption, of course, that all of the namespace package requirements have been met: i.e., each package has a database/__init__.py that contains a namespace declaration and nothing else.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 06/01/2008, Steven Bethard [EMAIL PROTECTED] wrote: What concerned me was your comment: E.g. an user wants to overwrite Python's databases.sqlite with a newer version of sqlite Maybe the situation is different here, but having someone installing a different version of sqlite behind my back makes me nervous. Yes, that concerned me. Whether possible or not, I see this as bad practice in general. On the other hand, allowing cx_Oracle to register itself as databases.cx_Oracle - which is the basic namespace functionality - is something I feel is important. (I have no idea if the cx_Oracle author would want to do this, but I think the option should be available). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote: Maybe the situation is different here, but having someone installing a different version of sqlite behind my back makes me nervous. Er, someone who? Behind whose back? I'm quite confused by what it is that's making you nervous. Do you worry about people bundling newer versions of say, the optparse module or wsgiref with their applications? If so, why? Or if not, what's different? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 1:07 PM, Phillip J. Eby [EMAIL PROTECTED] wrote: At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote: Maybe the situation is different here, but having someone installing a different version of sqlite behind my back makes me nervous. Er, someone who? Behind whose back? I'm quite confused by what it is that's making you nervous. Do you worry about people bundling newer versions of say, the optparse module or wsgiref with their applications? If so, why? Or if not, what's different? I worry about exactly the pyxml problem. Someone installs pyxml on my system, pyxml replaces xml.parsers.expat with a different version of pyexpat than the rest of Python, and then programs like mod_python crash because the two components were compiled against different versions of a common library. Here's the link again that I posted earlier: http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash Note that this all happens behind my back because I didn't know that pyxml would be replacing pyexpat in such a way that would cause this crash. In fact, I didn't even know that pyxml was installing pyexpat. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 2:01 PM, Steven Bethard [EMAIL PROTECTED] wrote: On Jan 6, 2008 1:07 PM, Phillip J. Eby [EMAIL PROTECTED] wrote: At 12:03 PM 1/6/2008 -0700, Steven Bethard wrote: Maybe the situation is different here, but having someone installing a different version of sqlite behind my back makes me nervous. Er, someone who? Behind whose back? I'm quite confused by what it is that's making you nervous. Do you worry about people bundling newer versions of say, the optparse module or wsgiref with their applications? If so, why? Or if not, what's different? I worry about exactly the pyxml problem. Someone installs pyxml on my system, pyxml replaces xml.parsers.expat with a different version of pyexpat than the rest of Python, and then programs like mod_python crash because the two components were compiled against different versions of a common library. Here's the link again that I posted earlier: http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash Note that this all happens behind my back because I didn't know that pyxml would be replacing pyexpat in such a way that would cause this crash. In fact, I didn't even know that pyxml was installing pyexpat. This is my worry as well (and why I was going to phrase the situation in a more should this be considered tone than the way Christian stated it. =) . But then again none of this is impossible even if we do leave out extending the namespace. Tweaking a package's __path__ value after the fact is not exactly hard. So even if we don't do this we are not preventing anyone from extending the namespace, just discouraging. My question becomes whether we want to allow something like this even if we explicitly state people should not use this mechanism to override pre-existing modules. Do we want people tossing stuff into the 'databases' package, or should the packages in the stdlib be considered sacred? I am leaning towards not, but that's because I personally like knowing that if I import something from a stdlib namespace it is from the stdlib. I don't want some bug report from a naive user of cx_Oracle ending up in the stdlib because the import came from the 'databases' package. And I would guess that if you don't consider this a stdlib thing but for any third-party package that other third-party packages would not love other packages mucking with their namespace. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On 06/01/2008, Brett Cannon [EMAIL PROTECTED] wrote: My question becomes whether we want to allow something like this even if we explicitly state people should not use this mechanism to override pre-existing modules. Do we want people tossing stuff into the 'databases' package, or should the packages in the stdlib be considered sacred? I am leaning towards not, but that's because I personally like knowing that if I import something from a stdlib namespace it is from the stdlib. I don't want some bug report from a naive user of cx_Oracle ending up in the stdlib because the import came from the 'databases' package. And I would guess that if you don't consider this a stdlib thing but for any third-party package that other third-party packages would not love other packages mucking with their namespace. I see the point, but I'm against reserving generic package names like databases for the stdlib, unless 3rd parties can add modules in there. Another example might be gui.tkinter - why shouldn't gui.wx be allowed? If we want a guaranteed-stdlib package form, we should probably have a top-level package, std or whatever. That notion has, I believe, been shot down before (no time to look up references now). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Sun, Jan 06, 2008 at 11:12:43PM +, Paul Moore wrote: If we want a guaranteed-stdlib package form, we should probably have a top-level package, std or whatever. py. That notion has, I believe, been shot down before (no time to look up references now). Mr Van Rossum has spoken against it many times. Now I think - if we don't want a separate Python's top-level namespace may be we should think about a separate top-level non-Python's (3rd parties') namespace? With it we could have database.sqlite (Python's sqlite) and user.database.sqlite (a newer version); and by doing import database.sqlite you know exactly what version you are importing. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 03:01 PM 1/6/2008 -0700, Steven Bethard wrote: Note that this all happens behind my back because I didn't know that pyxml would be replacing pyexpat in such a way that would cause this crash. In fact, I didn't even know that pyxml was installing pyexpat. Ah -- so this is 100% orthogonal to namespace packages, since this is something that can happen even without __path__ munging. Namespace packages don't actually make this any easier, either, so I don't see how this reflects on the proposal. Without a namespace package, packages earlier on sys.path *completely* override those that are installed later. With a namespace package, only the specific submodules/subpackages that exist can override the ones that appear later. IOW, without namespace packages, if you have two 'foo' packages, one containing 'bar' and the other both 'bar' and 'baz', then with namespace packages you'll always see a foo.bar and a foo.baz, with the contents of foo.bar depending on path order. *Without* namespace packages, the exact same thing is true of foo.bar, but foo.baz will also be either visible or invisible depending on the path order. In other words, the status quo actually has *more* variability of what happens. So, while it might be a good idea to advise people against replacing packages they don't own or at least making it prominently visible that a package replaces something in the stdlib, it doesn't (so far as I can tell) have anything to do with the merits of namespace packages one way or the ohter. Unless there is something else I'm missing? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 3:28 PM, Oleg Broytmann [EMAIL PROTECTED] wrote: Now I think - if we don't want a separate Python's top-level namespace may be we should think about a separate top-level non-Python's (3rd parties') namespace? With it we could have database.sqlite (Python's sqlite) and user.database.sqlite (a newer version); and by doing import database.sqlite you know exactly what version you are importing. Bleh. I'm +1 on allowing third-party additions to the same 'database' namespace that the stdlib puts packages in. People will just have to get used to the package, and not the namespace, determining who to complain to. In theory, it might make sense to allow libraries to close some namespaces to deal with Brett's worry, but I think the consenting adults rule says not to bother. -- Namasté, Jeffrey Yasskin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 02:10 PM 1/6/2008 -0800, Brett Cannon wrote: My question becomes whether we want to allow something like this even if we explicitly state people should not use this mechanism to override pre-existing modules. Do we want people tossing stuff into the 'databases' package, or should the packages in the stdlib be considered sacred? This is actually an excellent point, given that the actual intended use of namespace packages is to allow an *organization* to control a namespace: e.g. zope.* and zc.* packages, osaf.* packages, etc. Using names that have meaning (like email or databases) sort of goes against the whole point of namespace packages in the first place. For some reason, I wasn't thinking about that when the original post came through. So, now that I've thought about it, I'm -1 on the stdlib using *top-level* namespace packages to sort out its contents (e.g. databases as a top-level package name) If we want to allow separately-distributed *upgrades* or bugfix releases of projects (such as an updated sqlite module), then using 2nd-level namespace packages like std.databases.* would allow that. Note, by the way, that this implies that somebody creating their own Oracle driver would *not* be expected to put it into std.databases. Again, the whole point of a namespace package is to reserve that namespace for packages produced by a particular organization, similar to the way e.g. the 'org.apache.projectname' packages in Java work. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 3:35 PM, Jeffrey Yasskin [EMAIL PROTECTED] wrote: On Jan 6, 2008 3:28 PM, Oleg Broytmann [EMAIL PROTECTED] wrote: Now I think - if we don't want a separate Python's top-level namespace may be we should think about a separate top-level non-Python's (3rd parties') namespace? With it we could have database.sqlite (Python's sqlite) and user.database.sqlite (a newer version); and by doing import database.sqlite you know exactly what version you are importing. Bleh. I'm +1 on allowing third-party additions to the same 'database' namespace that the stdlib puts packages in. People will just have to get used to the package, and not the namespace, determining who to complain to. In theory, it might make sense to allow libraries to close some namespaces to deal with Brett's worry, but I think the consenting adults rule says not to bother. There seems to be a misunderstanding. This is *not* going to happen for standard library package names. I'm fine with inventing mechanisms to allow 3rd party packages to beo cobbled together from multiple contributions (it would seem to make sense for e.g. Twisted or Zope). But I am absolutely squarely against 3rd party installs adding to (or worse, overriding) standard library package names. This is (to me) simple common sense, the reason being knowing who to blame. We get enough bug reports in the Python tracker about 3rd party software as it is. (In general I'm not keen on attempts to create a single unified ontology for library modules. It's like expecting all doctors in town to live on the same street. But my feelings on keeping a clean demarcation between standard and 3rd party are much stronger.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
Phillip J. Eby wrote: This is actually an excellent point, given that the actual intended use of namespace packages is to allow an *organization* to control a namespace: e.g. zope.* and zc.* packages, osaf.* packages, etc. Using names that have meaning (like email or databases) sort of goes against the whole point of namespace packages in the first place. For some reason, I wasn't thinking about that when the original post came through. So, now that I've thought about it, I'm -1 on the stdlib using *top-level* namespace packages to sort out its contents (e.g. databases as a top-level package name) I don't have a strong opinion as PJE but tend to agree with his point of view. We must not reserve a complete set of top level names and close them for 3rd party software. *Either* we create subject area packages (e.g. databases, web) and open them for 3rd party software *or* we create a top level name space for Python's stdlib and reserve it for our own purpose. For the initial example of databases.sqlite I think py.db.sqlite has a nice ring to it. If we want to allow separately-distributed *upgrades* or bugfix releases of projects (such as an updated sqlite module), then using 2nd-level namespace packages like std.databases.* would allow that. I like to see a possibility to easily upgrade, bugfix or extend a stdlib package with 3rd party extensions. PEP 297 (http://www.python.org/dev/peps/pep-0297/) contains some useful ideas. Note, by the way, that this implies that somebody creating their own Oracle driver would *not* be expected to put it into std.databases. Again, the whole point of a namespace package is to reserve that namespace for packages produced by a particular organization, similar to the way e.g. the 'org.apache.projectname' packages in Java work. The initial idea behind the new packages for Python 3.0 weren't really based on name space packages. It was more about grouping related modules by subject. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 4:10 PM, Christian Heimes [EMAIL PROTECTED] wrote: Phillip J. Eby wrote: This is actually an excellent point, given that the actual intended use of namespace packages is to allow an *organization* to control a namespace: e.g. zope.* and zc.* packages, osaf.* packages, etc. Using names that have meaning (like email or databases) sort of goes against the whole point of namespace packages in the first place. For some reason, I wasn't thinking about that when the original post came through. So, now that I've thought about it, I'm -1 on the stdlib using *top-level* namespace packages to sort out its contents (e.g. databases as a top-level package name) I don't have a strong opinion as PJE but tend to agree with his point of view. We must not reserve a complete set of top level names and close them for 3rd party software. Why not? 3rd party software can copy the same hierarchy under its own toplevel package, e.g. zope.db, zope.net, etc. Regarding using common words, either the stdlib grabs these, or *nobody* gets to use them (for fear of conflicting with some other 3rd party package grabbing the same). *Either* we create subject area packages (e.g. databases, web) and open them for 3rd party software *or* we create a top level name space for Python's stdlib and reserve it for our own purpose. For the initial example of databases.sqlite I think py.db.sqlite has a nice ring to it. Java's example notwithstanding, I don't want py or python to be part of the stdlib package namespace. *If* (part of) the stdlib has to live under a single distinguished name, pick something like std or core. When I'm using Python I already know I'm using Python, I don't want to be reminded of that fact on every import line. If we want to allow separately-distributed *upgrades* or bugfix releases of projects (such as an updated sqlite module), then using 2nd-level namespace packages like std.databases.* would allow that. I like to see a possibility to easily upgrade, bugfix or extend a stdlib package with 3rd party extensions. PEP 297 (http://www.python.org/dev/peps/pep-0297/) contains some useful ideas. I see mostly possibilities for abuse here. Linux vendors can install bugfixes or using their own packaging system. Note, by the way, that this implies that somebody creating their own Oracle driver would *not* be expected to put it into std.databases. Again, the whole point of a namespace package is to reserve that namespace for packages produced by a particular organization, similar to the way e.g. the 'org.apache.projectname' packages in Java work. Right. The initial idea behind the new packages for Python 3.0 weren't really based on name space packages. It was more about grouping related modules by subject. See my previous post. This is only mildly useful. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008, at 6:28 PM, Oleg Broytmann wrote: On Sun, Jan 06, 2008 at 11:12:43PM +, Paul Moore wrote: If we want a guaranteed-stdlib package form, we should probably have a top-level package, std or whatever. py. That notion has, I believe, been shot down before (no time to look up references now). Mr Van Rossum has spoken against it many times. Now I think - if we don't want a separate Python's top-level namespace may be we should think about a separate top-level non-Python's (3rd parties') namespace? I think some things make sense to move some things into a common namespace: hashlib, email, xml et al... I also think there are probably other candidates for similar grouping and cleanup, but I don't have a well thought out set. (db, url??, zip??); and I think it is happening, albeit slowly. With it we could have database.sqlite (Python's sqlite) and user.database.sqlite (a newer version); and by doing import database.sqlite you know exactly what version you are importing. At first blush I am +1 for a third party or non stdlib namespace; user is already a module though. Other ideas: sitepkg, addon, extra, ext But then what of packages that are already namespaced? It would be tedious to; from sitepkg.zope.app.interface import SomeThing So while I like the idea, I think I am against wedging everything into namespaces just for the sake of it; at the end of the day I think I am -1 on *requiring* it. Additionally, I have only been reading this list for a week or so and feel a little like I may be injecting a novice and poorly formed opinion into a discussion that has been ongoing for years. Please pardon my ignorance if this is the case. ~ro Oleg. -- Oleg Broytmannhttp://phd.pp.ru/ [EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/reed% 40reedobrien.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: Regarding using common words, either the stdlib grabs these, or *nobody* gets to use them (for fear of conflicting with some other 3rd party package grabbing the same). This isn't quite true; a standalone Python application that isn't extensible doesn't need to worry about this. And it's standalone apps that are most likely to claim these common words. (For example, until recently, Chandler's database library packages were in 'repository.*'.) But of course this is still a pretty minor point overall. If the stdlib does go for deeper nestings, I have a slight preference for seeing them under std.* or some such rather than top level. But I don't really see a whole lot of point to doing a major re-org of the stdlib space to begin with, for the simple reason that package names are not really categories -- they're *names*. IMO 'from databases import sqlite' doesn't add any value over 'import pysqlite3' to begin with. Worse, it will likely be an attractive nuisance for people saying why don't we have databases.Oracle? and suchlike. And you still have to remember the names, only now they're longer. And was it database or databases? Greater uniqueness of names is just another reason flat is better than nested. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages
On Jan 6, 2008 7:23 PM, Phillip J. Eby [EMAIL PROTECTED] wrote: At 04:23 PM 1/6/2008 -0800, Guido van Rossum wrote: Regarding using common words, either the stdlib grabs these, or *nobody* gets to use them (for fear of conflicting with some other 3rd party package grabbing the same). This isn't quite true; a standalone Python application that isn't extensible doesn't need to worry about this. And it's standalone apps that are most likely to claim these common words. (For example, until recently, Chandler's database library packages were in 'repository.*'.) But of course this is still a pretty minor point overall. If the stdlib does go for deeper nestings, I have a slight preference for seeing them under std.* or some such rather than top level. But I don't really see a whole lot of point to doing a major re-org of the stdlib space to begin with, for the simple reason that package names are not really categories -- they're *names*. IMO 'from databases import sqlite' doesn't add any value over 'import pysqlite3' to begin with. Worse, it will likely be an attractive nuisance for people saying why don't we have databases.Oracle? and suchlike. And you still have to remember the names, only now they're longer. And was it database or databases? Greater uniqueness of names is just another reason flat is better than nested. :) Right. Packages are useful if it helps make the sub-names shorter. The email package is a good example: it uses lots of generic names like errors, charset, encoders, message, parser, utils, iterators. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
