[Python-Dev] deprecated stuff in standard library
I have noticed that deprecated stuff is still being used in the standard Python library. When using modules that contain deprecated stuff you get a warning, and as a mere user there isn't much you can do about that. As a general rule, the Python standard library should not use deprecated constructs in non-deprecated (or otherwise deprecated) modules. The case I am running into is that mhlib uses multifile (in 2.6). -- Sjoerd Mullender signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2
-On [20100219 08:37], Simon Cross (hodgestar+python...@gmail.com) wrote: >We need someone to maintain the copy of ElementTree in the Python >repository. Ideally this means pulling upgrades and bugfixes from >Fredrik's repository every now and then. Which will give you nothing as that tree hasn't been touched in over three years. I can understand giving special consideration to maintainers, but that would imply they actually maintain something, no? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Contentment that derives from knowing when to be content is eternal contentment... ___ 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] deprecated stuff in standard library
Isn't mhlib itself deprecated? (It's gone in Py3k.) On Fri, Feb 19, 2010 at 4:33 AM, Sjoerd Mullender wrote: > I have noticed that deprecated stuff is still being used in the standard > Python library. When using modules that contain deprecated stuff you > get a warning, and as a mere user there isn't much you can do about that. > > As a general rule, the Python standard library should not use deprecated > constructs in non-deprecated (or otherwise deprecated) modules. > > The case I am running into is that mhlib uses multifile (in 2.6). -- --Guido van Rossum (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] Update xml.etree.ElementTree for Python 2.7 and 3.2
All, I hope that Fredrik himself has time to chime in at least briefly, but he told me off-line that he sees nothing controversial in the currently proposed set of changes. On Fri, Feb 19, 2010 at 5:04 AM, Jeroen Ruigrok van der Werven wrote: > -On [20100219 08:37], Simon Cross (hodgestar+python...@gmail.com) wrote: >>We need someone to maintain the copy of ElementTree in the Python >>repository. Ideally this means pulling upgrades and bugfixes from >>Fredrik's repository every now and then. > > Which will give you nothing as that tree hasn't been touched in over three > years. > > I can understand giving special consideration to maintainers, but that would > imply they actually maintain something, no? > > -- > Jeroen Ruigrok van der Werven / asmodai > イェルーン ラウフロック ヴァン デル ウェルヴェン > http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B > Contentment that derives from knowing when to be content is eternal > contentment... > ___ > 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 (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] deprecated stuff in standard library
On 2010-02-19 14:10, Guido van Rossum wrote: > Isn't mhlib itself deprecated? (It's gone in Py3k.) I wouldn't like that, but it is beside my point. If a module is deprecated, then it should not be used in released code. If mhlib is deprecated, it doesn't tell you about it. mhlib uses multifile and multifile does tell you it is deprecated, and that is pretty annoying. > On Fri, Feb 19, 2010 at 4:33 AM, Sjoerd Mullender wrote: >> I have noticed that deprecated stuff is still being used in the standard >> Python library. When using modules that contain deprecated stuff you >> get a warning, and as a mere user there isn't much you can do about that. >> >> As a general rule, the Python standard library should not use deprecated >> constructs in non-deprecated (or otherwise deprecated) modules. >> >> The case I am running into is that mhlib uses multifile (in 2.6). > -- Sjoerd Mullender signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deprecated stuff in standard library
Sjoerd Mullender wrote: On 2010-02-19 14:10, Guido van Rossum wrote: Isn't mhlib itself deprecated? (It's gone in Py3k.) I wouldn't like that, but it is beside my point. If a module is deprecated, then it should not be used in released code. If mhlib is deprecated, it doesn't tell you about it. mhlib uses multifile and multifile does tell you it is deprecated, and that is pretty annoying. This is because no one has gotten around to it. Create a bug report for it, and preferably attach a patch with tests. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deprecated stuff in standard library
On Fri, Feb 19, 2010 at 08:40, Sjoerd Mullender wrote: > On 2010-02-19 14:10, Guido van Rossum wrote: > > Isn't mhlib itself deprecated? (It's gone in Py3k.) > > I wouldn't like that, but it is beside my point. If a module is > deprecated, then it should not be used in released code. > If mhlib is deprecated, it doesn't tell you about it. mhlib uses > multifile and multifile does tell you it is deprecated, and that is > pretty annoying. > > I see the deprecation warning upon importing mhlib in 2.6 and trunk (with -Wd). ___ 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] deprecated stuff in standard library
Eric Smith trueblade.com> writes: > > This is because no one has gotten around to it. Create a bug report for > it, and preferably attach a patch with tests. > > Eric. > Actually, it gives py3k warning about "mhlib" + 2 others warnings: ./python/release26-maint/ $ ./python -Wd -3 -c "import mhlib" -c:1: DeprecationWarning: the mhlib module has been removed in Python 3.0; use the mailbox module instead ./python/release26-maint/Lib/mhlib.py:82: DeprecationWarning: in 3.x, mimetools has been removed in favor of the email package import mimetools ./python/release26-maint/Lib/mhlib.py:83: DeprecationWarning: the multifile module has been deprecated since Python 2.5 import multifile ___ 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] deprecated stuff in standard library
On 2010-02-19 14:45, Eric Smith wrote: > Sjoerd Mullender wrote: >> On 2010-02-19 14:10, Guido van Rossum wrote: >>> Isn't mhlib itself deprecated? (It's gone in Py3k.) >> >> I wouldn't like that, but it is beside my point. If a module is >> deprecated, then it should not be used in released code. >> If mhlib is deprecated, it doesn't tell you about it. mhlib uses >> multifile and multifile does tell you it is deprecated, and that is >> pretty annoying. > > This is because no one has gotten around to it. Create a bug report for > it, and preferably attach a patch with tests. My point is, as a matter of *policy*, nothing should be released that uses deprecated stuff. I can't create a bug report about wrong (or incomplete) policies. > 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/sjoerd.mullender%40cwi.nl -- Sjoerd Mullender signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On Fri, Feb 19, 2010 at 07:27, Stuart Bishop wrote: >> In any case, since you want to make a version that can be included and >> uses the timezone API, I guess that's a moot question until we have >> that version. :) > > As I understand it dateutil pretty much already provides what I'm describing. Well, pretty much yes. I don't know how good it is at using the system data without an Olsen database, but it shouldn't be too much work to add that, I guess. But that changes the topic from moving pytz to stdlib into moving dateutil.tz into stdlib. :) Personally I like pytz "anal" timezone support though, and dateutil.tz doesn't have that, and I still think it would be possible to have both in one system, but using different API-calls. Also, people have uttered negativities about datetime.tz, but they have never been able to say what they don't like about it. I would like if we could look into making a timezone module that works on Python 2.5 to 3.2 that uses system data, unless there is also a "Olsen module" installed, and that has all the features of both dateutil.tz and pytz, ie: 1. Support for the standard API. 2. A Pytz extended API. 3. Using the system data. 4. Using a separate Olsen database installable by normal Python means. 5. Perhaps a timezone name alias map? That could map both old Olsen names and Windows names. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] deprecated stuff in standard library
Sjoerd Mullender wrote: > My point is, as a matter of *policy*, nothing should be released that > uses deprecated stuff. I can't create a bug report about wrong (or > incomplete) policies. The policy is more that the test suite shouldn't raise Deprecation Warnings unless it is explicitly checking for them (or otherwise testing known-deprecated code). If there is a hole in the test suite coverage such that paths that trigger deprecated code are not exercised by the regression tests, then that is a bug. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] some notes from the first part of the lang summit
My notes from the session I led: + argparse - Same issues brought up. + Hg transition - Just updated everyone; Dirkjan said everything I did in his email update. + Stdlib breakout - Mentioned; nothing planned beyond a PEP at some point. + Extension module policy - If you write C code just for performance, you must provide a pure Python version (and both are tested). - When the stdlib is broken out, say ctypes-based versions are possible as fallback implementations. - Non-CPython VMs should contribute their pure Python implementations of modules back to the stdlib (e.g. datetime). + Proposing language changes - Need thorough dev docs. - People should vet ideas first, then PEP and code vetting, then submit for consideration. + Off-topic discussion - Need a "languishing" state in the tracker. - Probably should have a paid admin to help keep things such as the Roundup tracker in tip-top shape to take load off of people like Martin (e.g. bug fixes, new features, etc). On Thu, Feb 18, 2010 at 16:56, Trent Mick wrote: > (http://trentmick.blogspot.com/2010/02/other-python-vms-upcoming-python.html) > > Note that this was just from the first 15 minutes or so... > >> >> Some quick notes about the coming plans by the "other" Python >> implementations >> from today's Python Language Summit at PyCon 2010: >> >> - IronPython: >> - plan is to do Python 2.7 first, focus for this year >> - python 3.2 for the end of next year hopefully >> - other work on IDE stuff >> - Pynie (i.e. Parrot) -- Allison Randall: >> - about 4 major features away from pure Python syntax (did dicts last >> night) >> - targetting py3k repo and test suite: should be on track for python >> 3.2 >> - Jython: >> - plan to target 2.6 (b/c 2to3 depends on 2.6) >> - temporarily skip 2.7 and target 3.x (probably 3.2) >> - then if 3.x adoption isn't fully there, then go back and add Python >> 2.7 >> - will require JDK 2.7 for Python 3 support (b/c of new support for >> dynamic languages) >> - PyPy (Holger): >> - plan is Benjamin will port to Python 2.7 in the summer >> - only have slight deviations from CPython: idea is to merge back with >> CPython so don't have deviations. Typcically 1 or 2 line changes in >> ~25 >> modules. >> > > > Trent > > -- > Trent Mick > trentm at activestate.com > http://trentm.com/blog/ > ___ > 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/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Update xml.etree.ElementTree for Python 2.7 and 3.2
On Fri, 19 Feb 2010 06:40:00 +0100, wrote: > Antoine Pitrou wrote: > > Le Thu, 18 Feb 2010 22:46:41 +0100, Martin v. Löwis a écrit : > >>> It's time to comment and review. > >> Unfortunately, it's not. I strongly object to any substantial change to > >> the code base without explicit approval by Fredrik Lundh. > > > > Which most probably puts elementtree in bugfix-only mode. I don't > > necessarily disagree with such a decision, but it must be quite clear. > > My point is that the decision as already made when ElementTree was > incorporated into the standard library; it's the same policy for most > code that Fredrik Lundh has contributed (and which he still maintains > outside the standard library as well). He has made it fairly clear on > several occasions that this is how he expects things to work, and unless > we want to truly fork the code, we should comply. Guido has already pretty much answered this concern, but for the bystanders, note that as I understand it the patch actually brings the standard library code in sync with Fredrick's codebase, so it is actually less of a fork than continuing to do our own bug fixes would be. And Frederick has commented on the patch on Reitveld. --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] deprecated stuff in standard library
On 2010-02-19 16:23, Nick Coghlan wrote: > Sjoerd Mullender wrote: >> My point is, as a matter of *policy*, nothing should be released that >> uses deprecated stuff. I can't create a bug report about wrong (or >> incomplete) policies. > > The policy is more that the test suite shouldn't raise Deprecation > Warnings unless it is explicitly checking for them (or otherwise testing > known-deprecated code). The policy should also be, if someone decides (or rather, implements) a deprecation of a module, they should do a grep to see where that module is used and fix the code. It's not rocket science. > If there is a hole in the test suite coverage such that paths that > trigger deprecated code are not exercised by the regression tests, then > that is a bug. > > Cheers, > Nick. > -- Sjoerd Mullender signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
Lennart> I would like if we could look into making a timezone module Lennart> that works on Python 2.5 to 3.2 that uses system data... 2.5, 2.6 and 3.1 are completely off the radar screen at this point. The best you could hope for is that someone backports whatever is created for 2.7 or 3.2 and distributes it outside the normal distribution channel (say, as a patch on PyPI). Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposal for virtualenv functionality in Python
This is a proto-proposal for including some functionality from virtualenv in Python itself. I'm not entirely confident about what I'm proposing, so it's not really PEP-ready, but I wanted to get feedback... First, a bit about how virtualenv works (this will use Linux conventions; Windows and some Mac installations are slightly different): * Let's say you are creating an environment in ~/env/ * /usr/bin/python is *copied* to ~/env/bin/python * This alone sets sys.prefix to ~/env/ (via existing code in Python) * At this point things are broken because the standard library is not available * virtualenv creates ~/env/lib/pythonX.Y/site.py, which adds the system standard library location (/usr/lib/pythonX.Y) to sys.path * site.py itself requires several modules to work, and each of these modules (from a pre-determined list of modules) is symlinked over from the standard library into ~/env/lib/pythonX.Y/ * site.py may or may not add /usr/lib/pythonX.Y/site-packages to sys.path * *Any* time you use ~/env/bin/python you'll get sys.prefix of ~/env/, and the appropriate path. No environmental variable is required. * No compiler is used; this is a fairly light tool There are some tweaks to this that could be made, but I believe virtualenv basically does things The Right Way. By setting sys.prefix All Tools Work (there are some virtualenv alternatives that do isolation without setting sys.prefix, but they typically break more often than virtualenv, or only support a limited number of workflows). Also by using a distinct interpreter (~/env/bin/python) it works fairly consistently and reliably compared to techniques like an environmental variable. The one serious alternative is what buildout (and virtualenv --relocatable) does, which is to use the system Python and change the path at the beginning of all scripts (it requires its own installer to accomplish this consistently). But virtualenv is kind of a hack, and I believe with a little support from Python this could be avoided. virtualenv can continue to exist to support the equivalent workflows on earlier versions of Python, but it would not exist (or would become much much simpler) on further Python versions. The specific parts of virtualenv that are a hack that I would like to replace with built-in functionality: * I'd rather ~/env/bin/python be a symlink instead of copying it. * I'd rather not copy (or symlink) *any* of the standard library. * I'd rather site.py support this functionality natively (and in turn that OS packagers support this when they make other modifications) * Compiling extensions can be tricky because code may not find headers (because they are installed in /usr, not ~/env/). I think this can be handled better if virtualenv is slightly less intrusive, or distutils is patched, or generally tools are more aware of this layout. * This gets more complicated with a Mac framework build of Python, and hopefully those hacks could go away too. I am not sure what the best way to do this is, but I will offer at least one suggestion (other suggestions welcome): In my (proto-)proposal, a new binary pythonv is created. This is slightly like pythonw.exe, which provides a Python interpreter on Windows which doesn't open a new window. This binary is primarily for creating new environments. It doesn't even need to be on $PATH, so it would be largely invisible to people unless they use it. If you symlink pythonv to a new location, it will effect sys.prefix (currently sys.prefix is calculated after dereferencing the symlink). Additionally, the binary will look for a configuration file. I'm not sure where this file should go; perhaps directly alongside the binary, or in some location based on sys.prefix. The configuration file would be a simple set of assignments; some I might imagine: * Maybe override sys.prefix * Control if the global site-packages is placed on sys.path * On some operating systems there are other locations for packages installed with the system packager; probably these should be possible to enable or disable * Maybe control installations or point to a file like distutils.cfg I got some feedback from the Debian/Ubuntu maintainer that he would like functionality that might be like this; for instance, if you have /usr/bin/python2.6 and /usr/bin/python2.6-dbg, he'd like them to work slightly different (e.g., /usr/bin/python2.6-dbg would look in a different place for libraries). So the configuration file location should be based on sys.prefix *and* the name of the binary itself (e.g., /usr/lib/python2.6/python-config-dbg.conf). I have no strong opinion on the location of the file itself, only that it can be specific to the directory and name of the interpreter. In addition to all this, I think sys would grow another prefixy value, e.g., sys.build_prefix, that points to the place where Python was actually built (virtualenv calls this sys.real_prefix, but that's not a very good name). Some code, especially in distutils, might n
Re: [Python-Dev] Proposal for virtualenv functionality in Python
This sounds like a great idea (especially since I proposed something a little bit like it in yesterday's language summit :-). I have to admit I cannot remember what uses are made of sys.prefix; it would be good to explicitly enumerate these in the PEP when you write it. Regarding the Windows question, does virtualenv work on Windows? If so, its approach might be adopted. If not, maybe we shouldn't care (in the first version anyway)? --Guido On Fri, Feb 19, 2010 at 1:49 PM, Ian Bicking wrote: > This is a proto-proposal for including some functionality from virtualenv in > Python itself. I'm not entirely confident about what I'm proposing, so it's > not really PEP-ready, but I wanted to get feedback... > First, a bit about how virtualenv works (this will use Linux conventions; > Windows and some Mac installations are slightly different): > * Let's say you are creating an environment in ~/env/ > * /usr/bin/python is *copied* to ~/env/bin/python > * This alone sets sys.prefix to ~/env/ (via existing code in Python) > * At this point things are broken because the standard library is not > available > * virtualenv creates ~/env/lib/pythonX.Y/site.py, which adds the system > standard library location (/usr/lib/pythonX.Y) to sys.path > * site.py itself requires several modules to work, and each of these modules > (from a pre-determined list of modules) is symlinked over from the standard > library into ~/env/lib/pythonX.Y/ > * site.py may or may not add /usr/lib/pythonX.Y/site-packages to sys.path > * *Any* time you use ~/env/bin/python you'll get sys.prefix of ~/env/, and > the appropriate path. No environmental variable is required. > * No compiler is used; this is a fairly light tool > There are some tweaks to this that could be made, but I believe virtualenv > basically does things The Right Way. By setting sys.prefix All Tools Work > (there are some virtualenv alternatives that do isolation without setting > sys.prefix, but they typically break more often than virtualenv, or only > support a limited number of workflows). Also by using a distinct > interpreter (~/env/bin/python) it works fairly consistently and reliably > compared to techniques like an environmental variable. The one serious > alternative is what buildout (and virtualenv --relocatable) does, which is > to use the system Python and change the path at the beginning of all scripts > (it requires its own installer to accomplish this consistently). > But virtualenv is kind of a hack, and I believe with a little support from > Python this could be avoided. virtualenv can continue to exist to support > the equivalent workflows on earlier versions of Python, but it would not > exist (or would become much much simpler) on further Python versions. > The specific parts of virtualenv that are a hack that I would like to > replace with built-in functionality: > * I'd rather ~/env/bin/python be a symlink instead of copying it. > * I'd rather not copy (or symlink) *any* of the standard library. > * I'd rather site.py support this functionality natively (and in turn that > OS packagers support this when they make other modifications) > * Compiling extensions can be tricky because code may not find headers > (because they are installed in /usr, not ~/env/). I think this can be > handled better if virtualenv is slightly less intrusive, or distutils is > patched, or generally tools are more aware of this layout. > * This gets more complicated with a Mac framework build of Python, and > hopefully those hacks could go away too. > I am not sure what the best way to do this is, but I will offer at least one > suggestion (other suggestions welcome): > In my (proto-)proposal, a new binary pythonv is created. This is slightly > like pythonw.exe, which provides a Python interpreter on Windows which > doesn't open a new window. This binary is primarily for creating new > environments. It doesn't even need to be on $PATH, so it would be largely > invisible to people unless they use it. > If you symlink pythonv to a new location, it will effect sys.prefix > (currently sys.prefix is calculated after dereferencing the symlink). > Additionally, the binary will look for a configuration file. I'm not sure > where this file should go; perhaps directly alongside the binary, or in some > location based on sys.prefix. > The configuration file would be a simple set of assignments; some I might > imagine: > * Maybe override sys.prefix > * Control if the global site-packages is placed on sys.path > * On some operating systems there are other locations for packages installed > with the system packager; probably these should be possible to enable or > disable > * Maybe control installations or point to a file like distutils.cfg > I got some feedback from the Debian/Ubuntu maintainer that he would like > functionality that might be like this; for instance, if you have > /usr/bin/python2.6 and /usr/bin/python2.6-dbg, he'd like them to work > slightly different (e.g., /usr/
Re: [Python-Dev] Proposal for virtualenv functionality in Python
Le Fri, 19 Feb 2010 13:49:23 -0500, Ian Bicking a écrit : > > * I'd rather ~/env/bin/python be a symlink instead of copying it. How about simply adding a --prefix argument to the interpreter. Then virtualenv can create a "python" script that simply adds --prefix and forwards all the arguments to the real python executable. Or am I missing something? ___ 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] Proposal for virtualenv functionality in Python
On Feb 19, 2010, at 11:45 AM, Antoine Pitrou wrote: > Le Fri, 19 Feb 2010 13:49:23 -0500, Ian Bicking a écrit : >> >> * I'd rather ~/env/bin/python be a symlink instead of copying it. > > How about simply adding a --prefix argument to the interpreter. Then > virtualenv can create a "python" script that simply adds --prefix and > forwards all the arguments to the real python executable. > Or am I missing something? It couldn't be a shell script, as they wouldn't work as shebang line interpreters for other python scripts. -- Philip Jenvey ___ 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] Proposal for virtualenv functionality in Python
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the "real" prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have "shortcuts" but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) ___ 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] Proposal for virtualenv functionality in Python
On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby wrote: > At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: >> >> I'm not sure how this should best work on Windows (without symlinks, and >> where things generally work differently), but I would hope if this idea is >> more visible that someone more opinionated than I would propose the >> appropriate analog on Windows. > > You'd probably have to just copy pythonv.exe to an appropriate directory, > and have it use the configuration file to find the "real" prefix. At least, > that'd be a relatively obvious way to do it, and it would have the advantage > of being symmetrical across platforms: just copy or symlink pythonv, and > make sure the real prefix is in your config file. > > (Windows does have "shortcuts" but I don't think that there's any way for a > linked program to know *which* shortcut it was launched from.) Some recent discussion pointed out that vista and win7 ntfs actually supports symlinks. the same question about determining where it was launched from may still hold there? (and we need this to work on xp). How often do windows users need something like virtualenv? (Asking for experience from windows users of all forms here). I personally can't imagine anyone that would ever use a system generic python install from a .msi unless they're just learning python. I would hope people would already use py2exe or similar and include an entire CPython VM with their app with their own installer but as I really have nothing to do with windows these days I'm sure I'm wrong. What about using virtualenv with ironpython and jython? does it make any sense in that context? how do we make it not impossible for them to support? despite all the questions, I'm +1 on going ahead with a PEP and sprint discussions to figure out how to get it in for CPython 3.2 and 2.7. -gps ___ 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] Proposal for virtualenv functionality in Python
win2k and later have a form of sym link, the api for it is just not provided in a nice simple app like it is on nix platforms. On 2/19/10, P.J. Eby wrote: > At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: >>I'm not sure how this should best work on Windows (without symlinks, >>and where things generally work differently), but I would hope if >>this idea is more visible that someone more opinionated than I would >>propose the appropriate analog on Windows. > > You'd probably have to just copy pythonv.exe to an appropriate > directory, and have it use the configuration file to find the "real" > prefix. At least, that'd be a relatively obvious way to do it, and > it would have the advantage of being symmetrical across platforms: > just copy or symlink pythonv, and make sure the real prefix is in > your config file. > > (Windows does have "shortcuts" but I don't think that there's any way > for a linked program to know *which* shortcut it was launched from.) > > ___ > 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/digitalxero%40gmail.com > -- Dj Gilcrease OpenRPG Developer ~~http://www.openrpg.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
I develop OpenRPG and 90% of our user base is on windows. We require the user to install python and wxPython from msi because our app supports GUI plugins so to ensure the user can use any plugin even if it isnt prepackaged they need to have the full python and wxPython installed. We are working on changing the code around to work better with py2exe & py2app. But I use virtual env on windows & linux to test multiple py/wx combos that our app supports On 2/19/10, Gregory P. Smith wrote: > On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby wrote: >> At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: >>> >>> I'm not sure how this should best work on Windows (without symlinks, and >>> where things generally work differently), but I would hope if this idea >>> is >>> more visible that someone more opinionated than I would propose the >>> appropriate analog on Windows. >> >> You'd probably have to just copy pythonv.exe to an appropriate directory, >> and have it use the configuration file to find the "real" prefix. At >> least, >> that'd be a relatively obvious way to do it, and it would have the >> advantage >> of being symmetrical across platforms: just copy or symlink pythonv, and >> make sure the real prefix is in your config file. >> >> (Windows does have "shortcuts" but I don't think that there's any way for >> a >> linked program to know *which* shortcut it was launched from.) > > Some recent discussion pointed out that vista and win7 ntfs actually > supports symlinks. the same question about determining where it was > launched from may still hold there? (and we need this to work on xp). > > How often do windows users need something like virtualenv? (Asking > for experience from windows users of all forms here). I personally > can't imagine anyone that would ever use a system generic python > install from a .msi unless they're just learning python. I would hope > people would already use py2exe or similar and include an entire > CPython VM with their app with their own installer but as I really > have nothing to do with windows these days I'm sure I'm wrong. > > What about using virtualenv with ironpython and jython? does it make > any sense in that context? how do we make it not impossible for them > to support? > > despite all the questions, I'm +1 on going ahead with a PEP and sprint > discussions to figure out how to get it in for CPython 3.2 and 2.7. > > -gps > ___ > 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/digitalxero%40gmail.com > -- Dj Gilcrease OpenRPG Developer ~~http://www.openrpg.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal for virtualenv functionality in Python
On Fri, 19 Feb 2010 14:35:42 -0700, Dj Gilcrease wrote: > On 2/19/10, P.J. Eby wrote: > > At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: > >>I'm not sure how this should best work on Windows (without symlinks, > >>and where things generally work differently), but I would hope if > >>this idea is more visible that someone more opinionated than I would > >>propose the appropriate analog on Windows. > > > > You'd probably have to just copy pythonv.exe to an appropriate > > directory, and have it use the configuration file to find the "real" > > prefix. At least, that'd be a relatively obvious way to do it, and > > it would have the advantage of being symmetrical across platforms: > > just copy or symlink pythonv, and make sure the real prefix is in > > your config file. > > > > (Windows does have "shortcuts" but I don't think that there's any way > > for a linked program to know *which* shortcut it was launched from.) > > win2k and later have a form of sym link, the api for it is just not > provided in a nice simple app like it is on nix platforms. See also http://bugs.python.org/issue1578269, which proposes an implementation of os.symlink for windows, and appears to be just about ready to go in. --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] Proposal for virtualenv functionality in Python
On 19/02/2010 16:30, Gregory P. Smith wrote: On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby wrote: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the "real" prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have "shortcuts" but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) Some recent discussion pointed out that vista and win7 ntfs actually supports symlinks. the same question about determining where it was launched from may still hold there? (and we need this to work on xp). How often do windows users need something like virtualenv? (Asking for experience from windows users of all forms here). I personally can't imagine anyone that would ever use a system generic python install from a .msi unless they're just learning python. I would hope people would already use py2exe or similar and include an entire CPython VM with their app with their own installer but as I really have nothing to do with windows these days I'm sure I'm wrong. I've used virtualenv on Windows and it is just as useful as on other platforms. *Most* Python developers I know work from an installed Python although application distribution is typically done with py2exe. The Windows msi installer is downloaded an insane amount from Python.org. Michael What about using virtualenv with ironpython and jython? does it make any sense in that context? how do we make it not impossible for them to support? despite all the questions, I'm +1 on going ahead with a PEP and sprint discussions to figure out how to get it in for CPython 3.2 and 2.7. -gps ___ 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.ironpythoninaction.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] deprecated stuff in standard library
On Fri, Feb 19, 2010 at 9:03 AM, Sjoerd Mullender wrote: > The policy should also be, if someone decides (or rather, implements) a > deprecation of a module, they should do a grep to see where that module > is used and fix the code. It's not rocket science. I'm not sure if you're aware of it, but you're starting to sound a little rude. ISTM that it doesn't make sense to waste effort ensuring that deprecated code is updated to not call other deprecated modules. Of course, all released non-deprecated code should steer clear of deprecated apis. -Mike ___ 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] Proposal for virtualenv functionality in Python
On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the "real" prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have "shortcuts" but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Windows also has hard-links for files. A lot of Windows tools are completely ignorant of both of those linking concepts... resulting in disks that look to be over capacity when they are not, for example. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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] Proposal for virtualenv functionality in Python
Glenn Linderman wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the "real" prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have "shortcuts" but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. ___ 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] Proposal for virtualenv functionality in Python
On approximately 2/19/2010 7:52 PM, came the following characters from the keyboard of Eric Smith: Glenn Linderman wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the "real" prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have "shortcuts" but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. So if you can't test it, why would you state it as a fact... and then back-pedal? :) Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. d:\>python.exe Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> exit() d:\>c:\python26\python.exe ActivePython 2.6.2.2 (ActiveState Software Inc.) based on Python 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> exit() d:\>d:\python.exe.lnk d:\>ActivePython 2.6.2.2 (ActiveState Software Inc.) based on Python 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> So this makes it look like it works fine. But doing exit() from the shortcut-started python fails... it hangs, eventually the whole CMD shell dies, if you poke it enough. I'm going to let it sit there a long time ... until I shut down, and see if it ever exits properly. The form d:\>start python.exe.lnk gives the python its own window, and that works/exits fine. So, shortcuts do work from the shell, but there might be some issues, and you might have to type the .lnk to invoke them (I haven't played with adding .lnk or .exe.lnk to PATHEXT) I don't have a clue if the above problem is a Windows issue, or a Python issue. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ 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] deprecated stuff in standard library
On Fri, Feb 19, 2010 at 5:41 PM, Mike Klaas wrote: > On Fri, Feb 19, 2010 at 9:03 AM, Sjoerd Mullender wrote: > >> The policy should also be, if someone decides (or rather, implements) a >> deprecation of a module, they should do a grep to see where that module >> is used and fix the code. It's not rocket science. > > I'm not sure if you're aware of it, but you're starting to sound a little > rude. He's just being Dutch. :-) > ISTM that it doesn't make sense to waste effort ensuring that > deprecated code is updated to not call other deprecated modules. Of > course, all released non-deprecated code should steer clear of > deprecated apis. Read again. Sjoerd meant it exactly the other way around. When a module is deprecated it is *not* a wasted effort to ensure that no other (undeprecated) modules depend on it! -- --Guido van Rossum (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] Proposal for virtualenv functionality in Python
-- http://www.ironpythoninaction.com On 19 Feb 2010, at 22:52, Eric Smith wrote: Glenn Linderman wrote: On approximately 2/19/2010 1:18 PM, came the following characters from the keyboard of P.J. Eby: At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote: I'm not sure how this should best work on Windows (without symlinks, and where things generally work differently), but I would hope if this idea is more visible that someone more opinionated than I would propose the appropriate analog on Windows. You'd probably have to just copy pythonv.exe to an appropriate directory, and have it use the configuration file to find the "real" prefix. At least, that'd be a relatively obvious way to do it, and it would have the advantage of being symmetrical across platforms: just copy or symlink pythonv, and make sure the real prefix is in your config file. (Windows does have "shortcuts" but I don't think that there's any way for a linked program to know *which* shortcut it was launched from.) No automatic way, but shortcuts can include parameters, not just the program name. So a parameter could be --prefix as was suggested in another response, but for a different reason. Shortcuts don't work from the shell (well, cmd.exe, at least), do they? Can't test from here. They do if you add .lnk to your PATHEXT environment variable. Michael ___ 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 ___ 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] deprecated stuff in standard library
> My point is, as a matter of *policy*, nothing should be released that > uses deprecated stuff. I can't create a bug report about wrong (or > incomplete) policies. Sure you can. Write a bug report asking that PEP 4 gets amended with specific wording. Not that PEP 4 is followed in practice at all, but if the policy was in place and just not followed, that's a bug. 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
