Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)
On Sun, Mar 16, 2008 at 7:06 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > So, if the consensus is that it would be better to have a module that > only does bootstrap installs of pure-Python eggs from PyPI, I'm > totally fine with that. Let's just do this; it will avoid a protracted discussion of the merits of eggs, pkg_resources, and setuptools. -- --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] PEP 365 (Adding the pkg_resources module)
At 08:48 AM 3/17/2008 -0500, Guido van Rossum wrote: >On Sun, Mar 16, 2008 at 7:06 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > So, if the consensus is that it would be better to have a module that > > only does bootstrap installs of pure-Python eggs from PyPI, I'm > > totally fine with that. > >Let's just do this; it will avoid a protracted discussion of the >merits of eggs, pkg_resources, and setuptools. Well, it might be replaced by a protracted discussion of how the module should work and what its API should be, but perhaps that would be a better one to have. :) So, the original proposal (from the previous thread about this) was that the module be named easy_install, and that it simply downloads setuptools and delegates to the "real" easy_install. That way, people can simply use "python -m easy_install ...", without worrying about whether setuptools has been installed yet. IIRC, other package management tools such as zc.buildout and workingenv can then be installed using easy_install. Any objections? Should I revise the PEP? ___ 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] [Python-3000] 2.6 and 3.0 project management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 16, 2008, at 6:46 PM, Barry Warsaw wrote: > > 'critical' is fine (or 'immediate'). My problem before was that I > couldn't do one query that gave me all the critical issues for both > 2.6 and 3.0. That certainly could have been pebkac though. Neal > mentioned that that kind of query should be possible, if it's not > already there. So, I just looked again and that wasn't quite my problem. When you search, it seems like you have a choice of version "don't care" or you can pick a single version. But it looks like once you're on the search results you can further refine the version filter via the list box. It's a little clunky, but it'll work. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR95/y3EjvBPtnXfVAQKlmgQAg+1azln0Ljb32iyoreALUwepHwrN0XLp Fg6OVPp70iYIhctFhT3QYAN+59wzqy8x2PKsuZV/k48ebsJWwLsbU1yHH0WImHoo 56Dso3sfbsj2GzK7i3cF903RiIVE4geQRbnttDnrQVmI9U3jrs9iyWMjw/5Znohz DtLTEEf2fQs= =mQXt -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] PEP 365 (Adding the pkg_resources module)
> Well, it might be replaced by a protracted discussion of how the > module should work and what its API should be, but perhaps that would > be a better one to have. :) Indeed, that's likely to happen :-) > So, the original proposal (from the previous thread about this) was > that the module be named easy_install, and that it simply downloads > setuptools and delegates to the "real" easy_install. That way, > people can simply use "python -m easy_install ...", without worrying > about whether setuptools has been installed yet. I thought the original proposal was to install a *binary* easy_install that takes that function. > IIRC, other package management tools such as zc.buildout and > workingenv can then be installed using easy_install. > > Any objections? Should I revise the PEP? I'm fine with the module, but would really like to see a command line utility in addition. This, of course, would raise the issue who "owns" the easy_install script name; ideally, the script would not have to be overwritten when setuptools gets installed. 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] PEP 365 (Adding the pkg_resources module)
At 09:45 AM 3/17/2008 -0500, Martin v. Löwis wrote: > > Well, it might be replaced by a protracted discussion of how the > > module should work and what its API should be, but perhaps that would > > be a better one to have. :) > >Indeed, that's likely to happen :-) > > > So, the original proposal (from the previous thread about this) was > > that the module be named easy_install, and that it simply downloads > > setuptools and delegates to the "real" easy_install. That way, > > people can simply use "python -m easy_install ...", without worrying > > about whether setuptools has been installed yet. > >I thought the original proposal was to install a *binary* easy_install >that takes that function. What do you mean by "binary"? I thought we were talking about a module. Do you mean a script to be installed alongside Python itself in e.g. /usr/bin? In the original discussion, it was a module to be added alongside pkg_resources, which would use pkg_resources to find and/or install setuptools. I also personally like the use of -m instead of a script because it makes it quite clear that this is a Python-specific installation tool, and *which* version of Python, as well, without having to have easy_install-2.5, easy_install-2.6, etc. > > IIRC, other package management tools such as zc.buildout and > > workingenv can then be installed using easy_install. > > > > Any objections? Should I revise the PEP? > >I'm fine with the module, but would really like to see a command >line utility in addition. > >This, of course, would raise the issue who "owns" the easy_install >script name; ideally, the script would not have to be overwritten >when setuptools gets installed. It won't have to. The module will attempt to import the setuptools-supplied version of easy_install, and delegate to it if possible, before trying to do any download. ___ 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] PEP 365 (Adding the pkg_resources module)
>> I thought the original proposal was to install a *binary* easy_install >> that takes that function. > > What do you mean by "binary"? I thought we were talking about a > module. Do you mean a script to be installed alongside Python itself in > e.g. /usr/bin? Exactly so. > In the original discussion, it was a module to be added alongside > pkg_resources, which would use pkg_resources to find and/or install > setuptools. I also personally like the use of -m instead of a script > because it makes it quite clear that this is a Python-specific > installation tool, and *which* version of Python, as well, without > having to have easy_install-2.5, easy_install-2.6, etc. If that becomes the official interface to easy_install, that's fine with me. I'm worried about web instructions that tell people that there is an "easy_install" utility, so that people never find out the module actually exists. 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] PEP 365 (Adding the pkg_resources module)
I don't think this should play games with scripts being overridden or whatever. If a bootstrap script is to be installed it should have a separate name. I'm not sure what the advantage is of a bootstrap script over "python -m bootstrap_module ..." though. The PEP suggests that other package managers also benefit. How do they benefit if the bootstrap script installs setuptools? That sounds like the bootstrap script would make setuptools the de-facto standard, which I'd like to avoid given the politics around this topic. I'd also like to avoid the specific name "easy_install" for any of this. That's a "brand name" (and a misleading one if you ask me, but that's politics again :-). --Guido On Mon, Mar 17, 2008 at 10:10 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 09:45 AM 3/17/2008 -0500, Martin v. Löwis wrote: > > > Well, it might be replaced by a protracted discussion of how the > > > module should work and what its API should be, but perhaps that would > > > be a better one to have. :) > > > >Indeed, that's likely to happen :-) > > > > > So, the original proposal (from the previous thread about this) was > > > that the module be named easy_install, and that it simply downloads > > > setuptools and delegates to the "real" easy_install. That way, > > > people can simply use "python -m easy_install ...", without worrying > > > about whether setuptools has been installed yet. > > > >I thought the original proposal was to install a *binary* easy_install > >that takes that function. > > What do you mean by "binary"? I thought we were talking about a > module. Do you mean a script to be installed alongside Python itself > in e.g. /usr/bin? > > In the original discussion, it was a module to be added alongside > pkg_resources, which would use pkg_resources to find and/or install > setuptools. I also personally like the use of -m instead of a script > because it makes it quite clear that this is a Python-specific > installation tool, and *which* version of Python, as well, without > having to have easy_install-2.5, easy_install-2.6, etc. > > > > > > IIRC, other package management tools such as zc.buildout and > > > workingenv can then be installed using easy_install. > > > > > > Any objections? Should I revise the PEP? > > > >I'm fine with the module, but would really like to see a command > >line utility in addition. > > > >This, of course, would raise the issue who "owns" the easy_install > >script name; ideally, the script would not have to be overwritten > >when setuptools gets installed. > > It won't have to. The module will attempt to import the > setuptools-supplied version of easy_install, and delegate to it if > possible, before trying to do any download. > > -- --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] PEP 365 (Adding the pkg_resources module)
At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote: >I don't think this should play games with scripts being overridden or >whatever. If a bootstrap script is to be installed it should have a >separate name. I'm not sure what the advantage is of a bootstrap >script over "python -m bootstrap_module ..." though. And -m also makes explicit: 1. that it's a Python-specific tool 2. which Python version it will apply to >The PEP suggests that other package managers also benefit. How do they >benefit if the bootstrap script installs setuptools? Because those other package managers depend, in fact, on setuptools, or at least pkg_resources... which was why the original proposal was to just include pkg_resources in the first place. :) >I'd also like to avoid the specific name "easy_install" for any of >this. That's a "brand name" (and a misleading one if you ask me, but >that's politics again :-). Ok, so if someone will propose a name and API for the thing, I'll implement it. (Assuming the proposed API is sane and reasonably implementable, of course.) ___ 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] PEP 365 (Adding the pkg_resources module)
On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote: > >I don't think this should play games with scripts being overridden or > >whatever. If a bootstrap script is to be installed it should have a > >separate name. I'm not sure what the advantage is of a bootstrap > >script over "python -m bootstrap_module ..." though. > > And -m also makes explicit: > > 1. that it's a Python-specific tool > 2. which Python version it will apply to Right! > >The PEP suggests that other package managers also benefit. How do they > >benefit if the bootstrap script installs setuptools? > > Because those other package managers depend, in fact, on setuptools, > or at least pkg_resources... which was why the original proposal was > to just include pkg_resources in the first place. :) On how much of pkg_resources do they depend? Or is that an unanswerable question? > >I'd also like to avoid the specific name "easy_install" for any of > >this. That's a "brand name" (and a misleading one if you ask me, but > >that's politics again :-). > > Ok, so if someone will propose a name and API for the thing, I'll > implement it. (Assuming the proposed API is sane and reasonably > implementable, of course.) Perhaps it can be called package_bootstrap? I don't know enough about the required functionality to propose an API, but here goes anyway. Would be reasonable for it to have a command line that allows you to specify a package name, optionally a version string, and (very) optionally a server to contact (specified as an URL?). It should default to the highest non-experimental version that's applicable to the current Python version (assuming there's an easy way to determine this; I don't want it to try and download different versions until one works). It should not handle any kind of dependency management or package management administration. It should be able to download a Python-only module or package and install it into site-packages (or perhaps elsewhere if so directed via another optional command line flag). It should support zip, tar and tar.gz/tgz files (and perhaps tar.bz2). It should simply unpack the zip/tar file using the zip or tar modules, and extract the package/module into site-packages in such a way that it can be imported directly without messing with sys.path. It should not mess with .pth files, setup.py scripts, or eggs. If the contents of the tar/zip file has a toplevel directory with version numbers in its name (e.g. Django-0.96.1) it should skip that and just use the subdirectory whose name is the "pure" package name (e.g. django). Does this make sense? I'm happy to take push-back, this is just something I cooked up off the top of my head based on my experience with manually installing packages. -- --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] [Distutils] PEP 365 (Adding the pkg_resources module)
On 17/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > >The PEP suggests that other package managers also benefit. How do they > >benefit if the bootstrap script installs setuptools? > > Because those other package managers depend, in fact, on setuptools, > or at least pkg_resources... which was why the original proposal was > to just include pkg_resources in the first place. :) I'm puzzled. We seem to be talking about adding a module to the stdlib whose basic function is to download and install setuptools? How is this better than just including setuptools in the stdlib? Personally, I have no problem per se with including setuptools in the stdlib. Maybe that means I miss the subtle benefit of this approach... I'm -1 on having a module which just installs setuptools. I'm +0 on including pkg_resources (as described in PEP 365) in the stdlib. I'm +lots on someone giving a clear explanation of the meaning and interrelationship of the various terms involved in this discussion (setuptools, easy_install, pkg_resources, eggs, "package managers" as distinct from setuptools, etc etc) so that the discussion gets some much-needed clarity :-( I'm -1 on adding anything until PEP 365 is updated to match what is being proposed, and then that amended PEP is submitted for discussion. 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] [Distutils] PEP 365 (Adding the pkg_resources module)
On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore <[EMAIL PROTECTED]> wrote: > On 17/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > >The PEP suggests that other package managers also benefit. How do they > > >benefit if the bootstrap script installs setuptools? > > > > Because those other package managers depend, in fact, on setuptools, > > or at least pkg_resources... which was why the original proposal was > > to just include pkg_resources in the first place. :) > > I'm puzzled. We seem to be talking about adding a module to the stdlib > whose basic function is to download and install setuptools? How is > this better than just including setuptools in the stdlib? I'm not in favor of this either. > Personally, I have no problem per se with including setuptools in the > stdlib. Maybe that means I miss the subtle benefit of this approach... > > I'm -1 on having a module which just installs setuptools. > I'm +0 on including pkg_resources (as described in PEP 365) in the stdlib. > > I'm +lots on someone giving a clear explanation of the meaning and > interrelationship of the various terms involved in this discussion > (setuptools, easy_install, pkg_resources, eggs, "package managers" as > distinct from setuptools, etc etc) so that the discussion gets some > much-needed clarity :-( Right. But finding someone who can explain all this is apparently hard. All the owners of package managers seem busy... > I'm -1 on adding anything until PEP 365 is updated to match what is > being proposed, and then that amended PEP is submitted for discussion. Well, if we can reach consensus here first on what to put into PEP 365 first I'd be fine with updating the PEP as an afterthought, especially of the consensus also comes with working code (hopefully less than 2500 lines :-). -- --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] [Distutils] PEP 365 (Adding the pkg_resources module)
> I'm puzzled. We seem to be talking about adding a module to the stdlib > whose basic function is to download and install setuptools? How is > this better than just including setuptools in the stdlib? I can do a review of such a module in an hour. To review setuptools (which I would have to do if it were to be included), I would likely need a week or so, full time. > Personally, I have no problem per se with including setuptools in the > stdlib. Maybe that means I miss the subtle benefit of this approach... Did you review setuptools and can vouch that it is written cleanly, follows the coding style, has correct documentation, and so on? 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] PEP 365 (Adding the pkg_resources module)
Guido van Rossum wrote: > It should be able to download a Python-only module or package and > install it into site-packages (or perhaps elsewhere if so directed via > another optional command line flag). It should support zip, tar and > tar.gz/tgz files (and perhaps tar.bz2). It should simply unpack the > zip/tar file using the zip or tar modules, and extract the > package/module into site-packages in such a way that it can be > imported directly without messing with sys.path. It should not mess > with .pth files, setup.py scripts, or eggs. Do you mean "existing eggs" or does that include the (potential .egg) package that is being installed? If I understood correctly, this bootstrap module currently supports installing eggs (although I'm not sure how they are supposed to work without the current way of keeping a .pth file). Is it *wanted* that eggs are being supported by core Python? Stefan ___ 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] [Distutils] PEP 365 (Adding the pkg_resources module)
On 17/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Personally, I have no problem per se with including setuptools in the > > stdlib. Maybe that means I miss the subtle benefit of this approach... > > Did you review setuptools and can vouch that it is written cleanly, > follows the coding style, has correct documentation, and so on? No, I concede that when I say "I have no problem" with including setuptools, I'm assuming that someone does that review - and there's no reason to assume that anyone will do that (that's why I say "I have no problem with" rather than "I want"). But I don't see any practical difference with including setuptools and including a module that installs setuptools. Would you be happy with the standard library including a module whose sole function was to install a package that you weren't happy to include directly in the standard library? I wouldn't, personally. 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] PEP 365 (Adding the pkg_resources module)
On Mon, Mar 17, 2008 at 11:55 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > It should be able to download a Python-only module or package and > > install it into site-packages (or perhaps elsewhere if so directed via > > another optional command line flag). It should support zip, tar and > > tar.gz/tgz files (and perhaps tar.bz2). It should simply unpack the > > zip/tar file using the zip or tar modules, and extract the > > package/module into site-packages in such a way that it can be > > imported directly without messing with sys.path. It should not mess > > with .pth files, setup.py scripts, or eggs. > > Do you mean "existing eggs" or does that include the (potential .egg) package > that is being installed? The latter. > If I understood correctly, this bootstrap module > currently supports installing eggs (although I'm not sure how they are > supposed to work without the current way of keeping a .pth file). My proposal is that the boostrap module only be able to install non-egg archives. > Is it *wanted* that eggs are being supported by core Python? No. There will be no egg support in the standard library. -- --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] [Distutils] PEP 365 (Adding the pkg_resources module)
On Mon, Mar 17, 2008 at 12:12 PM, Paul Moore <[EMAIL PROTECTED]> wrote: > But I don't see any practical difference with including setuptools and > including a module that installs setuptools. Would you be happy with > the standard library including a module whose sole function was to > install a package that you weren't happy to include directly in the > standard library? I wouldn't, personally. Actually it's quite different -- the user or administrator is in control and they can choose not to install setuptools. -- --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
[Python-Dev] Currently adding known 2.6 showstoppers to the tracker
Right now at the sprint I am going through a list of issues Neal and I compiled of what needs to happen to get 2.6/3.0 out the door (although the list is pretty much 2.6-specific). They are all being flagged as "immediate" priority. Hopefully it won't take too long to add all of them (although the list ain't short =). If you want to see the list, Martin added a pre-defined Showstoppers search to make it easy to list everything that is set to "immediate". -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] Currently adding known 2.6 showstoppers to the tracker
Great! I wonder though if these should really all be given "showstopper" priority. IMO things don't reach showstopper status until they are blocking the next release (alpha, beta or final). On Mon, Mar 17, 2008 at 12:28 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > Right now at the sprint I am going through a list of issues Neal and I > compiled of what needs to happen to get 2.6/3.0 out the door (although > the list is pretty much 2.6-specific). They are all being flagged as > "immediate" priority. Hopefully it won't take too long to add all of > them (although the list ain't short =). > > If you want to see the list, Martin added a pre-defined Showstoppers > search to make it easy to list everything that is set to "immediate". -- --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] PEP 365 (Adding the pkg_resources module)
At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote: >There will be no egg support in the standard library. Are there any qualifications on that statement, or is this in the same category as "from __future__ import braces"? ___ 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] PEP 365 (Adding the pkg_resources module)
On 17/03/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Mon, Mar 17, 2008 at 11:55 AM, Stefan Behnel <[EMAIL PROTECTED]> wrote: > > Is it *wanted* that eggs are being supported by core Python? > > No. There will be no egg support in the standard library. This bothers me somewhat. At a certain level, all that egg files are is zip files with a different extension - and the zipimport module and PEP 302 certainly do support them. There is a lot more conceptual baggage associated with the egg "brand name", but unless that extra is clearly specified, a statement like "there will be no egg support" doesn't mean much. My view on PEP 365 is that it offers a standard way of doing from pkg_resources import resource_string foo_config = resource_string(__name__, 'foo.conf') which is basically a version of foo_config = open(os.path.join(os.path.dirname(__file__),'foo.conf').read() which also supports PEP 302 importers such as zipimport. This has nothing to do with eggs, and everything to do with solidifying the support for cleanly handling PEP 302 importers. For me, that would be far more useful that a package download&installer (as I'm on Windows, I tend to use bdist_wininst installers, and a bootstrap module which gave no uninstall capability would suck for me). The sticking point here, is deciding what parts of pkg_resources are OK, and which constitute "egg support". It may not be possible to come to a clear understanding of this. But I remain -1 on any module that just does download and install, with no uninstall capability. I don't like *eggs* for precisely this reason! 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] PEP 365 (Adding the pkg_resources module)
On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote: > >There will be no egg support in the standard library. > > Are there any qualifications on that statement, or is this in the > same category as "from __future__ import braces"? IIUC eggs are a method of package management that includes support for dependencies, multiple versions, and C extensions in zip files, as well as conventions for naming these and for encoding metadata (e.g. how to find out the version or the dependencies). This whole set of conventions is IMO too much to include into the stdlib ATM -- if only because it has proved controversial in the past. Maybe a few years from now it will be no longer controversial and then my objections will disappear. -- --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] [Distutils] PEP 365 (Adding the pkg_resources module)
> But I don't see any practical difference with including setuptools and > including a module that installs setuptools. Would you be happy with > the standard library including a module whose sole function was to > install a package that you weren't happy to include directly in the > standard library? I wouldn't, personally. If the actual code is not in Python, I'm not responsible for it. I don't have to deal with bug reports, and I don't have to help users with that feature. As users want to get the functionality anyway, and out-of-the-box, I consider it a useful compromise. 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] Currently adding known 2.6 showstoppers to the tracker
On Mon, Mar 17, 2008 at 12:35 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Great! > > I wonder though if these should really all be given "showstopper" > priority. IMO things don't reach showstopper status until they are > blocking the next release (alpha, beta or final). > Fine by me. If Barry has no issue with that I will drop all of their priority to urgent. But until then I will just keep doing immediate and change them en-mass. -Brett > > > On Mon, Mar 17, 2008 at 12:28 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > Right now at the sprint I am going through a list of issues Neal and I > > compiled of what needs to happen to get 2.6/3.0 out the door (although > > the list is pretty much 2.6-specific). They are all being flagged as > > "immediate" priority. Hopefully it won't take too long to add all of > > them (although the list ain't short =). > > > > If you want to see the list, Martin added a pre-defined Showstoppers > > search to make it easy to list everything that is set to "immediate". > > -- > --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] Currently adding known 2.6 showstoppers to the tracker
Brett Cannon schrieb: > Right now at the sprint I am going through a list of issues Neal and I > compiled of what needs to happen to get 2.6/3.0 out the door (although > the list is pretty much 2.6-specific). They are all being flagged as > "immediate" priority. Hopefully it won't take too long to add all of > them (although the list ain't short =). > > If you want to see the list, Martin added a pre-defined Showstoppers > search to make it easy to list everything that is set to "immediate". In the past I've used "high" for beta/final show stoppers, "urgent" for show stoppers for the next release and "immediate" for critical bugs that either affects security or the current development process. I like to keep one priority reserved for issue that must be resolevd ASAP and within hours and not until the next release. 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] PEP 365 (Adding the pkg_resources module)
At 12:59 PM 3/17/2008 -0500, Guido van Rossum wrote: >On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby ><[EMAIL PROTECTED]> wrote: > > At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote: > > >There will be no egg support in the standard library. > > > > Are there any qualifications on that statement, or is this in the > > same category as "from __future__ import braces"? > >IIUC eggs are a method of package management that includes support for >dependencies, multiple versions, and C extensions in zip files, as >well as conventions for naming these and for encoding metadata (e.g. >how to find out the version or the dependencies). This whole set of >conventions is IMO too much to include into the stdlib ATM -- if only >because it has proved controversial in the past. Maybe a few years >from now it will be no longer controversial and then my objections >will disappear. So, does this mean that the bootstrap tool must not use eggs? That seems a little bit odd, in that setuptools will at least need its .egg-info directory to get installed, and all of the people who'll be using this initially will be using it precisely in order to have support for eggs... So, it might be simpler all around to just clear up the "controversy". To the best of my recollection, only MAL and MvL have ever objected on Python-Dev to the idea of supporting eggs. Note: I'm specifically segregating "egg support" from the topic of including setuptools or easy_install in the stdlib directly. There are many legitimate reservations and open questions about the latter, including availability of volunteer support, choice of defaults, whether to replace distutils with setuptools, etc. etc. I recognize and respect the validity of those issues, which is precisely why I withdrew setuptools from inclusion in Python 2.5. However, regarding support for eggs, my understanding is that there were only two objections to eggs -- even at the time of the 2.5 setuptools discussions. And even though MvL objects to the idea of eggs in *principle*, I didn't read his recent posts as objecting to having the bootstrap tool download and install eggs in *practice*. (Although I hope he will clarify that stance one way or the other.) That leaves MAL, whose objections to PEP 365 centered on the API (he said he was "+1 on the concepts being added to the stdlib, -1 on adding the module in its current state"). Among other concerns, he wanted pkg_resources to be split into pkgutil and a new "egglib" module. I don't have a problem with this in principle, if there were a pkg_resources module that reconstituted the merged API. (But there are some practical problems with that approach, such as trying to split namespace package support between two theoretically-unrelated modules.) I would guess, however, that MAL's issues with the pkg_resources API would not apply to a bootstrap module whose sole purpose was to download eggs and put them on sys.path. Or, perhaps he would object *more*, I don't know. We could certainly ask him, though. :) So, was there anyone else you were counting towards "controversy"? The only other person I recall objecting to setuptools in any way on Python-Dev was effbot, and IIUC his objections were practical/administrative re: supporting easy_install and setuptools, not to the idea of .egg support in general. In summary, I think the controversy on Python-Dev regarding .egg support has actually been over for some time now. ___ 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] PEP 365 (Adding the pkg_resources module)
On Mon, Mar 17, 2008 at 1:45 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:59 PM 3/17/2008 -0500, Guido van Rossum wrote: > >On Mon, Mar 17, 2008 at 12:45 PM, Phillip J. Eby > ><[EMAIL PROTECTED]> wrote: > > > At 12:17 PM 3/17/2008 -0500, Guido van Rossum wrote: > > > >There will be no egg support in the standard library. > > > > > > Are there any qualifications on that statement, or is this in the > > > same category as "from __future__ import braces"? > > > >IIUC eggs are a method of package management that includes support for > >dependencies, multiple versions, and C extensions in zip files, as > >well as conventions for naming these and for encoding metadata (e.g. > >how to find out the version or the dependencies). This whole set of > >conventions is IMO too much to include into the stdlib ATM -- if only > >because it has proved controversial in the past. Maybe a few years > >from now it will be no longer controversial and then my objections > >will disappear. > > So, does this mean that the bootstrap tool must not use eggs? Correct. > That > seems a little bit odd, in that setuptools will at least need its > .egg-info directory to get installed, and all of the people who'll be > using this initially will be using it precisely in order to have > support for eggs... I'm okay if setuptools, once it's been installed, runs some setup code that creates the .egg-info directory and whatever else. This means I'm also okay with the bootstrap module finding and invoking that setup code. But I'm *not* okay with building any kind of egg management into the bootstrap module. The bootstrap module must be be neutral w.r.t. the package management style. > So, it might be simpler all around to just clear up the > "controversy". To the best of my recollection, only MAL and MvL have > ever objected on Python-Dev to the idea of supporting eggs. You can add my name to the list. I've heard plenty of people speak highly of eggs, but I've *also* heard from plenty of people (besides MAL and MvL) who have serious difficulties with the concept of eggs. I have certainly personally encountered plenty of situations where I wasn't able to complete an egg-based install because some dependency was broken (e.g. not available for the Python version I was using). > Note: I'm specifically segregating "egg support" from the topic of > including setuptools or easy_install in the stdlib directly. There > are many legitimate reservations and open questions about the latter, > including availability of volunteer support, choice of defaults, > whether to replace distutils with setuptools, etc. etc. I recognize > and respect the validity of those issues, which is precisely why I > withdrew setuptools from inclusion in Python 2.5. > > However, regarding support for eggs, my understanding is that there > were only two objections to eggs -- even at the time of the 2.5 > setuptools discussions. And even though MvL objects to the idea of > eggs in *principle*, I didn't read his recent posts as objecting to > having the bootstrap tool download and install eggs in > *practice*. (Although I hope he will clarify that stance one way or > the other.) You can do it in two stages. The bootstrap can download and install egg support, even though the bootstrap itself knows nothing about eggs. Then another bootstrap can download and install eggs. > That leaves MAL, whose objections to PEP 365 centered on the API (he > said he was "+1 on the concepts being added to the stdlib, -1 on > adding the module in its current state"). Among other concerns, he > wanted pkg_resources to be split into pkgutil and a new "egglib" > module. I don't have a problem with this in principle, if there were > a pkg_resources module that reconstituted the merged API. (But there > are some practical problems with that approach, such as trying to > split namespace package support between two theoretically-unrelated modules.) Well, you've heard my position now. > I would guess, however, that MAL's issues with the pkg_resources API > would not apply to a bootstrap module whose sole purpose was to > download eggs and put them on sys.path. Or, perhaps he would object > *more*, I don't know. We could certainly ask him, though. :) No need. I object to this myself. > So, was there anyone else you were counting towards > "controversy"? The only other person I recall objecting to > setuptools in any way on Python-Dev was effbot, and IIUC his > objections were practical/administrative re: supporting easy_install > and setuptools, not to the idea of .egg support in general. > > In summary, I think the controversy on Python-Dev regarding .egg > support has actually been over for some time now. Not really. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/py
Re: [Python-Dev] PEP 365 (Adding the pkg_resources module)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guido van Rossum wrote: > On Mon, Mar 17, 2008 at 11:12 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >> At 10:53 AM 3/17/2008 -0500, Guido van Rossum wrote: >> >I don't think this should play games with scripts being overridden or >> >whatever. If a bootstrap script is to be installed it should have a >> >separate name. I'm not sure what the advantage is of a bootstrap >> >script over "python -m bootstrap_module ..." though. >> >> And -m also makes explicit: >> >> 1. that it's a Python-specific tool >> 2. which Python version it will apply to > > Right! > >> >The PEP suggests that other package managers also benefit. How do they >> >benefit if the bootstrap script installs setuptools? >> >> Because those other package managers depend, in fact, on setuptools, >> or at least pkg_resources... which was why the original proposal was >> to just include pkg_resources in the first place. :) > > On how much of pkg_resources do they depend? Or is that an > unanswerable question? > >> >I'd also like to avoid the specific name "easy_install" for any of >> >this. That's a "brand name" (and a misleading one if you ask me, but >> >that's politics again :-). >> >> Ok, so if someone will propose a name and API for the thing, I'll >> implement it. (Assuming the proposed API is sane and reasonably >> implementable, of course.) > > Perhaps it can be called package_bootstrap? I don't know enough about > the required functionality to propose an API, but here goes anyway. > > Would be reasonable for it to have a command line that allows you to > specify a package name, optionally a version string, and (very) > optionally a server to contact (specified as an URL?). It should > default to the highest non-experimental version that's applicable to > the current Python version (assuming there's an easy way to determine > this; I don't want it to try and download different versions until one > works). It should not handle any kind of dependency management or > package management administration. > > It should be able to download a Python-only module or package and > install it into site-packages (or perhaps elsewhere if so directed via > another optional command line flag). It should support zip, tar and > tar.gz/tgz files (and perhaps tar.bz2). It should simply unpack the > zip/tar file using the zip or tar modules, and extract the > package/module into site-packages in such a way that it can be > imported directly without messing with sys.path. It should not mess > with .pth files, setup.py scripts, or eggs. If the contents of the > tar/zip file has a toplevel directory with version numbers in its name > (e.g. Django-0.96.1) it should skip that and just use the subdirectory > whose name is the "pure" package name (e.g. django). > > Does this make sense? I'm happy to take push-back, this is just > something I cooked up off the top of my head based on my experience > with manually installing packages. > I would prefer to see it just: - Find a source distribution (the variants you specified) on the given server which matches the supplied version string, using the same semantics as the current 'pkg_resources' constraints. - Unpack the source distribution to a temp directory. - cd into that directory and use sys.executable to invoke 'setup.py install'. Any extra command-line arguments beyond those used to find the source distribution would be passed on to the 'install' command, which would allow alternate locations, etc. That makes the installation as much like a manual one as possible, and means that existing pacakges will be installable whether or not they know about setuptools, etc. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3sDr+gerLs4ltQ4RAhjWAKCbFP87mJN4UnVt0pzDs81JovVpoACdGI7A tohpRJnXah0/QnyQeYiqoYY= =9Cif -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] PEP 365 (Adding the pkg_resources module)
At 01:59 PM 3/17/2008 -0500, Guido van Rossum wrote: >I have certainly personally encountered plenty of situations where I >wasn't able to complete an egg-based install because some dependency >was broken (e.g. not available for the Python version I was using). That's odd -- setuptools-based installs should be able to find and install packages from source. I have noticed a recent phenomenon where new developers upload *only* an egg to PyPI, without the source, but that's usually short-lived until someone points it out to them. Do you happen to know what packages you had this problem with? >I'm okay if setuptools, once it's been installed, runs some setup code >that creates the .egg-info directory and whatever else. This means I'm >also okay with the bootstrap module finding and invoking that setup >code. But I'm *not* okay with building any kind of egg management into >the bootstrap module. The bootstrap module must be be neutral w.r.t. >the package management style. Ok, well then we'll have to invent a new kind of binary package, whose name isn't 'egg'. Supporting distutils source packages is almost certainly a non-starter, if you want to avoid bringing the rest of setuptools into play. The only way to correctly determine what a source package contains is to run its setup script... and running unboxed setup scripts isn't safe because there are people who hardcode paths (or more precisely, use bad ways of computing them) in their setup scripts. I'm not saying the tool needs to guard against *malicious* scripts, just badly-written ones. (Setuptools does this with its "sandboxing" module, when running source packages' setup scripts.) So, if source is out, then some binary format is needed, which means defining the conventions for said format... i.e. "eggs lite" or "egg substitutes". :) > > So, it might be simpler all around to just clear up the > > "controversy". To the best of my recollection, only MAL and MvL have > > ever objected on Python-Dev to the idea of supporting eggs. > >You can add my name to the list. I've heard plenty of people speak >highly of eggs, but I've *also* heard from plenty of people (besides >MAL and MvL) who have serious difficulties with the concept of eggs. I did say "on Python-Dev", and you implied that it was not controversial with you, except for the maintenance-related concerns. I'm not fighting about this, but I would rather you were straight-up with your objections rather than deferring it to a controversy that "might go away in a few years". That way, I could at least attempt to do something about the concerns. OTOH, if your objections were non-specific and likely to stay that way, then I could have at least not wasted your time with any of this. ___ 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] Currently adding known 2.6 showstoppers to the tracker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 17, 2008, at 12:28 PM, Brett Cannon wrote: > Right now at the sprint I am going through a list of issues Neal and I > compiled of what needs to happen to get 2.6/3.0 out the door (although > the list is pretty much 2.6-specific). They are all being flagged as > "immediate" priority. Hopefully it won't take too long to add all of > them (although the list ain't short =). > > If you want to see the list, Martin added a pre-defined Showstoppers > search to make it easy to list everything that is set to "immediate". Brett, I'm going to use "immediate" to mark issues that must be fixed before the next release, which includes alpha releases. So I think "urgent" is a better priority to use for things that have to get fixed in 2.6/3.0. We can bounce these issues up higher if we want to fix them before the next alpha of course. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR97KeXEjvBPtnXfVAQKcCAP/YxZ7LQJepi9pg5IONjg1NePJSWwqggG7 rdFexmeHVockllBr5GMMmYgnr+jytnNDtRMTdy/uBvn3Ocl8+JRUHb5g/sDz2KQr usHcHnqIgkoQIgBnHGjnOg6nWmrn1CsAxJBMFuw3vcOksoYsJDdPiy+67GtJ0XIh ClZGJ8zbQQg= =Li3K -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] [Distutils] PEP 365 (Adding the pkg_resources module)
Guido van Rossum wrote: > On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore <[EMAIL PROTECTED]> wrote: >> >> I'm +lots on someone giving a clear explanation of the meaning and >> interrelationship of the various terms involved in this discussion >> (setuptools, easy_install, pkg_resources, eggs, "package managers" as >> distinct from setuptools, etc etc) so that the discussion gets some >> much-needed clarity :-( > > Right. But finding someone who can explain all this is apparently > hard. All the owners of package managers seem busy... In preparing for my PyCon 2008 tutorial on eggs and buildout, I spent three full-time weeks carefully going over sources for distutils, setuptools and buildout to discover those aspects not documented. I can explain how they work, although I'm not sure this is the correct forum. I'd like to first offer my slides from my tutorial, 150 of them with detailed handout notes on many of them. http://wiki.python.org/moin/buildout/pycon2008_tutorial I'm happy to answer questions after that. I'm in the Hanada B room for OLPC at PyCon and on IRC #pycon. -Jeff ___ 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] [Distutils] PEP 365 (Adding the pkg_resources module)
At 02:44 PM 3/17/2008 -0500, Jeff Rush wrote: >Guido van Rossum wrote: > > On Mon, Mar 17, 2008 at 11:35 AM, Paul Moore <[EMAIL PROTECTED]> wrote: > >> > >> I'm +lots on someone giving a clear explanation of the meaning and > >> interrelationship of the various terms involved in this discussion > >> (setuptools, easy_install, pkg_resources, eggs, "package managers" as > >> distinct from setuptools, etc etc) so that the discussion gets some > >> much-needed clarity :-( > > > > Right. But finding someone who can explain all this is apparently > > hard. All the owners of package managers seem busy... > >In preparing for my PyCon 2008 tutorial on eggs and buildout, I spent three >full-time weeks carefully going over sources for distutils, setuptools and >buildout to discover those aspects not documented. I can explain how they >work, although I'm not sure this is the correct forum. I'd like to first >offer my slides from my tutorial, 150 of them with detailed handout notes on >many of them. > >http://wiki.python.org/moin/buildout/pycon2008_tutorial Wow. I am skimming over the 44-page one on setuptools, and that is definitely the most comprehensive doc anyone has produced on it, aside from the official docs. Thank you! ___ 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] PEP 365 (Adding the pkg_resources module)
On 17/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > That leaves MAL, whose objections to PEP 365 centered on the API (he > said he was "+1 on the concepts being added to the stdlib, -1 on > adding the module in its current state"). Among other concerns, he > wanted pkg_resources to be split into pkgutil and a new "egglib" > module. I don't have a problem with this in principle, if there were > a pkg_resources module that reconstituted the merged API. (But there > are some practical problems with that approach, such as trying to > split namespace package support between two theoretically-unrelated modules.) I would personally like to see such a separation. As one of the authors of PEP 302 (well, the documentation - Just did all of the implementation) I have an interest in strengthening the standard library's support for transparent use of PEP 302 importers. To that end, I would like to see such functions as pkg_resources.resource_string() standardised. That covers the pkgutil aspect of pkg_resources. The "egglib" side of things is where the controversy lies, IMHO. I have a (somewhat unfocussed) dislike of eggs, largely because of the lack of a package management tool to handle them. I can live with them or without them, and it doesn't bother me if others use them, but the thing that really, really bothers me is that the controversy (and yes, there is such) over eggs is hampering the adoption of the pkgutil side of pkg_resources. So from me, there's a strong +1 for the split of pkg_resources into additions to the existing pkgutil module, and an independent egglib. You say there are practical problems to doing this. OK, but could we not have a discussion on how to resolve those issues as they come up? Could the split not be initially into 3 parts - pkgutil (eg, resource_string), egglib, and "difficult"? Then there would be something concrete to discuss and resolve. 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] [Python-3000] xturtle and 3.0
Brett Cannon schrieb: > ... > The current plan is to introduce a tk package and turtle was to become > tk.turtle. xturtle, if picked up, can just take the place of the > current turtle at that location. > > -Brett > Hi Brett, as you probably can imagine, I'd like to try out xturtle.py with Python 2.6 Alas, I didn't succeed installing Python 2.6 correctly on my Windows machine using the Windows msi installer. Whereas I could start the python interpreter successfully it was impossible to use it to execute either idle.py nor turtle.py In the first case I got an import error: import _socket Import Error: DLL load failed in the second one likewise import _tkinter Import Error: DLL load failed A look on sys.path showed the DLLs directory to be present there. Do you have an explanation for this behaviour? What can I do to avoid it? Do I have to take some special action when installing the alpha release (I did it "for this user only")? With best regards, Gregor ___ 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] [Python-3000] xturtle and 3.0
On Mon, Mar 17, 2008 at 3:35 PM, Gregor Lingl <[EMAIL PROTECTED]> wrote: > > > Brett Cannon schrieb: > > ... > > > The current plan is to introduce a tk package and turtle was to become > > tk.turtle. xturtle, if picked up, can just take the place of the > > current turtle at that location. > > > > -Brett > > > Hi Brett, > > as you probably can imagine, I'd like to try out xturtle.py with Python 2.6 > Alas, I didn't succeed installing Python 2.6 correctly on my Windows > machine using > the Windows msi installer. > > Whereas I could start the python interpreter successfully it was > impossible to use it > to execute either idle.py nor turtle.py > > In the first case I got an import error: > > import _socket > Import Error: DLL load failed > > in the second one likewise > > import _tkinter > Import Error: DLL load failed > > A look on sys.path showed the DLLs directory to be present there. > Do you have an explanation for this behaviour? What can I do to > avoid it? Do I have to take some special action when installing the > alpha release (I did it "for this user only")? I don't use Windows so I can't help with that. But you might want to try a checkout and build from source. You can find instructions in the PCbuild directory. -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] [Python-3000] xturtle and 3.0
On 17/03/2008, Gregor Lingl <[EMAIL PROTECTED]> wrote: > as you probably can imagine, I'd like to try out xturtle.py with Python 2.6 > Alas, I didn't succeed installing Python 2.6 correctly on my Windows > machine using the Windows msi installer. > > Whereas I could start the python interpreter successfully it was > impossible to use it to execute either idle.py nor turtle.py It worked for me. I have Python 2.5 installed, so I did an install of Python 2.6a1 "for all users", but I deselected the "register extensions" option (which makes this the default Python). I then ran idle using C:\Apps\Python26\python C:\Apps\Python26\Lib\idlelib\idle.py This worked fine for me. > A look on sys.path showed the DLLs directory to be present there. > Do you have an explanation for this behaviour? What can I do to > avoid it? Do I have to take some special action when installing the > alpha release (I did it "for this user only")? This is my sys.path: >C:\Apps\Python26\python Python 2.6a1 (r26a1:61155, Mar 1 2008, 12:11:56) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', 'C:\\Apps\\Python26\\python26.zip', 'C:\\Apps\\Python26\\DLLs', 'C:\\Apps\\Python26\\lib', 'C:\\Apps\\Python26\\lib\\plat-win', 'C:\\Apps\\Python26\\lib\\lib-tk', 'C:\\Apps\\Python26', 'C:\\Apps\\Python26\\lib\\site-packages'] I don't see why "for this user only" should work any differently. No, I just tried it and it's OK as well. I can't see any reason why "register extensions" sould cause you a problem either. Can I suggest you uninstall and reinstall and see if that helps? Keep a log of what you didn, and if it's still a problem let me know and I'll see what I can do. Paul. PS What version of Windows are you on? I'm using XP Home (32 bit). If you're using 64-bit, I can't help, I'm afraid... ___ 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] Capsule Summary of Some Packaging/Deployment Technology Concerns
I was in a Packaging BoF yesterday and, although not very relevant to the packager bootstrap thread, Guido has asked me to post some of the concerns. The BoF drew about 15 people, many of whom were packagers for Red Hat, Ubuntu and such. Everyone had strong expressions of frustration with the status quo and most had tried to resolve their issues but had their patches rejected. I am not taking either side and whether those rejections were justified I cannot say, but the general feeling of their concerns intentionally not being addressed isn't healthy. Several had abandoned setuptools, deeming it a failed solution and others called for a fork. To start, I am not a leader of the group nor do I claim I accurately captured and expressed all their concerns. I apologize to those in the BoF for any misrepresentations. 1. Many felt the existing dependency resolver was not correct. They wanted a full tree traversal resulting in an intersection of all restrictions, instead of a first-acceptable-solution approach taking now, which can result in top-level dependencies not being enforced upon lower levels. The latter is faster however. One solution would be to make the resolver pluggable. 2. People want a solution for the handling of documentation. The distutils module has had commented out sections related to this for several years. 3. A more flexible internal handing of the different types of files is needed. Currently the code, data, lib, etc. files are aggregated at build time and people would like them to be kept separate until install/packaging time. They also want greater flexibility in the kinds of files identified for packaging. There is currently a single plugin entrypoint for file_finding, so people have resorted to abusing the setuptools function find_packages() again and again with different include/exclude args. A solution is to expand the set of entrypoints into finer grained categories. They also want a way to expand the set of categories rather than a fixed set, which can be easily done with entrypoint groups and names. People also want a greater variety of file_finders to be included with setuptools. Instead of just CVS and SVN, they want it to comprehend Mercurial, Bazaar, Git and so forth. 4. They want an uninstall setuptools command. Adding one to remove a specific egg isn't difficult but correctly removing those dependencies that came in with that egg, without breaking later installs can be tricky. This is complicated because there isn't a single global package namespace to manage, when you factor in virtualenv and buildout sandboxes and per-user package areas. This differs from how RPMs and .debs are viewed. 5. There was concern over the .pth mechanism used by setuptools re activation. First, there is a (perceived) performance issue with increasingly adding every ZIP file explicitly onto sys.path. This may or may not be a red herring. The other is the use of a single .pth file to control the list of activated packages. Those who produce distributions would prefer a magic directory into which links to distributions could be dropped, similar to the current best practices for Linux, with /etc/conf.d/, /etc/profile.d/, /etc/xinetd.d/ and so forth. 6. There is a need for more extensibility hooks. People want places to plug in special handling. For example: a) setuptools has a --record option to capture the list of files installed for use by subsequent packaging tools. Some want that list to be available to a setuptools plugin. b) some want hooks for post-build/post-install actions, instead of the current approach of writing a custom build class that handles it all. 7. Many wanted to ability to install files anywhere in the install tree and not just under the Python package. Under distutils this was possible but it was removed in setuptools for security reasons. Custom code can still be written to do this explicitly but this is not popular. Neither setuptools nor distutils has the ability to rename files at install time. A fair question is whether it is the job of setuptools (or any Python packaging solution) to cover all these bases. The risk of not doing the job is that some of those in attendance were rolling their own solutions which do not play well with packages installed using other means, not seeing them. Distutils has intentionally tried to -not- be a general replacement packaging solution, with its support of the "bdist" command for various platform-specific distribution formats. We should continue not trying to replace platform-specific packaging technologies but perhaps improve our control of their creation. As mentioned, some of these concerns can be resolved by adding customization-pressure-release entrypoints to setuptools, and some can be handled with much be
[Python-Dev] Installing Python 2.6 alpha1 on Windows XP
Hi Paul, thanks for you efforts, but up to now it still didn't work. I'm using Windows XP Professional (32 bit). I tried an install on two different machines with the same negative result. I proceeded like you suggested. - I installed for all users, - I disabled the register extensions When doing the same call to execute idle as you, I got the following: Traceback (most recent call last): File "c:\Python26\Lib\idlelib\idle.py", line 6, in import PyShell File "c:\Python26\Lib\idlelib\PyShell.py", line 9, in import socket File "c:\Python26\Lib\socket.py", line 46, in import _socket ImportError: DLL load failed: I get a similar error message, when I do from turtle import * with ... import _tkinter Import Error. DLL load failed sys.path is exactly like yours. (So the DLLs directory is contained in sys.path) _tkinter.pyd and _socket.pyd are present in DLLs. I've installed Python 2.5 on both machines. On the first one I moreover deleted all entries concerning Python (2.5) from the PATH variable, with no positive effect. On the other machine I have also installed Python 3000 successfully, which even still doesn't have IDLE in it's Menu. Nevertheless there C:\Python30> python Lib\idlelib\idle.py brings up IDLE 3.0a1 (and I even can import and use a port of xturtle.py to Python 3000 there). I never experienced a similar Problem before when installing Python. Any ideas? Regards, Gregor ___ 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] New/Old class exception pitfall
While discussing issue2291, I presented the following argument: """ Consider the following code: class x: pass class y(x): pass try: raise y except y: print "a" except: print "b" It prints 'b'. Now, suppose in preparation for 3.0 transition someone adds "__metaclass__ = type" to the module with that code. The result: it prints 'a'. Since the difference in behavior is in error handling code, which in my experience is often not thoroughly tested, the bug introduced by a seemingly innocuous move from old to new style classes is likely to trigger in the worst possible moment. (For example a wrong roll-back logic is applied after a failed database commit.) """ http://bugs.python.org/msg63584 This issue is only partially alleviated by the -3 warning because the warning is not issued unless the error condition raising a new style class not deriving from BaseException is actually tested for. It is my understanding that subclass check is skipped for new style classes not derived from BaseException in order to enable the identity check when a string exception is caught. With the deprecation of string exceptions, this logic is hard to justify. In any case, I believe this issue is either code or documentation bug: """ Exceptions are identified by class instances. The except clause is selected depending on the class of the instance: it must reference the class of the instance or a base class thereof. """ http://docs.python.org/dev/reference/executionmodel.html#id2 I don't see anything in the documentation that would suggest that old and new class instances should behave differently. ___ 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] New/Old class exception pitfall
On Mon, Mar 17, 2008 at 5:35 PM, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > While discussing issue2291, I presented the following argument: > > """ > Consider the following code: > > class x: > pass > class y(x): > pass > try: > raise y > except y: > print "a" > except: > print "b" > > It prints 'b'. Really? Under which version exactly? On which platform? I cannot reproduce this with either 2.4, 2.5 or 2.6 on OS X. > Now, suppose in preparation for 3.0 transition someone > adds "__metaclass__ = type" to the module with that code. The result: > it prints 'a'. Which one would expect regardless of the metaclass, right? > Since the difference in behavior is in error handling > code, which in my experience is often not thoroughly tested, the bug > introduced by a seemingly innocuous move from old to new style classes > is likely to trigger in the worst possible moment. (For example a wrong > roll-back logic is applied after a failed database commit.) > """ http://bugs.python.org/msg63584 > > This issue is only partially alleviated by the -3 warning because the warning > is not issued unless the error condition raising a new style class not > deriving > from BaseException is actually tested for. > > It is my understanding that subclass check is skipped for new style classes > not derived from BaseException in order to enable the identity check when a > string exception is caught. I have no idea what you are talking about. Can you quote a file, revision and line number where this is done? > With the deprecation of string exceptions, this logic is hard to justify. > > In any case, I believe this issue is either code or documentation bug: > > """ > Exceptions are identified by class instances. The except clause is > selected depending on the class of the instance: it must reference the class > of > the instance or a base class thereof. > """ http://docs.python.org/dev/reference/executionmodel.html#id2 > > I don't see anything in the documentation that would suggest that old and new > class instances should behave differently. Me neither. -- --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] New/Old class exception pitfall
On Mon, Mar 17, 2008 at 06:35:46PM -0400, Alexander Belopolsky wrote: > class x: > pass > class y(x): > pass > try: > raise y > except y: > print "a" > except: > print "b" > > It prints 'b'. Python 2.2, 2.3, 2.4 and 2.5 on Linux: prints 'a'. 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] New/Old class exception pitfall
On Mon, Mar 17, 2008 at 6:49 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
..
> Really? Under which version exactly? On which platform? I cannot
> reproduce this with either 2.4, 2.5 or 2.6 on OS X.
Just retested in
Python 2.6a1+ (trunk:61449M, Mar 17 2008, 17:29:21)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
and
Python 2.5 (r25:51908, Nov 24 2006, 11:03:50)
[GCC 3.4.4 20050721 (Red Hat 3.4.4-2)] on linux2
I don't have my PowerBook here, but I am sure I've seen in on Mac OS
too. Only new-style class behavior is problematic. The following
code prints 'b' for me:
__metaclass__ = type
class x:
pass
class y(x):
pass
try:
raise y
except y:
print "a"
except:
print "b"
> Which one would expect regardless of the metaclass, right?
Yes.
> I have no idea what you are talking about. Can you quote a file,
> revision and line number where this is done?
>
Sorry for the lack of details. The code in question is at
trunk/Python/errors.c:108 as of r61467:
"""
if (PyExceptionClass_Check(err) && PyExceptionClass_Check(exc)) {
/* problems here!? not sure PyObject_IsSubclass expects to
be called with an exception pending... */
return PyObject_IsSubclass(err, exc);
}
return err == exc;
"""
(flushed left hoping it won't get garbled)
As you can see, subclass check is only performed if
PyExceptionClass_Check(err) passes, which includes a check for err
being derived from BaseException (see Include/pyerrors.h). This logic
allows returning err == exc when err is a string.
___
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] New/Old class exception pitfall
On Mon, Mar 17, 2008 at 07:18:25PM -0400, Alexander Belopolsky wrote: > I don't have my PowerBook here, but I am sure I've seen in on Mac OS > too. Only new-style class behavior is problematic. The following > code prints 'b' for me: > > __metaclass__ = type Ah, yes - with this addition it prints 'b'. > class x: > pass > class y(x): > pass > try: > raise y > except y: > print "a" > except: > print "b" 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] Installing Python 2.6 alpha1 on Windows XP
On 17/03/2008, Gregor Lingl <[EMAIL PROTECTED]> wrote: > When doing the same call to execute idle as you, I got the following: > > Traceback (most recent call last): > File "c:\Python26\Lib\idlelib\idle.py", line 6, in > import PyShell > File "c:\Python26\Lib\idlelib\PyShell.py", line 9, in > import socket > File "c:\Python26\Lib\socket.py", line 46, in > import _socket > ImportError: DLL load failed: Can you try running C:\Python26\python.exe, and then at the interpreter prompt, execute: import sys print sys.path import socket and post the results? I expect you will get the same error about _socket not being loadable, but I'd like to check. Also can you try just "import _socket"? What is the size of _socket.pyd - mine is 44,032 bytes. Another thought - do you have any copies of msvcr90.dll on your PATH? I don't think it'll make a difference, but if you do can you try renaming them? > I never experienced a similar Problem before when installing Python. > > Any ideas? Not many :-( One final thought, what is the value of your PATH variable? Mine has no Python entries in it at all - that's normal, the Python installer doesn't set PATH. Sorry I can't be of more help, 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] New/Old class exception pitfall
Oleg Broytmann phd.pp.ru> writes: > > On Mon, Mar 17, 2008 at 06:35:46PM -0400, Alexander Belopolsky wrote: > > class x: > > pass > > class y(x): > > pass > > try: > > raise y > > except y: > > print "a" > > except: > > print "b" > > > > It prints 'b'. > >Python 2.2, 2.3, 2.4 and 2.5 on Linux: prints 'a'. > Sorry, my fault. It prints 'a' without __metaclass__ = type, but prints 'b' with the metaclass. The output should be the same in both cases. The problematic case is: __metaclass__ = type class x: pass class y(x): pass try: raise y except y: print "a" except: print "b" the above code prints 'b' in 2.x ___ 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] Installing Python 2.6 alpha1 on Windows XP
Paul Moore schrieb: > On 17/03/2008, Gregor Lingl <[EMAIL PROTECTED]> wrote: >> When doing the same call to execute idle as you, I got the following: >> >> Traceback (most recent call last): >> File "c:\Python26\Lib\idlelib\idle.py", line 6, in >> import PyShell >> File "c:\Python26\Lib\idlelib\PyShell.py", line 9, in >> import socket >> File "c:\Python26\Lib\socket.py", line 46, in >> import _socket >> ImportError: DLL load failed: > > Can you try running C:\Python26\python.exe, and then at the > interpreter prompt, execute: > > import sys > print sys.path > import socket > > and post the results? > >>> import sys >>> print sys.path ['', 'C:\\Python26\\python26.zip', 'C:\\Python26\\DLLs', 'C:\\Python26\\lib', ] 'C:\\Python26\\lib\\plat-win', 'C:\\Python26\\lib\\lib-tk', 'C:\\Python26', 'C:\\Python26\\lib\\site-packages'] >>> import socket Traceback (most recent call last): File "", line 1, in File "C:\Python26\lib\socket.py", line 46, in import _socket ImportError: DLL load failed: Das System kann die angegebene Datei nicht finden. ;-) :-( >>> > I expect you will get the same error about _socket not being loadable, > but I'd like to check. Also can you try just "import _socket"? > >>> import _socket Traceback (most recent call last): File "", line 1, in ImportError: DLL load failed: Das System kann die angegebene Datei nicht finden. > What is the size of _socket.pyd - mine is 44,032 bytes. > The same > Another thought - do you have any copies of msvcr90.dll on your PATH? > I don't think it'll make a difference, but if you do can you try > renaming them? > > No I don't! Only in c:\Python26, in c:\Python30 and on c:\Python30\DLLs. Strange that there are two copies of msvcr90.dll in Python30. So I'll copy this beast also to C:\Python26\DLLs, and ... it works! I can import socket and I even can start IDLE from the Python2.6 Menu Thanks for your advice. Do you have an idea if this is a 'bug' in the installer? Why the differences between 2.6 and 3000. Why two copies of that .dll in Python 30.0? I'm rather happy now :-) Have a nice evening. (Here in Vienna it's already 0:51 am.) All the best Gregor >> I never experienced a similar Problem before when installing Python. >> >> Any ideas? >> > > Not many :-( > > One final thought, what is the value of your PATH variable? Mine has > no Python entries in it at all - that's normal, the Python installer > doesn't set PATH. > > Sorry I can't be of more help, > 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
[Python-Dev] 3rd party developers: don't change your APIs when porting to Py3k!
For those who don't read blogs, I just blogged the slides for my keynote, and added an important admonishment to 3rd party developers. Here's the full text of the blog: The slides of my `keynote`_ are now up on python.org. There's both a `PowerPoint`_ and a `PDF`_ file. .. _keynote: http://www.python.org/doc/essays/ppt/ .. _PowerPoint: http://www.python.org/doc/essays/ppt/pycon2008/Py3kAndYou.ppt .. _PDF: http://www.python.org/doc/essays/ppt/pycon2008/Py3kAndYou.pdf I'd like to take this opportunity to remind you of a really important issue that I neglected to mention in the talk: **Don't change your APIs incompatibly when porting to Py3k.** Yes, you heard that right: even though Python 3.0 is changing incompatibly, I implore you (especially if you're maintaining a library that's used by others) *not* to make incompatible changes to your API. If you *have* make API changes, do them *before* you port to 3.0 -- release a version with the new API for Python 2.5, or 2.6 if you must. (Or do it later, *after* you've released a port to 3.0 without adding new features.) Why? Think of your users. Suppose Ima Lumberjack has implemented a web 2.0 app for managing his sawmill. Ima is a happy user of your most excellent web 2.0 framework. Now Ima wants to upgrade his app to Py3k. He waits until you have ported your framework to Py3k. He does everything by the books, runs his source code through the 2to3 tool, and starts testing. Imagine his despair when the tests fail: how is he going to tell whether the breakage is due to your API changes or due to his own code not being Py3k-ready? On the other hand, if port your web 2.0 framework to Py3k *without* making API changes, Ima's task is much more focused: the bugs he is left with after running 2to3 are definitely in his own code, which (presumably :-) he knows how to debug and fix. The same recommendation applies even more strongly if your library is a dependency for other libraries -- due to the fan-out the pain caused to others multiplies. If one of those packages gives up (even temporarily) its Py3k porting effort, this may prevent many other libraries and apps from being ported at all! So, once more for emphasis: **Don't change your APIs at the same time as porting to Py3k!** *PS.* The 3.0final release is now scheduled for September 3, 2008. See `PEP 361`_. .. _PEP 361: http://python.org/dev/peps/pep-0361/ -- --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] Capsule Summary of Some Packaging/Deployment Technology Concerns
At 05:10 PM 3/17/2008 -0500, Jeff Rush wrote: >I was in a Packaging BoF yesterday and, although not very relevant to the >packager bootstrap thread, Guido has asked me to post some of the concerns. > >The BoF drew about 15 people, many of whom were packagers for Red Hat, Ubuntu >and such. Everyone had strong expressions of frustration with the status quo >and most had tried to resolve their issues but had their patches rejected. I >am not taking either side and whether those rejections were >justified I cannot >say, but the general feeling of their concerns intentionally not being >addressed isn't healthy. Several had abandoned setuptools, deeming it a >failed solution and others called for a fork. > >To start, I am not a leader of the group nor do I claim I accurately captured >and expressed all their concerns. I apologize to those in the BoF for any >misrepresentations. I'm actually happy to hear that there's this much energy available -- hopefully some of it can be harnessed towards positive solutions. When I began developing setuptools, I often asked for the input of packagers, developers, etc., through the distutils-sig... and was met with overwhelming silence. So the fact that there is now a group of people who are ready to work for some solutions seems like a positive change, to me. It's hard to make design decisions regarding itches you don't personally have, and which other people won't help scratch. Unfortunately, a lot of the proposals from packaging system people have been of the form of, "fix this for us by breaking things for other people". Not all of them, though. Many have been very helpful, contributing troubleshooting help and good patches. That some of those good patches took nearly a year to get into setuptools (some from Fedora just got into 0.6c8 that were sent to me almost a year ago) is because I'm the only person reviewing setuptools patches, and I've spent only a few days in the last year doing focused development work on setuptools (as opposed to answering questions about it on the SIG). It's never a good thing when people's patches sit around, regardless of where they come from. But that's not the same thing as *rejecting* the patches. >1. Many felt the existing dependency resolver was not correct. They wanted a > full tree traversal resulting in an intersection of all restrictions, > instead of a first-acceptable-solution approach taking now, which can > result in top-level dependencies not being enforced upon lower > levels. The > latter is faster however. One solution would be to make the resolver > pluggable. Patches welcome, on both counts. Personally, Bob and I originally wanted a full-tree intersection, too, but it turned out to be hairier to implement than it seems at first. My guess is that none of the people who want it, have actually tried to implement it without a factorial or exponential O(). But that doesn't mean I'll be unhappy if somebody succeeds. :) Intuitively, it seems easy, just gather the requirements and intersect. In practice, different versions of a package may have different dependencies, so the intersection is not nearly as simple as that. We ended up just going for a depth-first version of the current algorithm (switched to breadth-first later, after field tests showed some problems with that), being greedy by testing latest-version-first, on the assumption that more recent versions would be likely to have the most-restrictive version requirements. In other words, we attempt to achieve heuristically what's being proposed to do algorithmically. And my guess is that whatever cases the heuristic is failing at, would probably not be helped by an algorithmic approach either. But I would welcome some actual data, either way. Again, though, patches are welcome. :) (Specifically, for the trunk; I don't see a resolver overhaul as being suitable for the 0.6 stable branch.) >2. People want a solution for the handling of documentation. The distutils > module has had commented out sections related to this for several years. As with so many other things, this gets tossed around the distutils-sig every now and then. A couple of times I've thrown out some options for how this might be done, but then the conversation peters out around the time anybody would have to actually do some work on it. (Me included, since I don't have an itch that needs scratching in this area.) In particular, if somebody wants to come up with a metadata standard for including documentation in eggs, we've got a boatload of hooks by which it could be done. Nothing's stopping anybody from proposing a standard and building a tool, here. (e.g. using the setuptools command hook, .egg-info writer hook, etc.) >3. A more flexible internal handing of the different types of files is needed. > Currently the code, data, lib, etc. files are aggregated at > build time and > people woul
[Python-Dev] xturtle and 2.6
Hi everyone, I happily like to report, that xturtle is running under Python 2.6 seemingly without any problems. Thanks to Paul Moore's advice I could get Python 2.6 running on my windows machine. I tested xturtle running those 30+ sample scripts, which are contained in the xturtle package with the included demoViewer and not a single (new) problem did occur. Quite a few of these samplescripts contain runtime measurements, which consistently showed that they ran 5 to 15% faster than under Python2.5 Regards, Gregor ___ 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] PEP 361: Python 2.6/3.0 release schedule
Greetings from Pycon 2008! Neal Norwitz and I have worked out the schedule for Python 2.6 and 3.0, which will be released in lockstep. We will be following a monthly release schedule, with releases to occur on the first Wednesday of the month. We'll move to a 2 week schedule for the release candidates. Executive summary: Python 2.6 and 3.0 finals are planned for September 3, 2008. PEP 361 contains all the gory details; from the PEP: Feb 29 2008: Python 2.6a1 and 3.0a3 are released Apr 02 2008: Python 2.6a2 and 3.0a4 planned May 07 2008: Python 2.6a3 and 3.0a5 planned Jun 04 2008: Python 2.6b1 and 3.0b1 planned Jul 02 2008: Python 2.6b2 and 3.0b2 planned Aug 06 2008: Python 2.6rc1 and 3.0rc1 planned Aug 20 2008: Python 2.6rc2 and 3.0rc2 planned Sep 03 2008: Python 2.6 and 3.0 final http://www.python.org/dev/peps/pep-0361/ This schedule gives everybody plenty of advanced notice, so you should be able to get your code in on time. Please be very careful about not breaking the branches. Neal and I will be cracking the whip of public shame when your commit turns the buildbots red. Embarrassing Pycon pictures of you will be posted if such broken revisions cause us to slip a release, and remember, we know how to use GIMP. On behalf of everyone, here's to an awesome release! -Barry Python 2.6/3.0 release manager PEP: 361 Title: Python 2.6 and 3.0 Release Schedule Version: $Revision: 61470 $ Last-Modified: $Date: 2008-03-17 19:27:00 -0500 (Mon, 17 Mar 2008) $ Author: Neal Norwitz, Barry Warsaw Status: Draft Type: Informational Created: 29-June-2006 Python-Version: 2.6 Python-Version: 3.0 Post-History: 17-Mar-2008 Abstract This document describes the development and release schedule for Python 2.6 and 3.0. The schedule primarily concerns itself with PEP-sized items. Small features may be added up to and including the first beta release. Bugs may be fixed until the final release. There will be at least two alpha releases, two beta releases, and one release candidate. The release date is planned for the beginning of September, 2008. Python 2.6 is not only the next advancement in the Python 2 series, it is also a transitional release, helping developers begin to prepare their code for Python 3.0. As such, many features are being backported from Python 3.0 to 2.6. Thus, it makes sense to release both versions in at the same time. The precedence for this was set with the Python 1.6 and 2.0 release. We will be releasing Python 2.6 and 3.0 in lockstep, on a monthly release cycle. The releases will happen on the first Wednesday of every month through the beta testing cycle. There will be two weeks between release candidates. The final releases of Python 2.6 and 3.0 will happen in lockstep. Release Manager and Crew 2.6/3.0 Release Manager: Barry Warsaw Windows installers: Martin v. Loewis Mac installers: Ronald Oussoren Documentation: Georg Brandl RPMs: Sean Reifschneider Release Schedule Note that this schedule is completely tentative. The number of alphas, betas and release candidates will be determined as the release process unfolds. The minimal schedule is: Feb 29 2008: Python 2.6a1 and 3.0a3 are released Apr 02 2008: Python 2.6a2 and 3.0a4 planned May 07 2008: Python 2.6a3 and 3.0a5 planned Jun 04 2008: Python 2.6b1 and 3.0b1 planned Jul 02 2008: Python 2.6b2 and 3.0b2 planned Aug 06 2008: Python 2.6rc1 and 3.0rc1 planned Aug 20 2008: Python 2.6rc2 and 3.0rc2 planned Sep 03 2008: Python 2.6 and 3.0 final Completed features for 3.0 See PEP 3000 [#pep3000] and PEP 3100 [#pep3100] for details on the Python 3.0 project. Completed features for 2.6 PEPs: 352: Raising a string exception now triggers a TypeError. Attempting to catch a string exception raises DeprecationWarning. BaseException.message has been deprecated. New modules in the standard library: None Deprecated modules and functions in the standard library: - buildtools - cfmfile - commands.getstatus() - macostools.touched() - md5 - MimeWriter - mimify - popen2, os.popen[234]() - posixfile - sets - sha Modules removed from the standard library: - gopherlib - rgbimg - macfs Python 3.0 compatability: - warnings were added for the following builtins which no longer exist in 3.0: apply, callable, coerce, dict.has_key, execfile, reduce, reload Other major features: - with/as will be keywords - a __dir__() special method to control dir() was added [1] - AtheOS support stopped. Possible features for 2.6 New features *should* be
Re: [Python-Dev] 3rd party developers: don't change your APIs when porting to Py3k! (but consider using ctypes)
I'm the maintainer of a few Python packages which wrap native C or C+ + code. At Pycon, I learned that PyPy and Jython support ctypes or have plans to do so in the near future. I don't know about IronPython. However, having CPython, PyPy, and Jython all supporting ctypes makes it the obvious choice for interfacing to native code in the future. Regards, Zooko O'Whielacronx ___ 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] 3rd party developers: don't change your APIs when porting to Py3k!
Now I apparently need an email reader that understands reStructuredText :-). Bill ___ 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] Change in priority fields
Barry, Neal, and myself had a conversation and changed the priority fields in the tracker. You can click on 'priority' to see an explanation, but the new fields are: - release blocker - critical - high - normal - low So "release blocker" blocks a release. "Critical" could very easily block a release, but not the current one. "High" issues should be addressed, but won't block anything. "Normal" is normal. And "low" is for spelling errors and such. -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] Change in priority fields
On Mon, Mar 17, 2008 at 9:10 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > Barry, Neal, and myself had a conversation and changed the priority > fields in the tracker. You can click on 'priority' to see an > explanation, but the new fields are: > > - release blocker > - critical > - high > - normal > - low > > So "release blocker" blocks a release. "Critical" could very easily > block a release, but not the current one. "High" issues should be > addressed, but won't block anything. "Normal" is normal. And "low" is > for spelling errors and such. Primarily everyone should use normal for issues that are, uh, normal. "Critical" should be used for bugs that are things like: crashing the interpreter, serious memory/reference leaks. "High" could be used for large problems with resource usage (too much memory) or something that is otherwise, important. n ___ 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] Change in priority fields
What do I do for something that should absolutely go into the 2.6final release (say) but is otherwise pretty minor? I've been using critical to make sure it doesn't get put off until past the release. On Mon, Mar 17, 2008 at 11:31 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On Mon, Mar 17, 2008 at 9:10 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > Barry, Neal, and myself had a conversation and changed the priority > > fields in the tracker. You can click on 'priority' to see an > > explanation, but the new fields are: > > > > - release blocker > > - critical > > - high > > - normal > > - low > > > > So "release blocker" blocks a release. "Critical" could very easily > > block a release, but not the current one. "High" issues should be > > addressed, but won't block anything. "Normal" is normal. And "low" is > > for spelling errors and such. > > Primarily everyone should use normal for issues that are, uh, normal. > "Critical" should be used for bugs that are things like: crashing the > interpreter, serious memory/reference leaks. "High" could be used for > large problems with resource usage (too much memory) or something that > is otherwise, important. > > > > n > ___ > 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/guido%40python.org > -- --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] Change in priority fields
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 17, 2008, at 11:35 PM, Guido van Rossum wrote: > What do I do for something that should absolutely go into the 2.6final > release (say) but is otherwise pretty minor? I've been using critical > to make sure it doesn't get put off until past the release. Critical is the right one to use. Neal and I will basically be moving issues between 'release blocker' and 'critical' with the former meaning this issue blocks the upcoming release. The latter means it will (probably) block an upcoming release. I think when we make a major milestone, e.g. the first beta, the first release candidate, etc., we'll triage those critical and move some up to release blockers. We should not release the finals until there are no release blockers or criticals. Either the critical gets moved to high and ignored, or it gets moved to release blocker and gets fixed. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR99JvnEjvBPtnXfVAQJwuwQAh5mhXdwg7t9FAsNXJ69OoPM6qj37OjP4 +3SjZMn9A1qObFB7biUV6P47KwydzDskMaswifMv9eV94+ccb0mIlDC/SgdjB9h8 JtuJq6mZ1nIUqQSLtX4W6op4G/Zpk/cerrbBzTWt06VU8yi7XhoBCVjDDVn37Nwv Kh260/8ewnw= =dMJV -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] Change in priority fields
On Mon, Mar 17, 2008 at 11:49 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Mar 17, 2008, at 11:35 PM, Guido van Rossum wrote: > > > What do I do for something that should absolutely go into the 2.6final > > release (say) but is otherwise pretty minor? I've been using critical > > to make sure it doesn't get put off until past the release. > > Critical is the right one to use. Neal and I will basically be moving > issues between 'release blocker' and 'critical' with the former > meaning this issue blocks the upcoming release. The latter means it > will (probably) block an upcoming release. I think when we make a > major milestone, e.g. the first beta, the first release candidate, > etc., we'll triage those critical and move some up to release blockers. > > We should not release the finals until there are no release blockers > or criticals. Either the critical gets moved to high and ignored, or > it gets moved to release blocker and gets fixed. Hm... This feels a bit like inflation of priorities to me; there would be lots of critical bugs and quite a few release blockers... The highest priority just pertains to the upcoming release which could be weeks in the future. I'd be more comfortable if there were 1-2 priorities above that, e.g. one higher for stuff that makes a buildbot go red (i.e. breaks a test) and two higher for stuff that affects most developers (e.g. stuff checked in that doesn't even build). -- --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] PEP 365 (Adding the pkg_resources module)
After reading all this, I really don't believe that adding egg support to the stdlib at this time is the right thing to do. I am therefore rejecting the PEP. I am hoping that someone will create a simpler bootstrap module that is able to download a file of pure Python code and install it, perhaps by running its setup.py, assuming that it only depends on distutils (or other things previously installed). I will welcome such a module into the stdlib. I'm not sure a PEP is even needed, though interested parties are certainly welcome to write a PEP specifying the behavior first. With 2.6 and 3.0 slated for release in September, there should be enough time to get this done before then. -- --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
