[issue4485] fast swap of "default" Windows python versions

2012-06-29 Thread Tim Golden

Tim Golden  added the comment:

Effectively made redundant by PEP 397, implemented in 3.3

--
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2010-07-24 Thread Brian Curtin

Brian Curtin  added the comment:

msg77014 could bring startup time down significantly so I'm -1 on that.

Overall I've never found difficulty in running scripts with the right version 
so I don't have a strong enough opinion on any of it. I think it's probably 
something which should be baked in python-ideas for a while to get a wider 
audience to think about it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2010-07-24 Thread Mark Lawrence

Mark Lawrence  added the comment:

Hum, I think I spoke too soon.  @Brian: @Tim: what do you think about this?

--
nosy: +brian.curtin, tim.golden

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com




[issue4485] fast swap of "default" Windows python versions

2010-07-23 Thread Mark Lawrence

Mark Lawrence  added the comment:

Right now this would suit me down to the ground, as I'm running four 
maintenance versions, 2.6/7 and 3.1/2 in parallel.  But as this is a feature 
request it will not happen until 3.2 at the earliest.

--
nosy: +BreamoreBoy
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2010-05-01 Thread Andreas Lemke

Andreas Lemke  added the comment:

Python 2.5, 2.6, 3.0, etc. are not fully compatible programming languages. And 
we cannot expect that there will ever be the one and only ultimate version of 
Python (hopefully). Many of us need to have more than one of them installed 
simultaneously. Upon opening a Python file, the right version needs to be 
started. For those of us who use IDLE, we wish the right version to be started 
with “Edit with IDLE”. 

Therefore, we need a clean – pythonic – solution to this problem.

I am probably not qualified to determine the best such solution. My main 
concern is that the community takes the issue seriously.

Nevertheless, it seems to me that different file name extensions (.py25, .py26, 
.py30) would be a good candidate to solve the issue. On Windows, I set up the 
appropriate file type associations. It worked quite well, except that IDLE 
doesn't seem to recognize files with extensions other than .py.

--
nosy: +Andreas24
versions: +Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2009-09-08 Thread Matthieu Labbé

Changes by Matthieu Labbé :


--
nosy: +matthieu.labbe

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2009-08-23 Thread Daniel Harding

Daniel Harding  added the comment:

I have created a script that does essentially what Mark Tolonen
suggests.  When it is provided a script to run, it looks for a #! line
and if it exists, attempts to use that to determine which version of
python.exe to use.  It also has the ability to install itself as the
default command for running .py files in the Windows registry.

Feedback welcome.

--
Added file: http://bugs.python.org/file14775/python_runner.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2009-08-19 Thread Daniel Harding

Changes by Daniel Harding :


--
nosy: +dharding

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2008-12-05 Thread Glenn Linderman

Glenn Linderman <[EMAIL PROTECTED]> added the comment:

Ah yes, it could work as a front-end launcher, since # is a comment
character for Python anyway, so all Pythons would ignore such a line.

So that can be done completely independently of python itself, and
installed separately, and used by people that choose to.

In other words, feel free to write the program, and release it for all
that find it useful.  The sooner the better, eh?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2008-12-05 Thread Mark Tolonen

Mark Tolonen <[EMAIL PROTECTED]> added the comment:

I see it as primarily useful in this transition period between 2.x and 
3.0, since py3 scripts aren't backward compatible and I see both being 
installed for the few years.  It could be a front-end launcher 
suitable for "ftype Python.File" that inspects the script for #! and 
checks the registry for installed python versions.  That would make it 
work with older versions as well.  Probably better suited to 
discussion on c.l.p than here, but at least recorded as an idea in 
this feature request.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2008-12-05 Thread Glenn Linderman

Glenn Linderman <[EMAIL PROTECTED]> added the comment:

Since Python hasn't done that until now, it won't help much with the
transition from 2to3.  The earliest versions that could add that would
be 3.1 and 2.7, it would seem, as it is a new fetaure.  Perhaps it would
be worth doing, in planning for Python 4...


Perl has done that for many versions.  The idea is useful for running
scripts that were designed and tested with a given version of Perl, on
that same version, to avoid the need to retest working, production,
code. Even when compatibility is supposed to be retained, and every
effort is made to do so in a maintenance release, sometimes little
things sneak in, that no one ever thought to test, and didn't to have
broken... so continuing to use the version with which a production
script was last extensively tested with, is "extra safe".

The technique you suggest isn't very good for testing a particular
script with various versions of python because you'd have to edit the
script to select the version.  It is good for being "extra safe" and
ensuring that a script continues to run with a particular version of the
interpreter.

I see this issue addressing the ability, in a testing environment, to
swap what version of implicit python is invoked for scripts invoked from
either the command line or from batch files, without the need to edit
the script or the batch file.  From the command line, it is relatively
easy just to invoke the right python via "c:\pythonNN\python script",
although that gets old if you are testing a large number of scripts.  So
I see it as primarily a convenience item for a testing environment.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2008-12-05 Thread Mark Tolonen

Mark Tolonen <[EMAIL PROTECTED]> added the comment:

An extension to this idea:  Support parsing #! lines in Windows and 
select the version of Python used.  python.exe could examine:

#!/usr/bin/python30

pattern match "python##", look in the registry to see if that version 
of python is installed, and launch that python.exe instead.

--
nosy: +metolone

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue4485] fast swap of "default" Windows python versions

2008-12-02 Thread Glenn Linderman

New submission from Glenn Linderman <[EMAIL PROTECTED]>:

Here's how I set up my computer, for multiple versions.  Now to change
the "default", I just use the assoc command to change the association
for .py to one of the three listed ftypes.  Simple and quick.

c:\>ftype Python25.File
ftype Python25.File
Python25.File="C:\Python25\python.exe" "%1" %*

c:\>ftype Python26.File
ftype Python26.File
Python26.File="C:\Python26\python.exe" "%1" %*

c:\>ftype Python30.File
ftype Python30.File
Python30.File="C:\Python30\python.exe" "%1" %*

c:\>assoc .py
assoc .py
.py=Python25.File


It would be nice if the ftypes were version specific as created by the
installer; IIRC, I created the above three from the ftype Python.File as
I installed each version. 

The Python.File could still be created by default, and could still
reflect the last temporally installed version of Python... but by
documenting the version specific ftypes, the user could still switch
among versions.

I suppose there is a question of if the version should contain two or
three parts, i.e. Python253.File; and if the version should be separated
such as Python2.5.3.File; the above worked for me for the moment, but
some thought might reveal a more useful technique.

It might even be appropriate for a Python version to create 3 ftypes,
such that version N.M.O creates ftypes named PythonN.File,
PythonN.M.File, and PythonN.M.O.File.  All but the most specific one
would be subject to change when additional versions are installed.  If M
or O are zero, they should probably still be specified (as zero) in a
scheme like this, so that there would be a solid way of referring to all
the specific versions.

--
components: Installation
messages: 76731
nosy: v+python
severity: normal
status: open
title: fast swap of "default" Windows python versions
type: feature request
versions: Python 2.6, Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com