Possible Enhancement to py Launcher - set default
When a new version of python is in alpha/beta it is often desirable to have it installed for tests but remain on a previous version for day to day use. However, currently the Windows py launcher defaults to the highest version that it finds, which means that unless you are very careful you will end up having to explicitly specify your older version every time that you start python with it once you have installed the newer version. I an thinking that it would be relatively simple to expand the current launcher functionality to allow the user to set the default version to be used. One possible syntax, echoing the way that versions are displayed with the -0 option would be to allow py -n.m* to set and store, either in the registry, environment variable or a configuration file, the desired default to be invoked by py or pyw. Personally I thing that this would encourage more people to undertake testing of new candidate releases of python. I would be interested in any feedback on the value that this might add. -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer.
On 5 February 2018 at 08:10, Steve Barnes <gadgetsteve@live.co.uk> wrote:
There's a `py.ini` file that lets you set the default version. See https://docs.python.org/3.6/using/windows.html#customization for details. Is that just something you weren't aware of, or does it not address the issue you're having? Paul
I'm reluctant to expand the feature set of the launcher in this direction. It's written in C, and tightly focused on being a lightweight launcher. Adding code to manage user options and persist them to the py.ini file would be a non-trivial overhead, as well as being hard to maintain (because C code and text handling :-)) It's not that hard to manage an ini file, and if anyone wants a friendlier interface, writing such a thing in Python as a standalone utility would be easy, and far more robust, flexible and maintainable than adding it to the launcher directly (you could even add a GUI if you like ;-)). Conceded, I'm saying this from the perspective of writing and maintaining the code, and not from the UX/UI perspective. If someone wants to add this feature to the launcher, I don't mind, but *personally* I don't think it's worth it. Paul On 6 February 2018 at 10:10, Alex Walters <tritium-list@sdamon.com> wrote:
I actually like the idea of being able to modify the py.ini file to set the default from py.exe. That seams like the most intuitive thing to me.
My only request for change would be to consolidate the various tools' behavior wrt their .ini file locations. Pip, for example, wants the file in ~/pip/pip.ini, while py.exe (on Windows) wants its py.ini in $LOCALAPPDATA. If they were all in a common location (or the same file with separate sections), that would make life a tiny bit easier. Eric On Tue, Feb 6, 2018 at 3:30 AM, Paul Moore <p.f.moore@gmail.com> wrote:
There are a few different points here: 1. There's no relationship between pip and the py launcher - they are separate tools/projects. Any co-operation in terms of file locations would have to be a result of common standards. Those would normally be platform standards, not Python ones. 2. On Windows, pip.ini is in $env:APPDATA\pip, not ~/pip. Are you confusing Windows and Unix conventions? 3. $env:APPDATA and $env:LOCALAPPDATA have different functions, and the choice between the two needs to be made on a case by case basis. However, the difference between the two is subtle, and frankly is probably lost on Unix developers. So which gets used is somewhat random, in practice. But it does matter, in certain environments. I *think* the different usages here are correct (although on the systems I work on, the distinction doesn't matter in practice so I can't confirm that). 4. Python projects tend to actually be *better* at following Windows platform conventions than other applications (which often use the Unix convention of putting stuff under ~) in my experience. What looks like inconsistency is sometimes (not in the case of py vs pip, admittedly) just people transferring expectations from one platform to another (or worse, transferring expectations from Unix programs naively ported to Windows over to other Windows programs). 5. Windows history for "where you should store your application config" is a mess - inconsistencies, changes in recommendations, and use cases not catered for, abound. So even in the ideal situation, what is right now was probably wrong 5 years ago. And will likely be wrong 5 years from now (although we can hope...) But +1 on a world where config data all gets stored consistently. Oh, and can I have a pony? :-) Paul On 6 February 2018 at 14:22, Eric Fahlgren <ericfahlgren@gmail.com> wrote:
On Tue, Feb 6, 2018 at 6:47 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Right, different planets, but orbiting the same star. I was thinking about the consolidation of the Windows registry layout a year or two ago, don't recall who spearheaded that (Steve Dower?). In any case, if the various tools either followed that convention, or we came up with an ini-based one that was consistent with it and usable on Unix (.pyconf or something)... 2. On Windows, pip.ini is in $env:APPDATA\pip, not ~/pip. Are you
confusing Windows and Unix conventions?
Yeah, our Windows dev environment uses Cygwin, so I'm constantly confused. :) Here's where I see py.exe looking for its ini file (first $LOCALAPPDATA then in $SystemRoot):
Not sure how to make pip cough up similar verbose output, but when it started complaining about legacy formats, I just followed its directions and this works:
ll $USERPROFILE/pip/pip.ini -rw-r--r-- efahlgren 2017-04-30 15:51 'C:/Users/efahlgren/pip/pip.ini'
Eric
On 6 February 2018 at 15:23, Eric Fahlgren <ericfahlgren@gmail.com> wrote:
Yep, that would be an informational PEP, defining standards we expect Python applications to follow. There's a lot more Python *applications* than there are Python *distributions*, and I'm not convinced a standard for applications would get much traction (even ignoring the need they'd have for backward compatibility) but if someone wants to try to get consensus on something, then have fun! Actually, the `appdirs` project (https://pypi.python.org/pypi/appdirs) does exactly this - provides a portable interface for applications to store config data in platform-specific locations. The correct answer is probably to persuade application developers to use appdirs rather than their own schemes. Pip and py both use appdirs-compatible schemes (py doesn't use appdirs itself, as it's not written in Python, but pip does). pip: appdirs.user_config_dir('pip', appauthor=False, roaming=True) py: appdirs.user_config_dir() You could argue that appdirs offers too many options - but if all applications used appdirs, you could have that debate once with the appdirs authors, rather than having to persuade every application in turn.
Yeah, our Windows dev environment uses Cygwin, so I'm constantly confused. :)
Yuk, Cygwin. I'll refrain from commenting further :-)
Backward compatibility. When we moved to the Windows-standard location, we left in fallbacks to the old locations. I've no idea whether pip sees Cygwin as Windows-like or Unix-like, so anything could be going on beyond that. Paul
Hi all, Just want to point out that if tools can accept a config file in a cross-platform standard location (perhaps in addition to a platform-specific one), then that is incredibly useful. Just search on Github for "dotfiles", and see how many people store their configuration in a git repo, so they can just go to a fresh machine, "git clone dotfiles" in their $HOME and be fully set up. A platform-independent location also simplifies life for us who use Linux, Windows and MacOs on a daily basis. (And then there is the fact that these platform "standards" are only followed very haphazardly anyway, e.g. Windows Vim uses ~\.vimrc on Windows and not somewhere in $LOCALAPPDATA .) As an aside, I don't agree with the "appdirs" package on Linux: XDG != Linux. That may seem pedantry, but while ~/.local is perhaps not too bad for user-specific config, /etc/xdg is almost certainly the wrong location for global config any application that is not part of a desktop environment. (In fact, such a directory may not exist on a typical headless Linux install.) Stephan 2018-02-06 16:44 GMT+01:00 Paul Moore <p.f.moore@gmail.com>:
A thought for you might be to consider an option to just produce, (on request), a template config file with the default settings and commented out options then display the path to the user. This would fit in with other tools that I have come across while keeping the configuration options that the C code recognises in with the code rather than in a manual or web page that can get out of step without the complexity of being able to set and store options from within the tool itself. It is also somewhat pythonic in that the options and their documentation being in the code fits in well with pythons self documenting features. ________________________________ From: Python-ideas <python-ideas-bounces+gadgetsteve=live.co.uk@python.org> on behalf of Paul Moore <p.f.moore@gmail.com> Sent: 06 February 2018 11:30 To: Alex Walters Cc: Python-Ideas Subject: Re: [Python-ideas] Possible Enhancement to py Launcher - set default I'm reluctant to expand the feature set of the launcher in this direction. It's written in C, and tightly focused on being a lightweight launcher. Adding code to manage user options and persist them to the py.ini file would be a non-trivial overhead, as well as being hard to maintain (because C code and text handling :-)) It's not that hard to manage an ini file, and if anyone wants a friendlier interface, writing such a thing in Python as a standalone utility would be easy, and far more robust, flexible and maintainable than adding it to the launcher directly (you could even add a GUI if you like ;-)). Conceded, I'm saying this from the perspective of writing and maintaining the code, and not from the UX/UI perspective. If someone wants to add this feature to the launcher, I don't mind, but *personally* I don't think it's worth it. Paul On 6 February 2018 at 10:10, Alex Walters <tritium-list@sdamon.com> wrote:
I actually like the idea of being able to modify the py.ini file to set the default from py.exe. That seams like the most intuitive thing to me.
Python-ideas mailing list Python-ideas@python.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas&data=02%7C01%7C%7C7699d0d7669c43d7c1a608d56d5515f7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636535134571322756&sdata=KzRBDOor7TVYLAvvEza2kr%2BIKifdMOgEwATN%2BQngFyo%3D&reserved=0 Code of Conduct: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F&data=02%7C01%7C%7C7699d0d7669c43d7c1a608d56d5515f7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636535134571322756&sdata=1ZrUqumcn4c69EGmEbQMOxL30AM%2BrYkSZSVrxBT5X7E%3D&reserved=0
On Mon, Feb 5, 2018 at 6:04 AM, Paul Moore <p.f.moore@gmail.com> wrote:
I think the feature is still worth considering. Playing with .ini files should be considered a hack, while a way to change the default may be useful for many, at all skill levels. In your link, though, the recommended way to change the default is to use the environment variable %PY_PYTHON%, rather than the .ini file. But environment variables are not as key to Windows use as it is to Linux use, so the feature is still worth considering. Does the installer offer to change the default to its version, even when running it after installation? If it does, it still might be good to add an option to py.exe, because it's closest to where you'd think to want to change the setting.
While this thread has focused on the location and means of managing py.ini, I think there is a more general solution that should be considered to the original problem, as described. The problem isn't that it's difficult or non-obvious how to set the default python for the py.exe launcher (that's a possible documentation issue, and I argue a minor tooling problem), the problem is that the launcher, by default, selects the latest version of python as the default, regardless of that python's release status. Without looking at the C code (I haven't but should), I don't think it would be too difficult to teach py.exe to not auto-select dev, alpha, or beta versions of python without being told explicitly to do so. For example (for the archives, this is written in February 2018, when 3.7 is in its beta), on a system with 3.6 and 3.7 installed... py.exe myfile.py REM should run 3.6, unless shebang overrides py.exe -3.7 myfile.py REM should run 3.7 beta And after 3.7.0 final is released and installed on said system, py.exe myfile.py should run 3.7. Is this difficult to implement? Is this a bad idea?
On 7 February 2018 at 05:36, Alex Walters <tritium-list@sdamon.com> wrote:
IMO the biggest technical issue with this is that as far as I can see PEP 514 doesn't specify a way to determine if a given Python is a pre-release version. If we do want to implement this (I'm +0 on it, personally) then I think the starting point would need to be an update to PEP 514 to include that data. Paul
I don't think so. As an example, what registry keys would Anaconda write to say that Release 5.2.1.7 is a pre-release version? Or would the py launcher have to parse the version looking for rc/a/b/... tags? And distributions would have to agree on how they record pre-release version numbers? Paul On 7 February 2018 at 14:57, Alex Walters <tritium-list@sdamon.com> wrote:
Checking the Version (!=SysVersion) property should be enough (and perhaps we need to set it properly on install). The launcher currently only works with PythonCore entries anyway, so no need to worry about other distros. PEP 514 allows for other keys to be added as well (it specifies a minimum set), so we could just set one for this. “NoDefaultLaunch” or similar. Finally, if someone created a script for setting py.ini, it could probably be included in the Tools directory. Wouldn’t be run on install or get a start menu shortcut though, just to set expectations right. Top-posted from my Windows phone From: Paul Moore Sent: Wednesday, February 7, 2018 7:37 To: Alex Walters Cc: Python-Ideas Subject: Re: [Python-ideas] Possible Enhancement to py Launcher - set default I don't think so. As an example, what registry keys would Anaconda write to say that Release 5.2.1.7 is a pre-release version? Or would the py launcher have to parse the version looking for rc/a/b/... tags? And distributions would have to agree on how they record pre-release version numbers? Paul On 7 February 2018 at 14:57, Alex Walters <tritium-list@sdamon.com> wrote:
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 5 February 2018 at 08:10, Steve Barnes <gadgetsteve@live.co.uk> wrote:
There's a `py.ini` file that lets you set the default version. See https://docs.python.org/3.6/using/windows.html#customization for details. Is that just something you weren't aware of, or does it not address the issue you're having? Paul
I'm reluctant to expand the feature set of the launcher in this direction. It's written in C, and tightly focused on being a lightweight launcher. Adding code to manage user options and persist them to the py.ini file would be a non-trivial overhead, as well as being hard to maintain (because C code and text handling :-)) It's not that hard to manage an ini file, and if anyone wants a friendlier interface, writing such a thing in Python as a standalone utility would be easy, and far more robust, flexible and maintainable than adding it to the launcher directly (you could even add a GUI if you like ;-)). Conceded, I'm saying this from the perspective of writing and maintaining the code, and not from the UX/UI perspective. If someone wants to add this feature to the launcher, I don't mind, but *personally* I don't think it's worth it. Paul On 6 February 2018 at 10:10, Alex Walters <tritium-list@sdamon.com> wrote:
I actually like the idea of being able to modify the py.ini file to set the default from py.exe. That seams like the most intuitive thing to me.
My only request for change would be to consolidate the various tools' behavior wrt their .ini file locations. Pip, for example, wants the file in ~/pip/pip.ini, while py.exe (on Windows) wants its py.ini in $LOCALAPPDATA. If they were all in a common location (or the same file with separate sections), that would make life a tiny bit easier. Eric On Tue, Feb 6, 2018 at 3:30 AM, Paul Moore <p.f.moore@gmail.com> wrote:
There are a few different points here: 1. There's no relationship between pip and the py launcher - they are separate tools/projects. Any co-operation in terms of file locations would have to be a result of common standards. Those would normally be platform standards, not Python ones. 2. On Windows, pip.ini is in $env:APPDATA\pip, not ~/pip. Are you confusing Windows and Unix conventions? 3. $env:APPDATA and $env:LOCALAPPDATA have different functions, and the choice between the two needs to be made on a case by case basis. However, the difference between the two is subtle, and frankly is probably lost on Unix developers. So which gets used is somewhat random, in practice. But it does matter, in certain environments. I *think* the different usages here are correct (although on the systems I work on, the distinction doesn't matter in practice so I can't confirm that). 4. Python projects tend to actually be *better* at following Windows platform conventions than other applications (which often use the Unix convention of putting stuff under ~) in my experience. What looks like inconsistency is sometimes (not in the case of py vs pip, admittedly) just people transferring expectations from one platform to another (or worse, transferring expectations from Unix programs naively ported to Windows over to other Windows programs). 5. Windows history for "where you should store your application config" is a mess - inconsistencies, changes in recommendations, and use cases not catered for, abound. So even in the ideal situation, what is right now was probably wrong 5 years ago. And will likely be wrong 5 years from now (although we can hope...) But +1 on a world where config data all gets stored consistently. Oh, and can I have a pony? :-) Paul On 6 February 2018 at 14:22, Eric Fahlgren <ericfahlgren@gmail.com> wrote:
On Tue, Feb 6, 2018 at 6:47 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Right, different planets, but orbiting the same star. I was thinking about the consolidation of the Windows registry layout a year or two ago, don't recall who spearheaded that (Steve Dower?). In any case, if the various tools either followed that convention, or we came up with an ini-based one that was consistent with it and usable on Unix (.pyconf or something)... 2. On Windows, pip.ini is in $env:APPDATA\pip, not ~/pip. Are you
confusing Windows and Unix conventions?
Yeah, our Windows dev environment uses Cygwin, so I'm constantly confused. :) Here's where I see py.exe looking for its ini file (first $LOCALAPPDATA then in $SystemRoot):
Not sure how to make pip cough up similar verbose output, but when it started complaining about legacy formats, I just followed its directions and this works:
ll $USERPROFILE/pip/pip.ini -rw-r--r-- efahlgren 2017-04-30 15:51 'C:/Users/efahlgren/pip/pip.ini'
Eric
On 6 February 2018 at 15:23, Eric Fahlgren <ericfahlgren@gmail.com> wrote:
Yep, that would be an informational PEP, defining standards we expect Python applications to follow. There's a lot more Python *applications* than there are Python *distributions*, and I'm not convinced a standard for applications would get much traction (even ignoring the need they'd have for backward compatibility) but if someone wants to try to get consensus on something, then have fun! Actually, the `appdirs` project (https://pypi.python.org/pypi/appdirs) does exactly this - provides a portable interface for applications to store config data in platform-specific locations. The correct answer is probably to persuade application developers to use appdirs rather than their own schemes. Pip and py both use appdirs-compatible schemes (py doesn't use appdirs itself, as it's not written in Python, but pip does). pip: appdirs.user_config_dir('pip', appauthor=False, roaming=True) py: appdirs.user_config_dir() You could argue that appdirs offers too many options - but if all applications used appdirs, you could have that debate once with the appdirs authors, rather than having to persuade every application in turn.
Yeah, our Windows dev environment uses Cygwin, so I'm constantly confused. :)
Yuk, Cygwin. I'll refrain from commenting further :-)
Backward compatibility. When we moved to the Windows-standard location, we left in fallbacks to the old locations. I've no idea whether pip sees Cygwin as Windows-like or Unix-like, so anything could be going on beyond that. Paul
Hi all, Just want to point out that if tools can accept a config file in a cross-platform standard location (perhaps in addition to a platform-specific one), then that is incredibly useful. Just search on Github for "dotfiles", and see how many people store their configuration in a git repo, so they can just go to a fresh machine, "git clone dotfiles" in their $HOME and be fully set up. A platform-independent location also simplifies life for us who use Linux, Windows and MacOs on a daily basis. (And then there is the fact that these platform "standards" are only followed very haphazardly anyway, e.g. Windows Vim uses ~\.vimrc on Windows and not somewhere in $LOCALAPPDATA .) As an aside, I don't agree with the "appdirs" package on Linux: XDG != Linux. That may seem pedantry, but while ~/.local is perhaps not too bad for user-specific config, /etc/xdg is almost certainly the wrong location for global config any application that is not part of a desktop environment. (In fact, such a directory may not exist on a typical headless Linux install.) Stephan 2018-02-06 16:44 GMT+01:00 Paul Moore <p.f.moore@gmail.com>:
A thought for you might be to consider an option to just produce, (on request), a template config file with the default settings and commented out options then display the path to the user. This would fit in with other tools that I have come across while keeping the configuration options that the C code recognises in with the code rather than in a manual or web page that can get out of step without the complexity of being able to set and store options from within the tool itself. It is also somewhat pythonic in that the options and their documentation being in the code fits in well with pythons self documenting features. ________________________________ From: Python-ideas <python-ideas-bounces+gadgetsteve=live.co.uk@python.org> on behalf of Paul Moore <p.f.moore@gmail.com> Sent: 06 February 2018 11:30 To: Alex Walters Cc: Python-Ideas Subject: Re: [Python-ideas] Possible Enhancement to py Launcher - set default I'm reluctant to expand the feature set of the launcher in this direction. It's written in C, and tightly focused on being a lightweight launcher. Adding code to manage user options and persist them to the py.ini file would be a non-trivial overhead, as well as being hard to maintain (because C code and text handling :-)) It's not that hard to manage an ini file, and if anyone wants a friendlier interface, writing such a thing in Python as a standalone utility would be easy, and far more robust, flexible and maintainable than adding it to the launcher directly (you could even add a GUI if you like ;-)). Conceded, I'm saying this from the perspective of writing and maintaining the code, and not from the UX/UI perspective. If someone wants to add this feature to the launcher, I don't mind, but *personally* I don't think it's worth it. Paul On 6 February 2018 at 10:10, Alex Walters <tritium-list@sdamon.com> wrote:
I actually like the idea of being able to modify the py.ini file to set the default from py.exe. That seams like the most intuitive thing to me.
Python-ideas mailing list Python-ideas@python.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas&data=02%7C01%7C%7C7699d0d7669c43d7c1a608d56d5515f7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636535134571322756&sdata=KzRBDOor7TVYLAvvEza2kr%2BIKifdMOgEwATN%2BQngFyo%3D&reserved=0 Code of Conduct: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F&data=02%7C01%7C%7C7699d0d7669c43d7c1a608d56d5515f7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636535134571322756&sdata=1ZrUqumcn4c69EGmEbQMOxL30AM%2BrYkSZSVrxBT5X7E%3D&reserved=0
On Mon, Feb 5, 2018 at 6:04 AM, Paul Moore <p.f.moore@gmail.com> wrote:
I think the feature is still worth considering. Playing with .ini files should be considered a hack, while a way to change the default may be useful for many, at all skill levels. In your link, though, the recommended way to change the default is to use the environment variable %PY_PYTHON%, rather than the .ini file. But environment variables are not as key to Windows use as it is to Linux use, so the feature is still worth considering. Does the installer offer to change the default to its version, even when running it after installation? If it does, it still might be good to add an option to py.exe, because it's closest to where you'd think to want to change the setting.
While this thread has focused on the location and means of managing py.ini, I think there is a more general solution that should be considered to the original problem, as described. The problem isn't that it's difficult or non-obvious how to set the default python for the py.exe launcher (that's a possible documentation issue, and I argue a minor tooling problem), the problem is that the launcher, by default, selects the latest version of python as the default, regardless of that python's release status. Without looking at the C code (I haven't but should), I don't think it would be too difficult to teach py.exe to not auto-select dev, alpha, or beta versions of python without being told explicitly to do so. For example (for the archives, this is written in February 2018, when 3.7 is in its beta), on a system with 3.6 and 3.7 installed... py.exe myfile.py REM should run 3.6, unless shebang overrides py.exe -3.7 myfile.py REM should run 3.7 beta And after 3.7.0 final is released and installed on said system, py.exe myfile.py should run 3.7. Is this difficult to implement? Is this a bad idea?
On 7 February 2018 at 05:36, Alex Walters <tritium-list@sdamon.com> wrote:
IMO the biggest technical issue with this is that as far as I can see PEP 514 doesn't specify a way to determine if a given Python is a pre-release version. If we do want to implement this (I'm +0 on it, personally) then I think the starting point would need to be an update to PEP 514 to include that data. Paul
I don't think so. As an example, what registry keys would Anaconda write to say that Release 5.2.1.7 is a pre-release version? Or would the py launcher have to parse the version looking for rc/a/b/... tags? And distributions would have to agree on how they record pre-release version numbers? Paul On 7 February 2018 at 14:57, Alex Walters <tritium-list@sdamon.com> wrote:
Checking the Version (!=SysVersion) property should be enough (and perhaps we need to set it properly on install). The launcher currently only works with PythonCore entries anyway, so no need to worry about other distros. PEP 514 allows for other keys to be added as well (it specifies a minimum set), so we could just set one for this. “NoDefaultLaunch” or similar. Finally, if someone created a script for setting py.ini, it could probably be included in the Tools directory. Wouldn’t be run on install or get a start menu shortcut though, just to set expectations right. Top-posted from my Windows phone From: Paul Moore Sent: Wednesday, February 7, 2018 7:37 To: Alex Walters Cc: Python-Ideas Subject: Re: [Python-ideas] Possible Enhancement to py Launcher - set default I don't think so. As an example, what registry keys would Anaconda write to say that Release 5.2.1.7 is a pre-release version? Or would the py launcher have to parse the version looking for rc/a/b/... tags? And distributions would have to agree on how they record pre-release version numbers? Paul On 7 February 2018 at 14:57, Alex Walters <tritium-list@sdamon.com> wrote:
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (8)
-
Alex Walters -
Eric Fahlgren -
Franklin? Lee -
Jan Claeys -
Paul Moore -
Stephan Houben -
Steve Barnes -
Steve Dower