New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fast swap of "default" Windows python versions #48735
Comments
Here's how I set up my computer, for multiple versions. Now to change c:\>ftype Python25.File c:\>ftype Python26.File c:\>ftype Python30.File c:\>assoc .py It would be nice if the ftypes were version specific as created by the The Python.File could still be created by default, and could still I suppose there is a question of if the version should contain two or It might even be appropriate for a Python version to create 3 ftypes, |
An extension to this idea: Support parsing #! lines in Windows and #!/usr/bin/python30 pattern match "python##", look in the registry to see if that version |
Since Python hasn't done that until now, it won't help much with the Perl has done that for many versions. The idea is useful for running The technique you suggest isn't very good for testing a particular I see this issue addressing the ability, in a testing environment, to |
I see it as primarily useful in this transition period between 2.x and |
Ah yes, it could work as a front-end launcher, since # is a comment So that can be done completely independently of python itself, and In other words, feel free to write the program, and release it for all |
I have created a script that does essentially what Mark Tolonen Feedback welcome. |
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. |
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. |
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. |
Effectively made redundant by PEP-397, implemented in 3.3 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: