Re: [Python-Dev] Distutils2 scripts
On 12/10/2010 00:11, Giampaolo Rodolà wrote: Wouldn't be kinda weird that one can open the command prompt and run "pysetup" but not "python" on Windows? I recall an old issue on the bug tracker in which the latter proposal was widely discussed and finally rejected for reasons I can't remember (and it seems I can't even find the bug right now). I think it's likely that those same reasons are valid for "pysetup" in the same manner. For the record, I would be more than happy to be able to open the command prompt and type "pysetup" and "python" with success, one day. Well ditto, but not everyone feels the same. If you have multiple python versions having them all modify the path on installation would be annoying - the other issue is that it is hard to deterministically undo a change on uninstallation. (And leaving cruft behind is bad, although plenty of other applications don't have as much of a conscience about it as we do.) For the record I wrote about the PATH settings (etc) useful for Python on Windows: http://www.voidspace.org.uk/python/articles/command_line.shtml#environment-variables Probably too basic for *you* but maybe helpful for others. What would be *really* nice was if we had a versioned script / exe as well (same for python.exe on Windows) so that you could unconditionally add the Python directory and its Scripts directory to the PATH and then be able to specify which version to run. Currently you have to setup aliases yourself to do this. So as well as pysetup.py/.exe I would like pysetup-3.2.py / .exe on Windows please. (I'd really like a python-3.2.exe as well.) All the best, Michael Foord --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2010/10/12 Eric Smith: On 10/11/2010 5:17 PM, Giampaolo Rodolà wrote: 2010/10/8 Eric Smith: On 10/8/10 10:26 AM, Barry Warsaw wrote: In any case, these could be a simple shell script wrapping 'python -m setup'. It could even take a --use-python-version option to select the pythonX.Y it used, without having to encode the Python version number in the script name. On Windows it can't be a shell script or batch file, but needs to be an executable. setuptools already deals with this. If that's the case what would I type in the command prompt in order to install a module? "C:\PythonXX\pysetup.exe"? If so I would strongly miss old "setup.py install". Same thing you would type at a shell prompt. Presumably we're talking about "pysetup install" (which you'll note is one character shorter!). You could fully qualify the path if need be, on any platform, using its conventions. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Distutils2 scripts
On 12 October 2010 00:42, Giampaolo Rodolà wrote: > I know. My point was you can't do it by default and installing a > module is something even a less experienced user usually does. > Typing "C:\PythonXX\pysetup" is harder compared to "setup.py install" > and solving this problem by modifying your environment paths so that > you can just type "pysetup" is something I would expect to be done by > the MSI installer, not the user. I would assume (am I wrong?) that the canonical way of installing modules on Windows for "non-advanced" users under distutils2 would still be to download and run a binary installer. Assuming that's the case, modifying paths to make sure pysetup is available as a command is no harder than making Python itself available. (Having said that, I'd still personally prefer to have the distutils2 command be invoked by some form of python -m invocation). 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] Distutils2 scripts
On 12/10/2010 12:55, Paul Moore wrote: On 12 October 2010 00:42, Giampaolo Rodolà wrote: I know. My point was you can't do it by default and installing a module is something even a less experienced user usually does. Typing "C:\PythonXX\pysetup" is harder compared to "setup.py install" and solving this problem by modifying your environment paths so that you can just type "pysetup" is something I would expect to be done by the MSI installer, not the user. I would assume (am I wrong?) that the canonical way of installing modules on Windows for "non-advanced" users under distutils2 would still be to download and run a binary installer. Assuming that's the case, modifying paths to make sure pysetup is available as a command is no harder than making Python itself available. (Having said that, I'd still personally prefer to have the distutils2 command be invoked by some form of python -m invocation). Sure, scripts like pysetup are typically installed into C:\PythonXY\Scripts on Windows. Adding this to the path is no harder than adding C:\PythonXY to the path - in fact it is *exactly* as hard. Some people have an issue that they have to do this *at all* though. Having the script invoked by "python -m ..." is no easier from this point of view, for it to work from the command line you still have to modify your path to be able to do it. Personally I would prefer a separate script, "pysetup install foo" is less annoying to type than "python -m distutils2.install foo" or "python -m setup install foo". All the best, Michael 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] [RELEASED] Python 3.2 alpha 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the third and final alpha preview release of Python 3.2. Python 3.2 is a continuation of the efforts to improve and stabilize the Python 3.x line. Since the final release of Python 2.7, the 2.x line will only receive bugfixes, and new features are developed for 3.x only. Since PEP 3003, the Moratorium on Language Changes, is in effect, there are no changes in Python's syntax and built-in types in Python 3.2. Development efforts concentrated on the standard library and support for porting code to Python 3. Highlights are: * numerous improvements to the unittest module * PEP 3147, support for .pyc repository directories * PEP 3149, support for version tagged dynamic libraries * an overhauled GIL implementation that reduces contention * many consistency and behavior fixes for numeric operations * countless fixes regarding string/unicode issues; among them full support for a bytes environment (filenames, environment variables) * a sysconfig module to access configuration information * a pure-Python implementation of the datetime module * additions to the shutil module, among them archive file support * improvements to pdb, the Python debugger For an extensive list of changes in 3.2, see Misc/NEWS in the Python distribution. To download Python 3.2 visit: http://www.python.org/download/releases/3.2/ 3.2 documentation can be found at: http://docs.python.org/3.2/ Please consider trying Python 3.2 with your code and reporting any bugs you may notice to: http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.2's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAky0V1QACgkQN9GcIYhpnLCm3wCeJ5EUcv8lYu4Yj/obNvOsIpvC kXAAnR9znSCZwMoEvWwzernXWIxrhojM =UE9Z -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] Distutils2 scripts
On Tue, Oct 12, 2010 at 1:55 PM, Paul Moore wrote: ... > I would assume (am I wrong?) that the canonical way of installing > modules on Windows for "non-advanced" users under distutils2 would > still be to download and run a binary installer. Yes this won't change. Regards Tarek ___ 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] Distutils2 scripts
On Oct 12, 2010, at 12:24 PM, Greg Ewing wrote: >Giampaolo Rodolà wrote: > >> If that's the case what would I type in the command prompt in order to >> install a module? >> "C:\PythonXX\pysetup.exe"? >> If so I would strongly miss old "setup.py install". > >Another thing bothers me about this. With the current scheme, >if you have multiple Pythons available, it's easy to be sure >that you're installing into the right one, because it's the >one that you use to run setup.py. Whereas if installation is >performed by a different executable, there's a possibility >of them being out of sync. > >So I think I'd prefer some scheme involving 'python -m ...' >or some other option to Python itself, rather than a separate >executable. This is why I suggested that 'setup.sh' (or whatever) take a --python-version option to select the python executable to use. Whatever solution is implemented definitely needs to take the multiple-installed pythons into account. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch making the current email package (mostly) support bytes
ba...@python.org wrote in the full post below: > I'm reminded of a survey Guido conducted at some long past > Python conference. He asked (paraphrasing): raise your hand > if you think Python is changing too fast. Lots of hands went > up. Then he asked, raise your hand if you have a feature you > want to get in the next version. Lots of hands went up. When? I doubt that you'd get the same reaction today given the schism that 3.X has created. Regardless, this underscores much of what I'm trying to get across here. Python conference attendees are hardly representative of the user base at large. Even today, they are probably just 0.1% of the whole. This list's readership is an order of magnitude smaller still. Open doesn't mean all that much to those outside the 0.01% whose preferences set the agenda. I appreciate that some people here do indeed weigh compatibility carefully, and realize that there are multiple valid viewpoints on this issue. And regrettably, I have neither solutions nor time to give this thread the further attention it deserves. So my point is just this: Change for change's sake is truly not what most Python users want. If Python core developers want 3.X to become as popular as 2.X, they should be less concerned with posts on this list or hands at a conference, than with the feet of the masses whose votes will ultimately decide 3.X's fate. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) > Date: Fri, 8 Oct 2010 14:20:32 -0400 > From: Barry Warsaw > To: python-dev@python.org > Subject: Re: [Python-Dev] Patch making the current email package (mostly) > support bytes > > On Oct 08, 2010, at 03:44 PM, l...@rmi.net wrote: > > >Ultimately, development in the open source world is driven by the > >very few with time to show up, rather than by the very many who > >depend on it. This can unfortunately lead to the perception > >of thrashing by end users. Some even come to see the net effect > >as not that much different from closed models. I have no solution > >to offer, except to underscore again that changes made here affect > >very many people who are too busy using Python to participate here. > >Especially given the still tentative state of 3.X, stability matters. > > I'm reminded of a survey Guido conducted at some long past Python conference. > He asked (paraphrasing): raise your hand if you think Python is changing too > fast. Lots of hands went up. Then he asked, raise your hand if you have a > feature you want to get in the next version. Lots of hands went up. > > I'm sympathetic to the view that changes in Python can be disruptive to end > users. The Python community itself takes this seriously too, as evidenced by > the language moratorium[*]. But OTOH, Python cannot stagnate and even fixing > things means changing things. The reality too is that Python releases come > out approximately every 18 months, and a year and a half can either seem like > an excruciatingly long time, or blink of the eye depending on which side of > the fence you stand on. > > Yes, stability matters, but Python 3 is still a new snakeling and I suspect > that as the pace of porting picks up, more changes will be necessary. Adding > new modules named like distutils2 or unittest2 is less than satisfying but > useful for keeping older APIs around. > > I'm sad to hear that some people think that our development model differs > little from closed source development. To me, nothing could be further from > the truth. But the adage does go "(s)he who does the work, decides", and this > is the forum for those who are doing the work. I think everyone here welcomes > advocates for under-represented Python communities, and their concerns should > be taken in consideration when changes are discussed. But ultimately, Python > must evolve to stay relevant or it will die. This is where competing design > trade-offs must be discussed. If not here, by us, then where and by whom? > > -Barry > > [*] Mostly instituted to allow alternative implementations to catch up, it > does necessarily slow the pace of changes visible to end users. ___ 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] Distutils2 scripts
> So as well as pysetup.py/.exe I would like pysetup-3.2.py / .exe on > Windows please. (I'd really like a python-3.2.exe as well.) Please submit a patch to the installer, then. I'm still skeptical about adding PATH, because a) I find that fairly invasive, and despise long paths myself (it hurts my eyes to see the list of directories that VS adds to MY path) b) it's actually fairly tricky to implement; in particular, removal on uninstallation is difficult. On the other hand, adding a versioned executable in some directory that is known to be on the path already is more easy, at least for a per-machine installation: I guess \windows\system32 would be the right location for such an executable. Placing files into system32 is fairly easy with MSI (except for possible WoW64 problems - what if you install both the 32-bit and the 64-bit Python 3.2 on the same machine). 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] Distutils2 scripts
On Tue, 12 Oct 2010 19:33:52 +0200,
=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?= wrote:
> > So as well as pysetup.py/.exe I would like pysetup-3.2.py / .exe on
> > Windows please. (I'd really like a python-3.2.exe as well.)
>
> Please submit a patch to the installer, then.
>
> I'm still skeptical about adding PATH, because
> a) I find that fairly invasive, and despise long paths myself
>(it hurts my eyes to see the list of directories that VS adds to MY
>path)
I get annoyed by that on Gentoo, too. Gentoo, though, is using the path
entries to control *which* version of various things run when I type
a command at the prompt, IIUC, and it updates them when I change the
active version of a program, and removes them correctly when a package
is uninstalled.
Gentoo doesn't use path for that for everything, though...for Python, when
I change which version is active ("eselect python python2.5") it updates
the symlinks rather than the path, and I like that much better. It's less
fragile, too, since it means I don't have to do 'source /etc/profile'
in every open shell after switching the active version of Python.
I don't use Windows much, but on balance I think I'm with Martin here :)
--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils2 scripts
On 12/10/2010 7:17 PM, R. David Murray wrote: On Tue, 12 Oct 2010 19:33:52 +0200, =?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?= wrote: So as well as pysetup.py/.exe I would like pysetup-3.2.py / .exe on Windows please. (I'd really like a python-3.2.exe as well.) Please submit a patch to the installer, then. I'm still skeptical about adding PATH, because a) I find that fairly invasive, and despise long paths myself (it hurts my eyes to see the list of directories that VS adds to MY path) Assume, for the sake of the argument, that we patched the MSI so it (optionally) added the installing version of Python (and, optionally ./scripts) to the PATH. What, then, do we do with existing PATH entries which point to older/other Python installations? Option (a) says: clear them all out, because it's meaningless having more than one entry with a python.exe on it and the one we want must be this one because we've just ticked a box to say so. Option (b) says: don't mess with other entries on the PATH; it's not done. That said, the current installer switches an APPPATH entry and changes -- optionally -- the file associations to point to the installing version, so there is a precedent for ditching previous data. I'm actually +0 on the idea. An expert user who's trying to juggle different Python versions should be able to sort himself out. A naive user can use Start > Run > Python to get the current version (thanks to the APPPATH) and can use "program.py arg1 arg2" on the console to run program.py with the associated version. (Notwithstanding the bug which doesn't correctly redirect output via file associations) But all this is pie in the sky until someone actually integrates such a change to the MSI. Martin's clearly not going to since he doesn't like the idea. I'm actually +0.5 on including a script in tools\scripts (or wherever) which, when run, would set as current the version of Python which ran it. I have a roughly working version of such a thing; the problem is getting it to work with all the different Python versions and all the different Windows versions we support. TJG ___ 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] Distutils2 scripts
> Assume, for the sake of the argument, that we patched the > MSI so it (optionally) added the installing version of Python > (and, optionally ./scripts) to the PATH. What, then, do we > do with existing PATH entries which point to older/other Python > installations? Option (a) says: clear them > all out, because it's meaningless having more than one entry > with a python.exe on it and the one we want must be this one > because we've just ticked a box to say so. Option (b) says: > don't mess with other entries on the PATH; it's not done. That, too. For the registry settings, overwriting them is an easy choice: it was the other installer that wrote the original entries (*very* likely so), so we "own" them and we can overwrite them. Running a repair installation on the original installer will revert that. With the PATH entry, it's not such an easy choice: the old entry may have been manually added, or it may have been added by the previous installer. Replacing it in the second case is again a straight-forward choice, but we don't know (unless we record somewhere - in the registry - that we added a PATH entry - perhaps an MSI Feature entry could tell us). 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] Patch making the current email package (mostly) support bytes
On Wed, 13 Oct 2010 03:01:57 am l...@rmi.net wrote: > So my point is just this: Change for change's sake is truly not > what most Python users want. If Python core developers want 3.X > to become as popular as 2.X, they should be less concerned with > posts on this list or hands at a conference, than with the feet > of the masses whose votes will ultimately decide 3.X's fate. I don't think anyone has ever suggested change for change's sake. If they have, I'd love to read the PEP for it. -- Steven D'Aprano ___ 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] PPC Tiger buildbot going down for an upgrade
I've found a dual-processor G4 to run the PPC Tiger buildbot on (it's currently an old e Mac), and I plan to take this buildbot down tomorrow, Wednesday, to upgrade. 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
