The Python Windows installer[1] should automatically add the Python and
Scripts directories to the PATH environment variable. (If you like,
you can also provide a checkbox in the installer GUI that users can
uncheck if they don't want this behavior.)

This issue was discussed at http://nabble.com/Why-does-Python-never-add-
itself-to-the-Windows-path--td8044465.html and the majority consensus
was that this is a good idea, but nobody has volunteered to implement
it.

^ [1]. The installer is generated by the code at
http://svn.python.org/view/python/trunk/Tools/msi/

I still don't think such a change should be made, hence I reject this
report as "won't fix". Discussion shouldn't start again on this matter
until there is an actual patch to review.

Martin, at the time I read the python-list thread, I didn't pay any
attention to the posts' authors. Only now did I realize you were one
of the posters. Oops.

I already know the basic ideas about creating MSIs with Wise from a
past job. So now I researched and thought about this particular
problem for several hours. I've learned that Windows Installer is able
to add ...\python and ...\python\scripts to the PATH during
installation. It cannot[1] remove them at uninstallation. [ WiX, and
its superior competitor MAKEMSI, each provide slightly higher-level
abstractions[2][3] on top of what Windows Installer provides[4] to make
this slightly easier, but not by that much. But I will assume you
don't plan to spend days or weeks of your spare time on migrating away
from msilib. :-) ]

Here are the rough notes I've made up so far on how to do this:

• make a new method add_environment. In it:
  • call start_component to create components "modify_path_per_user"
    and "modify_path_per_machine"
  • call add_data to create an Environment table. It should have
    two rows[5]:
    • Name:"=PATH" Value:"[TARGETDIR];[TARGETDIR]\Scripts;[~]"
      Component:"modify_path_per_user"
    • Name:"=*PATH" Value:"[TARGETDIR];[TARGETDIR]\Scripts;[~]"
      Component:"modify_path_per_machine"

Another difficult part is the UI. Then there's the issue of switching
which of the two components are installed based on whether it's per-
user or per-machine and also based on whether the user specifies via
the UI that they want their PATH changed. I have to think more about
that, and I'm already tired of researching.

Remember that Windows Installer cannot undo its PATH changes at
uninstall time. So, before I consider proceeding further, let me
verify a few things with you.

1. [TARGETDIR] will stay on the path. I think that is fine, since the
   python.exe will be gone, so will never be executed. Do you agree?

2. [TARGETDIR]\scripts will also stay on the path. And it may still
   contain scripts installed by the user or by third-party installers like
   the SCons installer. I don't know enough about how Python works to
   know if that's a problem. Is it a problem?

P.S. Would you prefer to discuss this by something more synchronous
like telephone (I will pay the tolls) or instant messaging?

P.P.S. Now that I have realized how complicated Python installation
actually is, and how hard it is to design the tables of and write
raw .MSI files, I have a new appreciation for the work you've done on
making a Python MSI installer. Thank you very much for having done
so. Also, now that I have started researching how much work is
necessary to get this done, I realize why you don't want to code it
yourself. :-)

I don't know if I will end up actually managing to come up with a patch.

^ [1]. I have inferred this fact based on
http://www.isg.ee.ethz.ch/tools/realmen/det/msi.en.html -- scroll down
to the "Setting the PATH" section
^ [2]. http://blogs.technet.com/alexshev/archive/2008/03/28/from-msi-
to-wix-part-13-installable-items-environment-variable.aspx
^ [3]. http://makemsi-manual.dennisbareis.com/path.htm
^ [4]. http://msdn.microsoft.com/en-us/library/aa368369(printer).aspx
^ [5]. Search inside the page http://msdn.microsoft.com/en-
us/library/aa368369(printer).aspx for "If the package can be installed
per-user or per-machine" to see why you need two rows.

1. [TARGETDIR] will stay on the path. I think that is fine, since the
   python.exe will be gone, so will never be executed. Do you agree?

Completely disagree. Adding something to PATH is nearly unacceptable
clutter even during installation, and completely unacceptable (to me)
after uninstallation. If you install Python several times, will the path
get longer and longer?

In principal, uninstallation should completely undo installation. There
should be only plausible exceptions, e.g. when the user still has files
in a directory, deleting the directory is unacceptable as it would also
delete the files. The big problem where the Python installer (and MSI
in general) fails is uninstallation of file associations, which doesn't
restore the file assocations to what they were (of course, that software
might be gone)

