[Python-Dev] Python launcher command line usage (Was: 3.2.1 encoding surprise)
On 19 July 2011 02:41, Vinay Sajip wrote: > The use of py from the command line is merely a convenience for developers (as > the PEP says) - it's better to rely on shebang lines together with settings in > the .ini to get the behaviour you want. But it's a *huge* convenience for running multiple Python versions, particularly as no existing Python versions install executables with the version in the name (python3.exe, python3.2.exe, etc).And BAT files aren't a suitable option (I'll rant about the issues with BAT files if you want, but I recommend you don't ask :-)) Being able to say py -3, py -2.7, etc, rather than having to hack PATH, create renamed copies of exes, etc, is arguably more of a benefit to me than shebang support. This may explain why I'd like to see a command-line means of invoking custom commands. Something like py.exe looking at an initial argument, and if it's of the form "-cmd" for a command in py.ini, then run that command, passing remaining arguments just as for py -3. (Maybe --cmd to match standard long option usage would be better?) Presumably, if this idea is to go anywhere, it would need adding to the PEP. Mark, do you think it would be useful? It makes it possible to invoke IronPython/Jython in the same manner as CPython. (And, of course, to abuse things so that "py -perl" runs Perl, but no-one would do that :-)) 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 launcher command line usage (Was: 3.2.1 encoding surprise)
On Tue, 19 Jul 2011 16:00:57 +0100 Paul Moore wrote: > On 19 July 2011 02:41, Vinay Sajip wrote: > > The use of py from the command line is merely a convenience for developers > > (as > > the PEP says) - it's better to rely on shebang lines together with settings > > in > > the .ini to get the behaviour you want. > > But it's a *huge* convenience for running multiple Python versions, > particularly as no existing Python versions install executables with > the version in the name (python3.exe, python3.2.exe, etc). Perhaps this could be changed? As far as I can see, python.exe is a small executable around ~25KB (all the code being in the DLL), so there doesn't seem to be any harm to make a copy of it named either pythonXY.exe or pythonX.Y.exe. Regards Antoine. ___ 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 launcher command line usage (Was: 3.2.1 encoding surprise)
On 19 July 2011 16:16, Antoine Pitrou wrote: > On Tue, 19 Jul 2011 16:00:57 +0100 > Paul Moore wrote: > >> On 19 July 2011 02:41, Vinay Sajip wrote: >> > The use of py from the command line is merely a convenience for developers >> > (as >> > the PEP says) - it's better to rely on shebang lines together with >> > settings in >> > the .ini to get the behaviour you want. >> >> But it's a *huge* convenience for running multiple Python versions, >> particularly as no existing Python versions install executables with >> the version in the name (python3.exe, python3.2.exe, etc). > > Perhaps this could be changed? As far as I can see, python.exe is > a small executable around ~25KB (all the code being in the DLL), so > there doesn't seem to be any harm to make a copy of it named either > pythonXY.exe or pythonX.Y.exe. I'm sure it could (and in fact, I thought that this had been discussed some time back and it may even be already happening in 3.3) but it doesn't help for existing versions, where the py.exe launcher does. So as a longer-term solution, supplying pythonXY.exe binaries may be useful (depending on how PEP 397 progresses), but the benefits won't be for quite some time. (And there's still the question of what gets put on PATH by default even if version-specific binaries exist). It's a topic worthy of discussion, but I suspect that in actual fact, PEP 397 may offer a more complete solution to the various Windows installation niggles. Two questions: 1. What level of support is there for PEP 397? If it's unlikely to get accepted, there's little point in basing a solution on it. 2. Would it be worth extending the goals of the PEP to make simplifying command line usage an explicit goal? Or is it better to keep PEP 397 focused on one thing and have a separate PEP covering such further extensions to the PEP 397 launcher? 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] knee.py import hook in 2.6
Hi, I'm trying to use the import hook in Python2.6, but I'm having a problem. It doesn't work for numpy. My error is such: > >>> import knee > >>> import numpy > Traceback (most recent call last): > File "", line 1, in > File "knee.py", line 16, in import_hook > q, tail = find_head_package(parent, name) > File "knee.py", line 52, in find_head_package > q = import_module(head, qname, parent) > File "knee.py", line 101, in import_module > m = imp.load_module(fqname, fp, pathname, stuff) > File "/usr/apps/python2.6/lib/python2.6/site-packages/numpy/__init__.py", > line 130, in > import add_newdocs > File "knee.py", line 16, in import_hook > q, tail = find_head_package(parent, name) > File "knee.py", line 52, in find_head_package > q = import_module(head, qname, parent) > File "knee.py", line 101, in import_module > m = imp.load_module(fqname, fp, pathname, stuff) > File > "/usr/apps/python2.6/lib/python2.6/site-packages/numpy/add_newdocs.py", line > 9, in > from lib import add_newdoc > File "knee.py", line 16, in import_hook > q, tail = find_head_package(parent, name) > File "knee.py", line 52, in find_head_package > q = import_module(head, qname, parent) > File "knee.py", line 101, in import_module > m = imp.load_module(fqname, fp, pathname, stuff) > File > "/usr/apps/python2.6/lib/python2.6/site-packages/numpy/lib/__init__.py", > line 4, in > from type_check import * > File "knee.py", line 16, in import_hook > q, tail = find_head_package(parent, name) > File "knee.py", line 52, in find_head_package > q = import_module(head, qname, parent) > File "knee.py", line 101, in import_module > m = imp.load_module(fqname, fp, pathname, stuff) > File > "/usr/apps/python2.6/lib/python2.6/site-packages/numpy/lib/type_check.py", > line 8, in > import numpy.core.numeric as _nx > File "knee.py", line 17, in import_hook > m = load_tail(q, tail) > File "knee.py", line 68, in load_tail > m = import_module(head, mname, m) > File "knee.py", line 101, in import_module > m = imp.load_module(fqname, fp, pathname, stuff) > File > "/usr/apps/python2.6/lib/python2.6/site-packages/numpy/core/__init__.py", > line 6, in > import umath > File "knee.py", line 16, in import_hook > q, tail = find_head_package(parent, name) > File "knee.py", line 52, in find_head_package > q = import_module(head, qname, parent) > File "knee.py", line 101, in import_module > m = imp.load_module(fqname, fp, pathname, stuff) > TypeError: import_hook() takes at most 4 arguments (5 given) So I don't know what is going on, unless a "self" is being passed along the way. (which seems like it could happen when looking at __import__ in the source) Can any of you identify my problem or let me know of a fixed import hook? Thank you, Timothy D. Kadich ___ 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] knee.py import hook in 2.6
Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Tue, Jul 19, 2011 at 11:16:46AM -0700, Timothy D. Kadich wrote: > I'm trying to use the import hook in Python2.6, but I'm having a problem. It > doesn't work for numpy. My error is such: [skip] > > TypeError: import_hook() takes at most 4 arguments (5 given) Seems like import_hook is from an older version of Python. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name 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] Python launcher command line usage (Was: 3.2.1 encoding surprise)
On Tue, 19 Jul 2011 17:21:30 +0100 Paul Moore wrote: > > Two questions: > 1. What level of support is there for PEP 397? If it's unlikely to get > accepted, there's little point in basing a solution on it. It only needs support from our Windows users or developers. It is doubtful than any Linux or OS X user would oppose it on purely platonic grounds. I myself, as a casual Windows user, understand that the current situation is not optimal and believe that any improvement is welcome. Practically, if Mark Hammond is satisfied with his own proposal, if Martin doesn't oppose it, and if other users like you say it's a good step forward, then I don't see any reason for it *not* to be accepted. (if you want an explicit +1, here it is :-)) > 2. Would it be worth extending the goals of the PEP to make > simplifying command line usage an explicit goal? Or is it better to > keep PEP 397 focused on one thing and have a separate PEP covering > such further extensions to the PEP 397 launcher? I have no opinion about that. Regards Antoine. ___ 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] email-6.0.0.a1
OK, so I've released the first iteration of the email6 package on pypi as email-6.0.0a1. After install you import it as email6. This will allow anyone curious and/or motivated to test it out under Python 3.2. I'm especially interested in anyone with a working program that uses email in 3.2: it should be completely backward compatible, and if it isn't I want to know ASAP.[*] I've also opened issue 12586 for review of the delta between default and the code that is in the release. I'd like to check the code in to default and continue to work on it from there. As I said in the issue comments: "When we originally planned out email6 we thought we'd be making a "compatibility break" with backward compatibility shims. As things have turned out the work is more a matter of incremental improvement of the API while maintaining the old API, and thus it seems reasonable to me to work on it directly in default rather than continue to work on it in a separate feature branch." Assuming, that is, that the general approach represented by *this* delta is accepted. What this delta adds to email is a conversion to handling all headers as full blown objects (as opposed to strings, tuples of strings, or Header objects, depending on context). The object type is a subclass of str, so the headers act like strings if you don't use their additional API. The basic additional API is that a 'source' attribute contains the text the generator read from the input source, and a 'value' attribute that contains the value with all the Content-Transfer-Encoding stuff undone so that you have a real unicode string. By changing a policy setting, you can have that value as the string value of the header. You can also assign a string with non-ASCII characters to a header, and the right thing will happen. (Well, eventually it will happen...right now it only works correctly for unstructured headers). Further, Date headers have a datetime attribute (and accept being set to a datetime), and address headers have attributes for accessing the individual addresses in the header. Other structured headers will eventually grow additional attributes as well. The general approach has been discussed with and approved by the email-sig, but all comments are welcome. I know there's room for bikeshedding on some aspects of the API; in some cases I've dome some "placeholder" stuff pending a more complete solution to certain design goals. I have a big project in the offing over the next couple months. QNX is still fully behind the funding for email6 development, but I probably won't be able to complete it until the fall. So I'd like to get this chunk (the biggest chunk of new code, considering the size of the parser) reviewed and checked in if possible. I'll keep working on the bits of functionality that aren't quite complete and the bugs that I know are there until my big project kicks off, but I wanted to release/post now so that there might be a chance of some review happening while I still have time to respond quickly to the feedback. -- R. David Murray http://www.bitdance.com [*] I believe that if you try to use an email6 Message object with the 3.2 mailbox module you will run in to some trouble, but I think it ought to be possible to make it work with the right magic :) PS: I don't have much experience writing parsers, so I'm expecting some critical comments about my parser design. It had to be a custom parser since otherwise I'd be blocked on waiting for some other software to get accepted into the stdlib, but it certainly wound up being a bigger chunk of code than I expected when I started writing it. ___ 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 launcher command line usage (Was: 3.2.1 encoding surprise)
On Wed, Jul 20, 2011 at 6:59 AM, Antoine Pitrou wrote: > (if you want an explicit +1, here it is :-)) FWIW, +1 from me as well, but keep in mind that I actively avoid programming on Windows (although I'm happy enough using it as a gaming platform) 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] Python launcher command line usage (Was: 3.2.1 encoding surprise)
On 20/07/2011 1:00 AM, Paul Moore wrote: On 19 July 2011 02:41, Vinay Sajip wrote: The use of py from the command line is merely a convenience for developers (as the PEP says) - it's better to rely on shebang lines together with settings in the .ini to get the behaviour you want. But it's a *huge* convenience for running multiple Python versions, particularly as no existing Python versions install executables with the version in the name (python3.exe, python3.2.exe, etc).And BAT files aren't a suitable option (I'll rant about the issues with BAT files if you want, but I recommend you don't ask :-)) Being able to say py -3, py -2.7, etc, rather than having to hack PATH, create renamed copies of exes, etc, is arguably more of a benefit to me than shebang support. Ditto for me. This may explain why I'd like to see a command-line means of invoking custom commands. Something like py.exe looking at an initial argument, and if it's of the form "-cmd" for a command in py.ini, then run that command, passing remaining arguments just as for py -3. (Maybe --cmd to match standard long option usage would be better?) Presumably, if this idea is to go anywhere, it would need adding to the PEP. Mark, do you think it would be useful? I doubt I will find it useful - but I'm on record as saying I wont find the custom command support itself useful :) But similarly with that support, evidence that enough people *will* find it useful is enough for me to support the concept. My current thinking re the PEP is to make it much smaller - just describe the concepts and try to avoid as much implementation detail as possible - I see no reason the PEP needs to take a stance on issues like that - this feature really could be treated just like any other feature request in Python - a loose consensus and acceptable patch is all that is needed. Mark ___ 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 launcher command line usage (Was: 3.2.1 encoding surprise)
On 7/19/2011 12:21 PM, Paul Moore wrote: On 19 July 2011 16:16, Antoine Pitrou wrote: On Tue, 19 Jul 2011 16:00:57 +0100 Perhaps this could be changed? As far as I can see, python.exe is a small executable around ~25KB (all the code being in the DLL), so there doesn't seem to be any harm to make a copy of it named either pythonXY.exe or pythonX.Y.exe. I'm sure it could (and in fact, I thought that this had been discussed some time back and it may even be already happening in 3.3) but it doesn't help for existing versions, where the py.exe launcher does. So as a longer-term solution, supplying pythonXY.exe binaries may be useful (depending on how PEP 397 progresses), but the benefits won't be for quite some time. (And there's still the question of what gets put on PATH by default even if version-specific binaries exist). Suppose for Windows there were one '.../python' directory wherever the user first asks it to be put and that all pythons, not just cpython, are installed in directories below that and that the small startup file is copied into or linked from the python directory. Then the one python directory could be put on the path and left there and never removed by any python de-installer (unless perhaps it check that there are no subdirs and *asks* the user. -- Terry Jan Reedy ___ 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] Draft PEP: "Simplified Package Layout and Partitioning"
So, over on the Import-SIG, we were talking about the implementation
and terminology for PEP 382, and it became increasingly obvious that
things were, well, not entirely okay in the "implementation is easy
to explain" department.
Anyway, to make a long story short, we came up with an alternative
implementation plan that actually solves some other problems besides
the one that PEP 382 sets out to solve, and whose implementation a
bit is easier to explain. (In fact, for users coming from various
other languages, it hardly needs any explanation at all.)
However, for long-time users of Python, the approach may require a
bit more justification, which is why roughly 2/3rds of the PEP
consists of a detailed rationale, specification overview, rejected
alternatives, and backwards-compatibility discussion... which is
still a lot less verbiage than reading through the lengthy Import-SIG
threads that led up to the proposal. ;-) (The remaining 1/3rd of
the PEP is the short, sweet, and easy-to-explain implementation detail.)
Anyway, the PEP has already been discussed on the Import-SIG, and is
proposed as an alternative to PEP 382 ("Namespace packages"). We
expect, however, that many people will be interested in it for
reasons having little to do with the namespace packaging use case.
So, we would like to submit this for discussion, hole-finding, and
eventual Pronouncement. As Barry put it, "I think it's certainly
worthy of posting to python-dev to see if anybody else can shoot
holes in it, or come up with useful solutions to open
questions. I'll be very interested to see Guido's reaction to it. :)"
So, without further ado, here it is:
PEP: XXX
Title: Simplified Package Layout and Partitioning
Version: $Revision$
Last-Modified: $Date$
Author: P.J. Eby
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 12-Jul-2011
Python-Version: 3.3
Post-History:
Replaces: 382
Abstract
This PEP proposes an enhancement to Python's package importing
to:
* Surprise users of other languages less,
* Make it easier to convert a module into a package, and
* Support dividing packages into separately installed components
(ala "namespace packages", as described in PEP 382)
The proposed enhancements do not change the semantics of any
currently-importable directory layouts, but make it possible for
packages to use a simplified directory layout (that is not importable
currently).
However, the proposed changes do NOT add any performance overhead to
the importing of existing modules or packages, and performance for the
new directory layout should be about the same as that of previous
"namespace package" solutions (such as ``pkgutil.extend_path()``).
The Problem
===
.. epigraph::
"Most packages are like modules. Their contents are highly
interdependent and can't be pulled apart. [However,] some
packages exist to provide a separate namespace. ... It should
be possible to distribute sub-packages or submodules of these
[namespace packages] independently."
-- Jim Fulton, shortly before the release of Python 2.3 [1]_
When new users come to Python from other languages, they are often
confused by Python's packaging semantics. At Google, for example,
Guido received complaints from "a large crowd with pitchforks" [2]_
that the requirement for packages to contain an ``__init__`` module
was a "misfeature", and should be dropped.
In addition, users coming from languages like Java or Perl are
sometimes confused by a difference in Python's import path searching.
In most other languages that have a similar path mechanism to Python's
``sys.path``, a package is merely a namespace that contains modules
or classes, and can thus be spread across multiple directories in
the language's path. In Perl, for instance, a ``Foo::Bar`` module
will be searched for in ``Foo/`` subdirectories all along the module
include path, not just in the first such subdirectory found.
Worse, this is not just a problem for new users: it prevents *anyone*
from easily splitting a package into separately-installable
components. In Perl terms, it would be as if every possible ``Net::``
module on CPAN had to be bundled up and shipped in a single tarball!
For that reason, various workarounds for this latter limitation exist,
circulated under the term "namespace packages". The Python standard
library has provided one such workaround since Python 2.3 (via the
``pkgutil.extend_path()`` function), and the "setuptools" package
provides another (via ``pkg_resources.declare_namespace()``).
The workarounds themselves, however, fall prey to a *third* issue with
Python's way of laying out packages in the filesystem.
Because a package *must* contain an ``__init__`` module, any attempt
to distribute modules for that package must necessarily include that
``__init__`` module, if those modules are to be importable.
However, the very fact that each distribution of modules for a package
must cont
Re: [Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
On Mon, Jul 18, 2011 at 3:03 AM, Ned Deily wrote: > I think adding the requirement to mandate hard link vs soft link usage > is an unnecessary and unwarranted attempt at optimization. For > instance, IIRC, the OS X installers don't use any hard links: that may > complicate the install, plus hard links on OS X HFS* file systems are a > bit of a kludge and not necessarily more efficient than symlinks. It's > not a big deal but perhaps the wording should be changed to make a > suggestion about hard links vs syminks rather than mandate which should > be used. Ah, OK. The wording's been changed so that symbolic links will be installed on Mac OS X and hard links elsewhere (although maybe symbolic links are also better on certain other platforms; I'm not sure). I do think that specific instructions must be given (rather than just a suggestion) because it's indicating what must be done to CPython. The instructions *should* be as close as possible to what the installer already does, but I'm not entirely sure what the installer does by default, and the hard-link recommendation was based off a cursory inspection of my own system, so further input from yourself and the rest of python-dev would be appreciated. Nick, can you please apply the patch (will be sent in the following email) to the PEP SVN as soon as we get the hard-link issue is figured out? Alternatively, could you provide me write access to just the pep-0394.txt file so I can update it myself? Thanks. -Kerrick Staley ___ 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] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)
$ svn diff Index: pep-0394.txt === --- pep-0394.txt(revision 88866) +++ pep-0394.txt(working copy) @@ -1,5 +1,5 @@ PEP: 394 -Title: The "python" command on Unix-Like Systems +Title: The "python" Command on Unix-Like Systems Version: $Revision$ Last-Modified: $Date$ Author: Kerrick Staley , @@ -53,10 +53,14 @@ * When reinvoking the interpreter from a Python script, querying ``sys.executable`` to avoid hardcoded assumptions regarding the interpreter location remains the preferred approach. +* The ``idle``, ``pydoc``, and ``python-config`` binaries from Python 2.0 +should likewise be available as ``idle2``, ``pydoc2``, and ``python2-config``, +with the original commands invoking these binaries by default, but possibly +invoking the Python 3.0 versions instead. These recommendations are the outcome of the relevant python-dev discussion in -March 2011 [1] (NOTE: More accurately, they will be such once that "Draft" -status disappears from the PEP header, it has been moved into the "Other +March to July 2011 [1] (NOTE: More accurately, they will be such once that +"Draft" status disappears from the PEP header, it has been moved into the "Other Informational PEP" section in PEP 0 and this note has been deleted) @@ -142,13 +146,21 @@ Application to the CPython Reference Interpreter -While technically a new feature, the ``make install`` command and the Mac OS -X installer in the 2.7 version of CPython will be adjusted to create the -new ``python2`` command in addition to the existing ``python`` and -``python2.7`` commands. This feature will first appear in CPython 2.7.2. +While technically a new feature, the ``make install`` command and the Mac +OS X installer in the 2.7 version of CPython will be adjusted to create the +``python2.7``, ``idle2.7``, ``pydoc2.7``, and ``python2.7-config`` binaries, +with ``python2``, ``idle2``, ``pydoc2``, and ``python2-config`` as links to +the respective binaries. On Mac OS X, these will be symbolic links; on other +platforms, they will be hard links, because hard links improve performance +on filesystems other than Mac OS X's HFS. ``python``, ``idle``, ``pydoc``, +and ``python-config`` will be created as symbolic links to these links. +This feature will first appear in CPython 2.7.2. -The ``make install`` command in the CPython 3.x series will continue to -install only the ``python3`` symlink for the foreseeable future. +The ``make install`` command in the CPython 3.x series will similarly install +the ``python3.x``, ``idle3.x``, ``pydoc3.x``, and ``python3.x-config`` binaries +(with appropriate ``x``), and ``python3``, ``idle3``, ``pydoc3``, and +``python3-config`` as symbolic links on Mac OS X and as hard links on other +platforms. Impact on PYTHON* Environment Variables @@ -166,27 +178,12 @@ Exclusions of MS Windows -This PEP deliberately excludes any proposals relating to Microsoft Windows. -The use of parallel installs on Windows suffers from numerous issues, -including the "last installed wins" behaviour for handling of file -associations, a lack of universal robust symlink support for easy aliasing of -commands, the fact that the Python executable is not available on ``PATH`` by -default, the fact that the ``python.exe`` and ``pythonw.exe`` names are -used for both Python 2 and Python 3 binaries and the lack of distinction -between the different Python versions when the Start menu shortcuts are -divorced from their containing folders (e.g. when they appear in the -"Recently Used" list. +This PEP deliberately excludes any proposals relating to Microsoft Windows: +devising an equivalent solution for Windows was deemed too complex to handle +here. PEP 397 and the related discussion on the python-dev mailing list address +this issue. -While these questions are well worth addressing, they do not have easy -answers. The authors of this particular PEP aren't inclined to even begin -trying to answer them, but anyone that wants to tackle them should feel free -to start working on their own PEP. -Note that, while the topic has been excluded from this PEP, there is plenty of -material in the linked python-dev discussion that may be useful in the design -and implementation of a Windows-specific solution. - - References == ___ 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
