Re: [Python-Dev] Thoughts on stdlib evolvement
Fredrik Lundh wrote: [snip] > in my experience, any external library that supports more than one > Python version on more than one platform is likely to be more robust > than code in the core. add the multilevel volunteer approach de- > described by Steven (with the right infrastructure, things like that > just appear), and you get more competent manpower contributing > to the standard distribution than you can get in any other way. In this context PEP 2 might be useful to look at again: http://www.python.org/peps/pep-0002.html It separates between library integrators (into the Python standard library) and library maintainers, and tries to ensure maintenance happens on a continuing basis. A multi-level setup to develop the Python standard library could take other forms, of course. I sometimes feel the Python-dev community is more focused on the development of the interpreter than of the library, and that this priority tends to be reversed outside the Python-dev community. So, it might be nice if the Python standard library development integrators and maintainers could be more separate from the Python core developers. A python-library-dev, say. Then again, this shouldn't result in large changes in the standard library, as old things should continue to work for the forseeable future. So for larger reorganizations and refactorings, such development should likely take place entirely outside the scope of the core distribution, at least for the time being. Finally, I haven't really seen much in the way of effort by developers to actually do such a large-scale cleanup. Nobody seems to have stepped up, taking the standard library, and made it undergo a radical refactoring (and just releasing it separately). That this hasn't happened seems to indicate the priority is not very high in the mind of people, so the problem might not be high either. :) Regards, Martijn ___ 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] Thoughts on stdlib evolvement
Gustavo Niemeyer wrote: > > > moving the main trunk and main development over to the Python CVS is > > > another thing, entirely. > > > > (as I've said many times before, both the user community and the developer > > community would benefit if the core standard library were made smaller, and > > more externally maintained packages were included in the standard releases) > > An issue to consider about this is that maintainers (not talking about > you or anyone else specifically) have different concepts of stability, > and while it may seem perfectly ok to refactor external modules between > two stable releases, doing so in the standard library would spread fear > and "python is so untrustful" feelings. I think you're seriously underestimating the competence of other developers, and seriously overestimating the competence of the python core developers. in my experience, any external library that supports more than one Python version on more than one platform is likely to be more robust than code in the core. add the multilevel volunteer approach de- described by Steven (with the right infrastructure, things like that just appear), and you get more competent manpower contributing to the standard distribution than you can get in any other way. ___ 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] Thoughts on stdlib evolvement
> "Gustavo" == Gustavo Niemeyer <[EMAIL PROTECTED]> writes: Gustavo> An issue to consider about this is that maintainers (not Gustavo> talking about you or anyone else specifically) have Gustavo> different concepts of stability, and while it may seem Gustavo> perfectly ok to refactor external modules between two Gustavo> stable releases, doing so in the standard library would Gustavo> spread fear and "python is so untrustful" feelings. This simply hasn't been a problem in XEmacs's equivalent to the standard library. In fact, the library modules tend to be more stable than the core, for several reasons. One important one is that the modules we distribute are not necessarily the bleeding edge. In particular, we try to keep up (within a couple weeks) with bugfixes to stable lines, but often lag several months after a major refactoring. This multitrack approach does involve some extra administrative work, but the burden on the core team is minimal. Most modules are managed by volunteers who do not feel able to contribute to the core (and often not to the coding of "their" module), but are very pleased to be able to contribute in this way. They are usually far more competent than the core developers to judge when new features are sufficiently attractive and stable to warrant updating to a refactored version, too. They tend to be more conservative than the module's lead maintainer, too. I will grant that XEmacs deserves (and probably has) a lower trust rating than Python, but that is due to flaws in the _core_, not in the package management. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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] Thoughts on stdlib evolvement
> > moving the main trunk and main development over to the Python CVS is > > another thing, entirely. > > (as I've said many times before, both the user community and the developer > community would benefit if the core standard library were made smaller, and > more externally maintained packages were included in the standard releases) An issue to consider about this is that maintainers (not talking about you or anyone else specifically) have different concepts of stability, and while it may seem perfectly ok to refactor external modules between two stable releases, doing so in the standard library would spread fear and "python is so untrustful" feelings. That's something a good police, reflecting practices that we learn "by osmose" while living in that environment (python-dev) for a while, could try to handle. Enforcing it is another issue, of course. -- Gustavo Niemeyer http://niemeyer.net ___ 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] Thoughts on stdlib evolvement
> moving the main trunk and main development over to the Python CVS is > another thing, entirely. (as I've said many times before, both the user community and the developer community would benefit if the core standard library were made smaller, and more externally maintained packages were included in the standard releases) (the development platform could need an overhaul as well; cvs/sourceforge/tex is a serious bottleneck. but the former doesn't require the latter). ___ 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] Thoughts on stdlib evolvement
Raymond Hettinger wrote: >> > If Fred were up for it, I think ElementTree would be a wonderful, >> > must-have addition. > >> I might be missing fine details of the English language here >> (what does "to be up for something" mean?), however, I believe >> ElementTree is an unlikely addition to the standard library. > > Rewritten: > > If Fredrik Lundh were supportive of the idea, I think the Standard > Library would benefit greatly from incorporating ElementTree. shipping stable versions of ElementTree/cElementTree (or PIL, or python- doc, or exemaker, or what else you might find useful) with official Python releases is perfectly okay. moving the main trunk and main development over to the Python CVS is another thing, entirely. ___ 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] Thoughts on stdlib evolvement
> Fernando Perez wrote: >> Skip Montanaro wrote: >> >> I've wondered if it wouldn't be better if the std lib were all stuffed >> into its >> own namespace: >> >> from std import urllib >> >> If a more structured approach is desired, it could be >> >> from std.www import urllib > > One may want to look at the "py.std" approach of "the py lib", found at > http://codespeak.net/py/current/doc/misc.html#the-py-std-hook > > Reinhold Thats where I hijacked the idea. Doing that would allow both to work. Legacy code could still use: import logging and new code could use: import std.logging At some point the legacy way to do things should be deprecated. David ___ 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] Thoughts on stdlib evolvement
Bob Ippolito wrote: > > On Jun 7, 2005, at 11:47 AM, Josiah Carlson wrote: > >> Ron Adam wrote: >> [snip] >> >>> Having less in the core distribution means smaller complete >>> applications >>> to install when py2exe is used. There also needs to be some assurance >>> that the standard library has as few bugs in it as possible. The more >>> that's added to it, the more work and testing to do that is needed. >>> >> >> Almost by definition, applications using py2exe are minimal Python >> installations without external dependencies. > > > Yeah, py2exe only includes the portion of the standard library that you > use, anyway... so the size of it is not an issue. > > -bob This wasn't the main point of my post in any case. Yes, as high bandwidth connections and disk space become more common, the organizational aspects are really more important than the size aspects. Cheers, Ron ___ 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] Thoughts on stdlib evolvement
On Jun 7, 2005, at 11:47 AM, Josiah Carlson wrote: > Ron Adam wrote: > [snip] > >> Having less in the core distribution means smaller complete >> applications >> to install when py2exe is used. There also needs to be some >> assurance >> that the standard library has as few bugs in it as possible. The >> more >> that's added to it, the more work and testing to do that is needed. >> > > Almost by definition, applications using py2exe are minimal Python > installations without external dependencies. Yeah, py2exe only includes the portion of the standard library that you use, anyway... so the size of it is not an issue. -bob ___ 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] Thoughts on stdlib evolvement
Ron Adam wrote: [snip] > Having less in the core distribution means smaller complete applications > to install when py2exe is used. There also needs to be some assurance > that the standard library has as few bugs in it as possible. The more > that's added to it, the more work and testing to do that is needed. Almost by definition, applications using py2exe are minimal Python installations without external dependencies. - Josiah ___ 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] Thoughts on stdlib evolvement
Reinhold Birkenfeld wrote: > Hello, > > I am currently having some thoughts about the standard library, with regard > to Python 2.5 and 3.0. Since I don't want to withhold them from you, here > are they ;) > > - Flat namespace: Should we tend to a more hierarchic library (e.g. > inet.url, inet.http, inet.nntp)? This would increase clarity when > searching for a module. I think putting the standard library in it's own package would be the first step. "std" has been mentioned a couple of times and I think its a good name for it. For backwards compatibility, maybe a "from __compatible__ import ver_2.x", or something similar, could be used as a way to allow future versions a bit more flexibility to change? Trying to move the modules in python/lib to python/packages/stdlib to see what would happen revealed the following files are required to be in python/lib to start the python shell without errors. copy_reg.py ntpath.py os.py site.py stat.py types.py These files are modules site.py imports. Maybe these should be builtins so that the shell could start without importing any modules? > - 3rd party modules: There are many superb modules out there, some of which > really do have a "standard" character. Examples include PIL, numarray, > ElementTree, [wxPython - I know this is a hairy issue], I'm on the side of less in builtins and less in the standard library, and for having a central repository for developers to distribute their packages. A python updater that gets a list of installable packages to install or uninstall would be fantastic. ;-) Having less in the core distribution means smaller complete applications to install when py2exe is used. There also needs to be some assurance that the standard library has as few bugs in it as possible. The more that's added to it, the more work and testing to do that is needed. > - User interface: Tkinter may be "the" standard, but other Toolkits deserve > notice, notably wxPython and PyGtk, the latter of which might be even > easier to package. I think these fall into the category of optional "official" extension packages that could be included in the core installer, but are not part of the standard library package itself. They are packages that would be maintained separately from the core and have their own developers dedicated to maintaining them. The 'official', or other designator if appropriate, would mean that they are important packages that fulfill a need and efforts to make and keep them compatible with the current python release is made. An "official" package designation might be something that developers could strive for and proudly display on their website or resume. Some minimum standards would be needed... ie current with current version of python, fully functional, fulfilling a need, etc. A request and voting process of some sort where python-dev can award "officialdom" to package developers might be usefull for this. Just a few thoughts, Cheers, Ron ___ 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] Thoughts on stdlib evolvement
Fernando Perez wrote: > Skip Montanaro wrote: > >> I wouldn't mind a stdlib that defined a set of top-level packages (some of >> which might be wholly unpopulated by modules in the standard distribution) >> It might, for example, define a gui package and gui.Tkinter and gui._tkinter >> modules, leaving the remainder of gui namespace available for 3rd party >> modules. Such a scheme would probably work best if there was some fairly >> lightweight registration/approval process in the community to avoid needless >> collisions. For example, it might be a bit confusing if two organizations >> began installing their packages in a subpackage named gui.widgets. An >> unsuspecting person downloading an application that used one version of >> gui.widgets into environment with the conflicting gui.widgets would run into >> trouble. > > I've wondered if it wouldn't be better if the std lib were all stuffed into > its > own namespace: > > from std import urllib > > If a more structured approach is desired, it could be > > from std.www import urllib One may want to look at the "py.std" approach of "the py lib", found at http://codespeak.net/py/current/doc/misc.html#the-py-std-hook Reinhold -- Mail address is perfectly valid! ___ 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] Thoughts on stdlib evolvement
Skip Montanaro wrote: > Tim> On 6/6/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > > >> - Flat namespace: Should we tend to a more hierarchic library (e.g. > >> inet.url, inet.http, inet.nntp)? This would increase clarity when > >> searching for a module. > > Tim> -1. I feel the opposite way: when trying to figure out where > Tim> something "lives", I prefer Python's flat namespace to (for > Tim> example) Java's com.company.baz.bar.foo hierarchy. > > I think Reinhold's suggestion (e.g., inet.*) was for a flatter namespace > than Java's scheme, but for a slightly more structured namespace than the > current standard library provides. Some amount of structure helps to > collect modules together whose names don't obviously suggest who their > neighbors are in the functionality space. For example, to the naive user it > might not be obvious that these groups of modules and packages are related: > > * getopt and optparse > * bsddb, gdbm and anydbm > * email, mhlib, quopri > * heapq, collections > * user, site, sitecustomize > * profile, hotshot, pstats > * pipes, subprocess, os Yep, exactly. Java's namespaces are ugly, that's right, but a flatter version certainly improves readability. """Namespaces are one honking great idea -- let's do more of those!""" > I wouldn't mind a stdlib that defined a set of top-level packages (some of > which might be wholly unpopulated by modules in the standard distribution) > It might, for example, define a gui package and gui.Tkinter and gui._tkinter > modules, leaving the remainder of gui namespace available for 3rd party > modules. Such a scheme would probably work best if there was some fairly > lightweight registration/approval process in the community to avoid needless > collisions. For example, it might be a bit confusing if two organizations > began installing their packages in a subpackage named gui.widgets. An > unsuspecting person downloading an application that used one version of > gui.widgets into environment with the conflicting gui.widgets would run into > trouble. Is the CPAN namespace wide open? If I wanted to create a Perl > module to fit into the HTML namespace is there some procedure involved or is > it an example of squatters' rights? Personally, I think that CPAN is one of the greatest strengths of Perl. The language is a mess, and the quality of many modules is questionable, but it's incredibly easy to find a module for handling a special problem, and the namespaces are IMHO well thought out. Additionally, the docs > >> - 3rd party modules: There are many superb modules out there, some of > >> which really do have a "standard" character. Examples include PIL, > >> numarray, ElementTree, [wxPython - I know this is a hairy issue], > > Tim> I think the most important question for each of these is "is the > Tim> module's release schedule at least as stable as Python's?". For > Tim> many of these, I suspect the answer is "no". > > If you provide the necessary namespace structure for them to nestle into, I > suspect most of them could be maintained outside the stdlib just fine. Exactly! There needn't be such a big separation between stdlib and 3rd party. Access to the net is standard nowadays, though it wouldn't be of any harm making a big distribution with all modules available, for downloading and burning on CD, for example. PJE's great EasyInstall and Python Eggs will be a perfect starting point for this, I think. Reinhold -- Mail address is perfectly valid! ___ 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] Thoughts on stdlib evolvement
On Mon, Jun 06, 2005 at 01:38:36PM -0500, Skip Montanaro wrote:
>
>
> Reinhold> - Flat namespace: Should we tend to a more hierarchic library
> Reinhold> (e.g. inet.url, inet.http, inet.nntp)? This would increase
> Reinhold> clarity when searching for a module.
>
> We've talked about this before. The main technical challenge seems to be
> backward compatibility. You need to support both flat ("import urllib") and
> packaged namespaces ("from www import urllib"), possibly within the same
> application. That is, postulating a www package, if I execute
>
> import urllib
> from www.urllib import urlopen
>
> the module-level code should only be executed once, and
>
> urlopen == urllib.urlopen
>
> should evaluate to True.
Can't this be handled with an __init__ module? Create an inet package
and having the __init__ module pull whatever it wanted into it's own
namespace.
It would be nice to then use warnings to show deprecation messages
when the old import is used (import url instead of import inet.url),
but I don't think that is quite so easy.
--
David Stanek
www.roninds.net
GPG keyID #6272EDAF on http://pgp.mit.edu
Key fingerprint = 8BAA 7E11 8856 E148 6833 655A 92E2 3E00 6272 EDAF
pgptKki5DlMrm.pgp
Description: 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] Thoughts on stdlib evolvement
Fernando Perez wrote: > Josiah Carlson wrote: >>Fernando Perez wrote: >>>I've wondered if it wouldn't be better if the std lib were all stuffed into >>>its own namespace: >>> >>>from std import urllib >>> >>>If a more structured approach is desired, it could be >>> >>>from std.www import urllib >> >>This generally brings up the intersection of stdlib and nonstdlib naming >>hierarchy. More specifically, what does "import email" mean? >>Presumably it means to import the email module or package, but from the >>current module directory, or from the standard library? > > > Well, I've thought of this (ligthly) mostly as a py3k thing, since it would > require that 'import email' in the naked fails, as it would become 'import > std.email', or 'import std.www.email' or whatever. A plain 'import email' > would then refer to some third-party 'email' module, not part of the standard > library. > > Since this would mean a massive break of exisiting code, it would necessarily > be > a py3k issue. But nonetheless the idea of confinign the stdlib to the 'std' > namespace does have some appeal, at least to me. Actually no. Re: std.* If there were a single path (or set of paths) know at install time where standard library modules are, then that can be placed in a PYSDTLIB environment variable (or some other specified place). Inside Python, whenever an import is done relative to std, one merely examines the paths offered via the PYSTDLIB environment variable for the looked-for module. For modules/packages in site-packages, one could use another name, perhaps "packages" or somesuch, to refer to it. sys.path is not usable as-is because it can contain the path of the module named __main__, and is (not uncommonly) modified by user code. This can be used with a proper import hook, which is turned on per-module via a __future__ import, hence no backwards compatibility issues. What I had been working on is the use of special import semantics for non-stdlib/site-packages modules. Specifically if you were to write 'mymodule.py' and import your other module 'myothermodule.py' in the same path, you would use "from . import myothermodule". It doesn't solve any problems with standard library naming, but it does allow one to do cousin imports... "from ..uncle import cousin", as well as all sorts of other things, which allows (in writing software) for modules and packages to be shared by other packages. - Josiah ___ 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] Thoughts on stdlib evolvement
Josiah Carlson wrote: > Fernando Perez wrote: >> I've wondered if it wouldn't be better if the std lib were all stuffed into >> its own namespace: >> >> from std import urllib >> >> If a more structured approach is desired, it could be >> >> from std.www import urllib > > This generally brings up the intersection of stdlib and nonstdlib naming > hierarchy. More specifically, what does "import email" mean? > Presumably it means to import the email module or package, but from the > current module directory, or from the standard library? Well, I've thought of this (ligthly) mostly as a py3k thing, since it would require that 'import email' in the naked fails, as it would become 'import std.email', or 'import std.www.email' or whatever. A plain 'import email' would then refer to some third-party 'email' module, not part of the standard library. Since this would mean a massive break of exisiting code, it would necessarily be a py3k issue. But nonetheless the idea of confinign the stdlib to the 'std' namespace does have some appeal, at least to me. Best, f ___ 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] Thoughts on stdlib evolvement
> "Skip" == Skip Montanaro <[EMAIL PROTECTED]> writes: Skip> If you provide the necessary namespace structure for them to Skip> nestle into, I suspect most of them could be maintained Skip> outside the stdlib just fine. FWIW, this has worked well for XEmacs; it's one of our most popular features vis-a-vis GNU Emacs. Users like it because we do provide a centralized directory of modules (with many mirrors) that they can download updates from, as well as a "batteries included" library distribution (which we call "SUMO tarballs" for historical reasons). Package developers like it because they can maintain closer control, yet have up-to-date versions distributed from our repository. Finally the core maintainers like it because there's a clear delegation of responsibility. We provide a centralized repository, which is mirrored by a couple score sites; I'm not sure how much harder it would be to make it distributed. The essential feature is the centralized directory. We do have problems. One is the megapackage issue that Phillip Eby referred in his reply to Bob Ippolito <[EMAIL PROTECTED]>. Our packaging system doesn't work well for them. Some of the problems are our fault, but I think it's actually a hard problem; we could fix up some details, but not really address the core issues of megapackages. The other one is that our initial division into "core" and "package" was pretty radical, and several core developers still want to pull certain packages back into core. But this creates backward compatibility problems. I think this would be less of a problem for Python. Creating the package repository could be more conservative: Python's standard library has plenty of modules that would not present such problems. In any case, Python has better facilities for dealing with backward compatibility issues (such as deprecation warnings and the like) than we do, and the language itself is simply more suited to preserving modularity than Emacs Lisp is (with its single dynamically scoped namespace). Our package namespace structure is trivial (it's basically flat); what is more important than the namespace structure, I think, is provision of package organization and directory utilities as Phillip Eby mentions. If they're reasonably flexible and Python invests some effort in helping package maintainers with different current distribution methods to adapt, I think this would work well for Python too. One thing we have found is that it takes only a small amount of incremental work to maintain the package directory and repository as such, even as it has grown dramatically. By contrast, I find the Zope wiki-based organization of Products quite annoying to work with. Of course the packaged code itself can and does bitrot if the external maintainer goes AWOL, or simply doesn't like hanging out with XEmacs people. In such cases we've found that users will often step up to help with the nitty-gritty management of "their" package, such as tracking bug reports, liaison with an "unsociable" upstream, regression testing, and integrating changes (anybody can run make and patch), even if they have to ask for help with code-related work. Ie, the fact that there is a well-defined package requiring specific management tasks encourages them to take on the work they can handle. For XEmacs the effort of separating out the packages was moderately large; it took about a year, with three or four developers spending a substantial fraction of their time on it, either organizing the repository or creating infrastructure. It was a very worthwhile investment. Python's investment probably would be proportionately smaller, as much of the necessary infrastructure seems to be already available. For XEmacs, I think the main returns come from creating well-defined chunks that people can "own" and take responsibility for. This helps to mitigate the "dormant bug" problem, and generally keeps the packaged code fresher than it was in the old days, even though we have a much larger volume of code and probably less manpower now. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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] Thoughts on stdlib evolvement
Fernando Perez wrote: > Skip Montanaro wrote: > > >>I wouldn't mind a stdlib that defined a set of top-level packages (some of >>which might be wholly unpopulated by modules in the standard distribution) >>It might, for example, define a gui package and gui.Tkinter and gui._tkinter >>modules, leaving the remainder of gui namespace available for 3rd party >>modules. Such a scheme would probably work best if there was some fairly >>lightweight registration/approval process in the community to avoid needless >>collisions. For example, it might be a bit confusing if two organizations >>began installing their packages in a subpackage named gui.widgets. An >>unsuspecting person downloading an application that used one version of >>gui.widgets into environment with the conflicting gui.widgets would run into >>trouble. > > > I've wondered if it wouldn't be better if the std lib were all stuffed into > its > own namespace: > > from std import urllib > > If a more structured approach is desired, it could be > > from std.www import urllib This generally brings up the intersection of stdlib and nonstdlib naming hierarchy. More specifically, what does "import email" mean? Presumably it means to import the email module or package, but from the current module directory, or from the standard library? I posted about this months ago, and got to writing an import hook that used a method suggested by Guido by naming things (sys.modules names) based on whether they were imported relative to the module with a __name__ of '__main__', and using the prefix dot semantics for package-relative imports to mean any relative imports. I eventually got hung up on some nested import bits, and got busy with work. I may have time to hack on it next week to finish the 'proof of concept' (currently in the Bay area for work), but if someone wants or needs more explanation, I would be happy to offer it. - Josiah ___ 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] Thoughts on stdlib evolvement
Skip Montanaro wrote: > I wouldn't mind a stdlib that defined a set of top-level packages (some of > which might be wholly unpopulated by modules in the standard distribution) > It might, for example, define a gui package and gui.Tkinter and gui._tkinter > modules, leaving the remainder of gui namespace available for 3rd party > modules. Such a scheme would probably work best if there was some fairly > lightweight registration/approval process in the community to avoid needless > collisions. For example, it might be a bit confusing if two organizations > began installing their packages in a subpackage named gui.widgets. An > unsuspecting person downloading an application that used one version of > gui.widgets into environment with the conflicting gui.widgets would run into > trouble. I've wondered if it wouldn't be better if the std lib were all stuffed into its own namespace: from std import urllib If a more structured approach is desired, it could be from std.www import urllib for example. But having std. as the top-level namespace for the stdlib, could simplify (I think) life a lot in the long run. If a decision for a more structured namespace is made, then it might be nice to have the same top-level structure in site-packages, albeit empty by default: from std.www import foo -> standard library www packages from www import bar -> third-party www packages Third-party packages can still be put into base site-packages, of course, but developers could be encouraged to transition into putting things into these categories. This would also ease the process of 'staging' a module as external for a while before deciding whether it meets the requirement for being put into the stdlib. Just an idea (sorry if it's been discussed and shot down before). best, f ___ 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] Thoughts on stdlib evolvement
Tim> On 6/6/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: >> - Flat namespace: Should we tend to a more hierarchic library (e.g. >> inet.url, inet.http, inet.nntp)? This would increase clarity when >> searching for a module. Tim> -1. I feel the opposite way: when trying to figure out where Tim> something "lives", I prefer Python's flat namespace to (for Tim> example) Java's com.company.baz.bar.foo hierarchy. I think Reinhold's suggestion (e.g., inet.*) was for a flatter namespace than Java's scheme, but for a slightly more structured namespace than the current standard library provides. Some amount of structure helps to collect modules together whose names don't obviously suggest who their neighbors are in the functionality space. For example, to the naive user it might not be obvious that these groups of modules and packages are related: * getopt and optparse * bsddb, gdbm and anydbm * email, mhlib, quopri * heapq, collections * user, site, sitecustomize * profile, hotshot, pstats * pipes, subprocess, os I wouldn't mind a stdlib that defined a set of top-level packages (some of which might be wholly unpopulated by modules in the standard distribution) It might, for example, define a gui package and gui.Tkinter and gui._tkinter modules, leaving the remainder of gui namespace available for 3rd party modules. Such a scheme would probably work best if there was some fairly lightweight registration/approval process in the community to avoid needless collisions. For example, it might be a bit confusing if two organizations began installing their packages in a subpackage named gui.widgets. An unsuspecting person downloading an application that used one version of gui.widgets into environment with the conflicting gui.widgets would run into trouble. Is the CPAN namespace wide open? If I wanted to create a Perl module to fit into the HTML namespace is there some procedure involved or is it an example of squatters' rights? >> - 3rd party modules: There are many superb modules out there, some of >> which really do have a "standard" character. Examples include PIL, >> numarray, ElementTree, [wxPython - I know this is a hairy issue], Tim> I think the most important question for each of these is "is the Tim> module's release schedule at least as stable as Python's?". For Tim> many of these, I suspect the answer is "no". If you provide the necessary namespace structure for them to nestle into, I suspect most of them could be maintained outside the stdlib just fine. Skip ___ 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] Thoughts on stdlib evolvement
At 03:17 PM 6/6/2005 -0700, Bob Ippolito wrote: >Personally I'd like to see the standard library get smaller rather >than larger. There's a whole lot of bit rot in there, and since >sys.path prefers the standard library over anything else it's a >really huge pain to integrate patches on a faster release schedule >than Python's while remaining sane at the same time. You know, before you said that, it hadn't occurred to me that the Python standard library is subject to the same economic forces that cause mega-packages like Twisted, SciPy, Zope, etc. to develop. Specifically, the cost incurred by relying on an externally-distributed dependency causes anyone with non-trivial needs to create "batteries included" libraries. One of my goals for Python Eggs and EasyInstall was to lower this dependency-cost barrier by reducing the "dependency cost" to zero at the point of installation, by making it as easy to install ten packages as one. (Another was to reduce the dependency cost for the developer, who need only add package metadata for the dependency to be fulfilled at installation time.) Now that you've pointed out the parallel between the stdlib and the other modules, I wonder if Python 3.0 might be able to take a more minimalist approach to the standard library, if it included the equivalents of easy_install and pkg_resources. ___ 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] Thoughts on stdlib evolvement
On 6/6/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > - Flat namespace: Should we tend to a more hierarchic library (e.g. > inet.url, inet.http, inet.nntp)? This would increase clarity when > searching for a module. -1. I feel the opposite way: when trying to figure out where something "lives", I prefer Python's flat namespace to (for example) Java's com.company.baz.bar.foo hierarchy. > - 3rd party modules: There are many superb modules out there, some of which > really do have a "standard" character. Examples include PIL, numarray, > ElementTree, [wxPython - I know this is a hairy issue], I think the most important question for each of these is "is the module's release schedule at least as stable as Python's?". For many of these, I suspect the answer is "no". -- Tim Lesher <[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] Thoughts on stdlib evolvement
On Jun 6, 2005, at 3:10 PM, Raymond Hettinger wrote: >>> If Fred were up for it, I think ElementTree would be a wonderful, >>> must-have addition. >>> > > > >> I might be missing fine details of the English language here >> (what does "to be up for something" mean?), however, I believe >> ElementTree is an unlikely addition to the standard library. >> > > Rewritten: > > If Fredrik Lundh were supportive of the idea, I think the Standard > Library would benefit greatly from incorporating ElementTree. > Personally I'd like to see the standard library get smaller rather than larger. There's a whole lot of bit rot in there, and since sys.path prefers the standard library over anything else it's a really huge pain to integrate patches on a faster release schedule than Python's while remaining sane at the same time. -bob ___ 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] Thoughts on stdlib evolvement
> > If Fred were up for it, I think ElementTree would be a wonderful, > > must-have addition. > I might be missing fine details of the English language here > (what does "to be up for something" mean?), however, I believe > ElementTree is an unlikely addition to the standard library. Rewritten: If Fredrik Lundh were supportive of the idea, I think the Standard Library would benefit greatly from incorporating ElementTree. 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] Thoughts on stdlib evolvement
Raymond Hettinger wrote: >> ElementTree, [wxPython - I know this is a hairy issue], > > > If Fred were up for it, I think ElementTree would be a wonderful, > must-have addition. I might be missing fine details of the English language here (what does "to be up for something" mean?), however, I believe ElementTree is an unlikely addition to the standard library. I also might be confusing people: AFAIK, ElementTree is Fredrik Lundh's work, not Fred Drake's, so it would be Fredrik who would need to contribute. My understanding is that Fredrik has indicated a dislike to contribute certain pieces of work, primarily out of fear to lose control. My experience with integrating his work without his explicit cooperation (specifically: sgmlop in PyXML) show that he won't object to somebody else doing such integration, but also won't try to cooperate afterwards. Regards, Martin ___ 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] Thoughts on stdlib evolvement
Skip Montanaro wrote:
> The main technical challenge seems to be
> backward compatibility. You need to support both flat ("import
> urllib") and
> packaged namespaces ("from www import urllib"), possibly within the
> same
> application. That is, postulating a www package, if I execute
>
> import urllib
> from www.urllib import urlopen
>
> the module-level code should only be executed once, and
>
> urlopen == urllib.urlopen
>
> should evaluate to True.
Unless
from __future__ import new_std_library
and we don't allow mixed use within the same module.
--eric
___
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] Thoughts on stdlib evolvement
> "Barry" == Barry Warsaw <[EMAIL PROTECTED]> writes: Barry> On Mon, 2005-06-06 at 14:38, Skip Montanaro wrote: >> import urllib >> from www.urllib import urlopen >> >> the module-level code should only be executed once, and >> >> urlopen == urllib.urlopen >> >> should evaluate to True. Barry> Not to mention "urlopen is urllib.urlopen" Whoops, yeah. I was thinking in terms of module-level functions and classes, where I think == is sufficient: >>> import foo2 >>> foo2.f >>> g = foo2.f >>> reload(foo2) >>> foo2.f == g False Obviously, for data objects "is" is what you want. Skip ___ 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] Thoughts on stdlib evolvement
On Mon, 2005-06-06 at 14:38, Skip Montanaro wrote: > import urllib > from www.urllib import urlopen > > the module-level code should only be executed once, and > > urlopen == urllib.urlopen > > should evaluate to True. Not to mention "urlopen is urllib.urlopen" -Barry signature.asc Description: This is a digitally signed message part ___ 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] Thoughts on stdlib evolvement
Reinhold> - Flat namespace: Should we tend to a more hierarchic library
Reinhold> (e.g. inet.url, inet.http, inet.nntp)? This would increase
Reinhold> clarity when searching for a module.
We've talked about this before. The main technical challenge seems to be
backward compatibility. You need to support both flat ("import urllib") and
packaged namespaces ("from www import urllib"), possibly within the same
application. That is, postulating a www package, if I execute
import urllib
from www.urllib import urlopen
the module-level code should only be executed once, and
urlopen == urllib.urlopen
should evaluate to True.
Reinhold> - 3rd party modules: There are many superb modules out there,
Reinhold> some of which really do have a "standard"
Reinhold> character. Examples include PIL, numarray, ElementTree,
Reinhold> [wxPython - I know this is a hairy issue],
I think a good first step would be deciding on a package hierarchy. Third
party packages could plug in wherever they fit best.
Skip
___
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] Thoughts on stdlib evolvement
> - 3rd party modules: There are many superb modules out there, some of > which > really do have a "standard" character. Examples include PIL, numarray, > ElementTree, [wxPython - I know this is a hairy issue], If Fred were up for it, I think ElementTree would be a wonderful, must-have addition. Raymond Hettinger ___ 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