2. [TARGETDIR]\scripts will also stay on the path. And it may still
   contain scripts installed by the user or by third-party installers like
   the SCons installer. I don't know enough about how Python works to
   know if that's a problem. Is it a problem?

To me, any change to PATH is a problem... (I really think that software
installation should never ever touch it - this aspect of the operating
system completely belongs to the user resp. the system administrator)

P.S. Would you prefer to discuss this by something more synchronous
like telephone (I will pay the tolls) or instant messaging?

I don't think this can be done for 2.6, so there is no need for
synchrony - there is plenty of time to come up with a solution
for 2.7/3.1. In any case, I'll be away for the next three weeks.

It cannot[1] remove them at uninstallation.
^ [1]. I have inferred this fact based on
http://www.isg.ee.ethz.ch/tools/realmen/det/msi.en.html -- scroll down
to the "Setting the PATH" section

I think this is incorrect. You cannot uninstall the path through
unsetting the PATH variable, sure. So perhaps using the Environment
table is the wrong approach in the first place. You can do nearly
anything in a custom action, so it should be possible to remove the
path entry on uninstallation by means of a custom action.

If such a solution was designed, there would still be many questions,
such as:

• what is the actual problem being solved? Is it real? Could there
  be other solutions to that problem (such as installing things into
  system32, or somewhere else that is on the PATH already)?
• if the path is modified, should the Python directory be added to
  the beginning or the end?
• IMO, this feature needs to be customizable, and IMO, it must be
  turned off by default. So how should such customization be offered?
  These questions can partially be discussed in the tracker item proposing
  the patch. The very end-user related aspects of it need to be discussed
  on python-dev (perhaps taking a poll whether this is desirable, whether
  it should be optional, and if so, what the default should be)

Reopening this issue since bpo-9228 was closed as a duplicate of this one. Given the significant level of user demand for this behaviour, it should NOT be closed again until a PEP has been written and either accepted or rejected. If such a PEP is not written and championed through to a final decision, then this issue should remain open indefinitely.

Such a PEP should canvas the option of installing development shell launch scripts into the Start menu and updating the documentation accordingly as an alternative to messing with the system-wide PATH setting.

An install-time option to allow power users to disable the PATH manipulation should also be considered. The interests of novice Python users and experienced Windows system administrators are not in alignment on this topic, and the current installer behaviour favours the latter at the expense of the former.

Now, another factor to consider is that Windows 7 makes manipulating the system PATH even more difficult to do correctly (e.g. see http://www.symantec.com/connect/forums/wise-7-win-7-problems-updating-environment-variable-current-user).

I believe ActiveState handle this by making the PATH modification optional and having it off by default (I found docs for ActivePerl stating this explicitly, but no equivalent for ActivePython).

Regardless, for a product intended for heavy command line use, we should definitely do better in either providing a way for users to request that the installer modify PATH directly, or else a way to easily launch a command shell with PATH updated appropriately.

I believe ActiveState handle this by making the PATH modification
optional and having it off by default (I found docs for ActivePerl
stating this explicitly, but no equivalent for ActivePython).

ActivePython 2.x has it on by default.

See tightly related ActivePython issue [1] regarding the way directories are added to the PATH environment variable.

Also, here's qooxdoo (a well-known JavaScript framework) giving out instructions [2] on how to use the official python distribution due to the missing path and file association treatment (and also redirecting the preference to ActivePython for that).

(Setting to all versions as I believe this isn't addressed in any previous or current release.)

[1] http://bugs.activestate.com/show_bug.cgi?id=92615
[2] http://manual.qooxdoo.org/current/pages/getting_started/troubleshooting.html#windows

FWIW I have an installer built which optionally adds to the path. It's not complete - still needs some GUI work to hook it all up, but I'll be proposing it shortly.

Helder: please don't change tracker settings unless you know what they are for. Python 2.6 and 3.1 can't possibly see any change here since they are in security fix mode, and can't see any fixes affecting this issue. Likewise, 2.7 and 3.2 will only see bug fixes. As the lack of supporting changes to Path isn't a bug (but possibly a missing feature), these versions can't see the bug, either. Putting 3.4 and 3.3 into an issue is just nonsense at this point: if the issue gets resolved for 3.3 before 3.4 is released, it will never be an issue for 3.4.

@brian: glad to know about it. It will surely help, as many Windows users aren't much comfortable with the console already, and even less comfortable for tweaking the system at this level (apart from permission issues, etc.). ;-)

@martin: you're right, sorry. I'd swear I several versions selected and only a couple missing, but probably I was tricked by a related/duplicate issue. Better read the manual next time... :-)

Attached is an in-progress patch.

I still need to figure out how to hook up the GUI to condition the path manipulation. A few locations have said to do conditional environment modification via the Component table, but I haven't been able to get some placeholder in there based on whether or not PREPEND is true/false from the GUI.

Right now if you build an installer with this it will always modify the path even if you haven't chosen the option to do so.

http://briancurtin.com/python-dev/python-3.3.15390.msi is an example installer. Note that it's not a signed installer, it's unofficial, and I don't support it whatsoever. It's merely provided as a sample of what the GUI looks like, and you can install it, see what happens, then uninstall and see that the path modification is properly undone.

I just saw Brian Curtin's Pycon 2012 presentation. If a goal is to make it easy for new users to run python, consider installing a desktop shortcut. This would make it very easy for new users (easier than starting up a shell).

This is independent of the Path changes discussed here. Those should be made (or not made) on their own merit, since most users will eventually need the Path to be properly adjusted.

Attached is bpo-3561.diff which adds a path option, off by default, as a feature to be installed. I've tested installation and un-installation with the feature both installed and not installed and it seems to work fine for me.

http://briancurtin.com/python-dev/python-3.3.15437.msi is an installer built with this patch. http://briancurtin.com/python-dev/CustomizePage.png is simply a screenshot of the page where you choose to enable this feature.

@brian -- to clarify,

(1) Does bpo-3561.diff completely supersede prependpath_in-progress.diff? (And should that be the one currently subject to review?)

(2) What happens with multiple installations? Do users have to manually unset the path to avoid surprises? Does this become obsolete if the py.exe shim delegating to the appropriate py* is included with 3.3? Does installing 3.3.2 in over top of 3.3.1 add the directory to the path twice?

UI-wise, I'm not sure why it looks like an installable component rather than a separate checkbox. Is it a limitation of the installation software?

I unlinked the old diff. bpo-3561.diff is the one that matters.

As for what happens with multiple installations, it's no different than how you'd already be managing it or anything else like it. If you install 2.7 with the path option enabled and then you install 3.2 with the path option enabled, 3.2 goes in front of 2.7. The installations don't touch each other. If we want to get smart and detect other installations on the Path, I believe this gets a lot more complicated.

It does not become obsolete with the launcher. The launcher solves a wider problem in a different way. You could just switch to the launcher if you wanted to, but because we (probably will) have that feature doesn't mean the bare python.exe can't grow this functionality. People have been asking for it for years. It's the first step of every tutorial on the internet. It takes up a special page on the information for a sprint I just saw.

As for the question of 3.3.2 over 3.3.1: I'm not sure yet. I'll build a few installers with different versions and run some upgrades to see what happens. We're using MSI's builtin ability to manage everything here, so I would imagine it knows what to do, but I'll confirm.

UI-wise, I'm not sure why it looks like an installable component rather than a separate checkbox. Is it a limitation of the installation software?

I originally did it as a separate check box UI-wise but couldn't hook that into be an actual "Feature" in MSI terms. The way it's currently done allows it to be added to certain tables, allowing us to conditionally modify the "Environment" table which contains the optional path addition.

I am by no means an MSI expert. This is just the way Martin and I talked about it at PyCon and the way I've seen it done around the web. If there's a way to tie a checkbox to the Feature table, I would like that.

UI-wise, I'm not sure why it looks like an installable component
rather than a separate checkbox. Is it a limitation of the
installation software?

You are misinterpreting the UI. The list is not of "installable components",
but of "features". Adjusting the path is a feature just as registering the
.py extension. That feature can be installed and uninstalled.

IANANSOE (I am not a native speaker of English), but it seems to me that "Prepend path" is a bit terse, in particular since "Path" is being prepended *to*. How about "Add python.exe to the search path"? That it is added to the beginning could be elaborated (i.e. prepended) in the feature description.

Agreed. I will work up a more friendly text to go along with the feature.

Here's a patch with better wording, and here's a screenshot of what the feature selection looks like with that text: http://i.imgur.com/k7e12.png

A minor thing: The capitalization of the feature names is inconsistent.

The attached patch changes the feature text to "Add python.exe to Path". I'm not sure the word "search" adds much there anyway.

An additional change here that I think would be beneficial is a better description text, immediately covering the benefit of this feature. I had to do some minor resizing of the relevant text boxes, but the description is now...

Prepend C:\Python33 to the system Path variable. This allows you to type 'python' into a command prompt without needing the full path.

Brian: The patch is fine, please apply.

New changeset 4e9f1017355f by Brian Curtin in branch 'default':
Fix bpo-3561. Add an option to place the Python installation into the Windows Path environment variable.
http://hg.python.org/cpython/rev/4e9f1017355f

Now that the feature is in, I'm going to track the few places we need to document it in bpo-14668.

I am really happy to see this as an option in the Windows installer. This has a potential to really reduce the support burden on training new Windows users to use Python and will really help normalize the experience for new users between Windows and POSIX platforms.

Unfortunately, from what I can tell, this is OFF by default. I think that is a mistake. The default for something like this is really important because without new users being explicitly told to set it, new users will not. Most new Python users are just going to take the default values and still be confused by not being able to open the console and run python as in the instructions for various new user tutorials (i.e. web frameworks, scientific computing, etc).

I understand the issue with installing multiple Python versions, but generally speaking people are going to want to install the latest version and have that be on their path. My sense is that there is a relative minority of Windows users that care about multiple versions of Python would not want their path to be updated. Unfortunately the ones who don't want their path updated are the ones that have driven the installer development at this point and will be most vocal in the Python community.

I suggest a compromise which makes adding to the PATH default to ON if another Python version is not installed and/or on the PATH and default to OFF otherwise.

It looks like you can use a condition table plus the feature table to check for Python in the path buy I am not exactly an expert with MSI. My quick check found:
http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx which says you can do a search for an installed component and then set a property. This should then allow setting of the default state of the feature based on a condition.

I really recommend that while we still have a chance to make a change that we think about the goal of this feature and whether making it disabled by default achieves those goals.

lambacck: I'm -1, but I'm willing to yield to anybody who wants to be "in charge" of this feature (i.e. Brian, or the release manager). I'm not willing yield to "mere" user requests, as regular users won't have to deal with negative consequences that enabling this by default may have.

I'm quite opposed to your proposed conditional approach; I think this will be highly confusing to users.

The reason for the conditional approach was to attempt to account for the "negative consequences" of adding enabling this by default. i.e. if you are already a Python developer and install a new version, it will be status quo, but if you are a new Python developer then you will be able to run instructions for packages that work perfectly fine on Windows but are maintained and documented by POSIX users and don't understand that the steps to make things work on Windows are different.

I don't care one way or the other about the compromise position but I strongly believe that if someone is installing Python on Windows for the first time they should get a good experience without having to know of the existence of docs like: http://docs.python-guide.org/en/latest/starting/install/win/

This tweet https://twitter.com/#!/zedshaw/status/194853198006198272 is characteristic of the sentiment that non-Windows users have about training Windows users to develop with Python. At the PyCon web summit several people who have been doing training lately have said that their solution is to get windows users to run a Linux Virtual Machine because the Windows Python experience is so bad for new Windows developers. This is one relatively easy place where we can make that experience better.

Unfortunately, from what I can tell, this is OFF by default. I think
that is a mistake. The default for something like this is really
important because without new users being explicitly told to set it,
new users will not. Most new Python users are just going to take the
default values and still be confused by not being able to open the
console and run python as in the instructions for various new user
tutorials (i.e. web frameworks, scientific computing, etc).

To put things in perspective, the default under POSIX ("make install")
is to make the installed version the default (by copying it
into /usr/bin/python3). To change that behaviour, you have to use "make
altinstall" explicitly.

[Jeff Dean]

If a goal is to make it easy for new users to run python, consider installing a desktop shortcut.
This would make it very easy for new users (easier than starting up a shell).
This is independent of the Path changes discussed here.

Hi Jeff; thanks for the suggestion. Could you open another bug report for it? It’s much more manageable to have one request per report. Thanks in advance.

I found about this enhancement via Python Insider blog post [1] that also asked adding comments to this issue. Here are mine:

1. Great to see that this is finally done!

2. Is only Python installation directory added into PATH? Why not also Scripts directory under it as originally requested in this issue? As a developer of a Python based test automation tool, just adding Python into PATH doesn't help us because our tool's launcher scripts still aren't found unless PATH is manually edited.

3. I would also prefer this to be on by default.

[1] http://blog.python.org/2012/05/recent-windows-changes-in-python-33.html

2. Yes, only the installation directory, because that's the only directory we create. Scripts is created by distutils/packaging, but perhaps we could add it since it is widely used. Anyone have an opinion?

3. Do you have a reason? Many tools that offer path manipulation do not do so by default because it changes how the system operates. If we put this on by default, it will change how a lot of scripts are executed without people expecting it. It's easy to click through an installer like Python's because it's not flashy and there aren't a lot of options as it is. If we just let people click through, things are going to break a lot more than if we make people ask for it.

I could see it becoming a default in a future release once it has been in the wild for a while, but I think we're going to run into a lot of problems if we just flip it right away.

Being on by default would just be easier. If it's off, we still need to separately instruct users to turn it on. That's obviously a lot easier than instruction them to change environment variables, so I don't feel too strongly about it.

Not adding Scripts into PATH, on the other hand, would make this enhancement pretty useless for us. If it's considered confusing that the installer adds a directory it doesn't create into PATH, perhaps the installer could be changed to also create that directory.

For 3, installing the PEP-397 launcher will be the long term "on-by-default" solution.

For 2, adding the Scripts subdirectory seems reasonable.

FWIW, Window used to have *very* severe restrictions on the maximum length of PATH, as well as gratuitously long names for standard executable file locations. This made conscientious developers understandably reluctant to mess with PATH, because adding to the start could break other elements of the user's system, while adding to the end wasn't reliable.

This is much less of an issue these days, as Windows is a lot more tolerant of ridiculously long PATH definitions.

2. Yes, only the installation directory, because that's the only
   directory we create. Scripts is created by distutils/packaging, but
   perhaps we could add it since it is widely used. Anyone have an
   opinion?

Fine with me. To create an empty directory, an entry into the CreateFolder
table needs to be made. This isn't yet supported in msilib.py, but should
be a method on Directory.

I'm strongly opposed to enabling this by default at least for 3.3, but does anyone think something like this dialog http://i.imgur.com/18zPD.png be helpful? After choosing the directory to install to and before choosing the features, it's a simple dialog explaining that the Path feature is available and what it does.

Attached is the patch.

Chris Lambacher

On Wed, Apr 25, 2012 at 10:50 AM, Martin v. Löwis added the comment:

lambacck: I'm -1, but I'm willing to yield ...
regular users won't have to deal with negative
consequences that enabling this by default may have.

I'm quite opposed to your proposed conditional approach;
I think this will be highly confusing to users.

Could you clarify what you think will be confusing? I see (a slight
variant of) Chris Lambacher's conditional approach as the obvious best
choice, if it is feasible.

(1) The default is "What you are already doing."
(2) If this is your only install, then assume you do want it on the
path, as many newbies would.

The only tweak is that if there is already a path to an
*older-but-compatible* version, then its path entry should be replaced
(not added to).

Or are you concerned that there may be differences of opinion on
whether or not 3.4 is sufficiently compatible with 3.3, and that
making the default context-sensitive will cause this to be Python's
problem, rather than the application's?

-jJ

On Thu, May 24, 2012 at 8:11 PM, Brian Curtin
<brian@python.org> added the comment:

does anyone think something like this dialog http://i.imgur.com/18zPD.png be helpful?

yes.

After choosing the directory to install to and before choosing
the features, it's a simple dialog explaining that the Path
feature is available and what it does.

But it might make sense to put that on the same screen where you
choose whether or not to check the box, even if that box (ands it
checkedness state) also gets carried over to a choose-all-options
screen.

So I have a patch that does most of what my previous message shows, but I can't seem to complete it. I don't know if I'm misunderstanding something or this just can't be done, but I could use the help of someone who understands MSI things much better than I can.

Attached is the patch which makes this (http://i.imgur.com/415Y1.png) screen possible. The problem is that I can't seem to hook up the Yes and No buttons to set the path feature to install or not on the next screen, the Feature selection page.

http://ubuntuone.com/1GfW3hasOIDydQEAweOoKr is a link to an installer built with that patch if anyone wants to click through and it and see if it's worth adding in that form.

These things are best studied with msiexec ... /l*v python.log, then inspecting python.log. Without looking at the trace, I'd expect that the actual installation run doesn't inherit ModifyPath from the UI run.

The installer runs actually twice - once in the user account, performing the UI sequence and collecting all information. Then in the context of the installer service, running the execute sequence to modify the system. Information is passed in properties. However, not all properties are passed, only secure properties (which I believe must be UPPERCASE, in addition to being listed as a secure property).

However, I really recommend to not introduce another secure property, but instead use a custom action, see

http://www.advancedinstaller.com/user-guide/qa-conditional-feature.html

Write a VB script, and call Session.FeatureRequestState.

As yet an alternative, and possibly the best one, there is an AddLocal ControlEvent, see

http://msdn.microsoft.com/en-us/library/windows/desktop/aa367537(v=vs.85).aspx

Associating this event with the "Yes" button should make the feature selected. Note that you can have multiple control events for a button, so you can proceed to the next dialog after having this control event.

Just a few comments on your new UI design <http://i.imgur.com/415Y1.png\>:

== Suggestion 1 ==

It seems, from your screenshot, that you plan to hide the [ Next > ]
and [ Cancel ] buttons, and show your [ Yes ] and [ No ] buttons
instead. This is doing something completely unexpected to the user.
I've used hundreds or thousands of Windows installers and IIRC never
seen such a thing.

Instead, may I suggest a checkbox:

[x] Prepend the Python folder to the PATH environment variable (recommended)

and leaving the [ Next > ] and [ Cancel ] buttons as-is.

== Suggestion 2 ==

Better yet, get rid of the screen which talks about changing the PATH
entirely. Instead, on the feature-selection screen, make the
prepend-Python-to-PATH option be selected by default.

Why not try implementing this suggestion in the next 3.3.0 beta? Then
you can see if the tech-support burden increases or decreases.

== Suggestion 1 ==

I don't think it's that unexpected. I certainly didn't come up with the idea myself - I've seen them before. Surely it might be new to some people, but is it confusing? For one, we think it's an option users should know about. It's also an option that you should explicitly enable. The yes/no seemed like an easy way to ask a yes/no question if you want it.

Instead, may I suggest a checkbox:

My first iterations of this patch used a checkbox in an additional window. I guess it's a possibility. If I can even figure out how to make any of this actually work, I'll try a version with a checkbox.

== Suggestion 2 ==

We can't make it the default. This has been explained on this issue, other issues around the tracker, on python-dev, and in a lot of other places. Believe me, as one of the biggest Python 3 advocates you can find, making Python 3 the default installation is not the right move here. If it's on by default, it absolutely will cause problems because people just click right through the installer and their system will be modified in a way that they don't want and potentially won't know how to undo. This type of change has to be exposed in a loud and non-default way to start.

I'm glad you're willing to consider using a checkbox. It seems to fit
better with the wizard paradigm, where there are always [ < Back ], [
Next > ], and [ Cancel ] buttons onscreen.

OK, I acknowledge that a lot of third-party software still depends on
Python 2. Fine. Why not modify the Python 3 installer to add Python
3 to the *end* of the PATH variable, not the beginning? Then I think
you could safely modify the PATH variable by default.

We don't need to stay with some paradigm if it's not the best way. If I can get any of these ways to work, I may post some type of survey on python-dev.

Adding to the end wouldn't make this much of a feature. Most users have already put another Python into their path, so if they decide they want to add 3.3 to it, this option barely helps them.

Anyway, just about everything relating to this feature has been discussed on the above mentioned lists over a long period of time. The feature is implemented as is, it has already been released, and it's staying that way for 3.3. All we can do is tweak the GUI.

Adding Python to the end of the PATH would very much help Windows
non-experts who don't even know what a PATH is.

IMO, when Python 3.4 comes out, it'd make sense add Python to the end
of the PATH by default. This'd help those non-experts a lot.

On 7/4/12, Brian Curtin <report@bugs.python.org> wrote:

Brian Curtin <brian@python.org> added the comment:

We don't need to stay with some paradigm if it's not the best way. If I can
get any of these ways to work, I may post some type of survey on
python-dev.

Adding to the end wouldn't make this much of a feature. Most users have
already put another Python into their path, so if they decide they want to
add 3.3 to it, this option barely helps them.

Anyway, just about everything relating to this feature has been discussed on
the above mentioned lists over a long period of time. The feature is
implemented as is, it has already been released, and it's staying that way
for 3.3. All we can do is tweak the GUI.

----------

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue3561\>

---

Can this issue be closed? If there are still disagreements about the UI or UX, it could be a separate 3.4 report.

As Eric says: any further issues with this change should be reported separately.

New changeset a9d34685ec47 by Brian Curtin in branch '2.7':
Backport 4e9f1017355f from bpo-3561.
http://hg.python.org/cpython/rev/a9d34685ec47