Re: [Python-Dev] Proposing the deprecation of the pyvenv script
On 18 September 2015 at 05:04, Barry Warsaw wrote: > On Sep 17, 2015, at 06:40 PM, Brett Cannon wrote: > >>I propose that the pyvenv script be deprecated in Python 3.5.1 and >>removed in Python 3.8. The reason for this proposal is because it is >>non-obvious what version of Python a pyvenv command is tied to (heck, >>it isn't necessarily obvious that it's Python 3). > > That's why in Debian/Ubuntu we include /usr/bin/pyvenv-X.Y for all supported > versions (currently 3.4 and 3.5 in Ubuntu 15.10), and then symlink > /usr/bin/pyvenv to the default one. So I'm sympathetic to this proposal. I currently use pyvenv directly, but I agree with starting a migration to only supporting the more explicit "python -m venv". There's always an inherent ambiguity on *nix with unqualified version sensitive Python commands as to whether they're referring to Python 2 or 3, as the answer often depends on *how old* the particular script is (e.g. pip and virtualenv relate to the Python 2 installation, while pyvenv relates to the Python 3 installation). There's one slightly oddity in the migration, which is that "pyvenv" will still run even if you're in an activated Python 2 virtual environment, while "python -m venv" fails. The answer is to use a qualified Python version in the latter call. I assume the change to the script will include forcing that particular deprecation warning to be visible by default. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] My collection of Python 3.5.0 regressions
Hi, Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following regressions: "OSError in os.waitpid() on Windows" http://bugs.python.org/issue25118 "Windows: datetime.datetime.now() raises an OverflowError for date after year 2038" http://bugs.python.org/issue25155 Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] My collection of Python 3.5.0 regressions
(Oh hey, I don't understand how I sent the previous email. Mistake with keyboard shortcut in Gmail?) Hi, Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following regressions: "OSError in os.waitpid() on Windows" http://bugs.python.org/issue25118 "Windows: datetime.datetime.now() raises an OverflowError for date after year 2038" http://bugs.python.org/issue25155 "3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5)" http://bugs.python.org/issue25150 It may be good to not wait too long before releasing a first 3.5.1 bugfix version :-) I just pushed fixes. We may wait a little bit for buildbots ;-) -- There are some more issues which may be Python 3.5 regressions: "Regression: test_datetime fails on 3.5, Win 7, works on 3.4" http://bugs.python.org/issue25092 "asynico: add ssl_object extra info" http://bugs.python.org/issue25114 "test_httpservers hangs on 3.5.0, win 7" http://bugs.python.org/issue25095 Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing the deprecation of the pyvenv script
On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote: >I currently use pyvenv directly, but I agree with starting a migration >to only supporting the more explicit "python -m venv". There's always >an inherent ambiguity on *nix with unqualified version sensitive >Python commands as to whether they're referring to Python 2 or 3, as >the answer often depends on *how old* the particular script is (e.g. >pip and virtualenv relate to the Python 2 installation, while pyvenv >relates to the Python 3 installation). On Debian, we often use things like -2 or -3 suffixes, but there's no naming standard, and you inevitably get to monstrosities like nose2-3. ;) For scripts which have to be Python-version specific, the slight loss of usability for `python -m blah` outweighs the ambiguity and ugliness of the direct alternative. >There's one slightly oddity in the migration, which is that "pyvenv" >will still run even if you're in an activated Python 2 virtual >environment, while "python -m venv" fails. The answer is to use a >qualified Python version in the latter call. One thing that came up in a similar discussion is pip, and the suggested move to `python -m pip`, which makes a lot of sense. However, *inside* a virtualenv, there's no ambiguity about the Python version associated with direct `pip` invocation, so it still makes sense to install that there. Cheers, -Barry pgpltiap26Kr2.pgp Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My collection of Python 3.5.0 regressions
Once Steve comes back from vacation he's going to have a lot of Windows install issues to look at. IMO, we should resolve those, and then issue 3.5.1. It's really too bad more people didn't test the installation with the release candidates, and I'm very glad that those people who did so did soI know there were a significant number of issues with the new Windows installer infrastructure that were caught and fixed before final. On Fri, 18 Sep 2015 15:18:32 +0200, Victor Stinner wrote: > (Oh hey, I don't understand how I sent the previous email. Mistake > with keyboard shortcut in Gmail?) > > Hi, > > Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following > regressions: > > "OSError in os.waitpid() on Windows" > http://bugs.python.org/issue25118 > > "Windows: datetime.datetime.now() raises an OverflowError for date > after year 2038" > http://bugs.python.org/issue25155 > > "3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of > the third-party yt module fails on Python 3.5)" > http://bugs.python.org/issue25150 > > It may be good to not wait too long before releasing a first 3.5.1 > bugfix version :-) > > I just pushed fixes. We may wait a little bit for buildbots ;-) > > -- > > There are some more issues which may be Python 3.5 regressions: > > "Regression: test_datetime fails on 3.5, Win 7, works on 3.4" > http://bugs.python.org/issue25092 > > "asynico: add ssl_object extra info" > http://bugs.python.org/issue25114 > > "test_httpservers hangs on 3.5.0, win 7" > http://bugs.python.org/issue25095 > > Victor > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My collection of Python 3.5.0 regressions
On 18/09/2015 16:27, R. David Murray wrote: Once Steve comes back from vacation he's going to have a lot of Windows install issues to look at. IMO, we should resolve those, and then issue 3.5.1. It's really too bad more people didn't test the installation with the release candidates, and I'm very glad that those people who did so did soI know there were a significant number of issues with the new Windows installer infrastructure that were caught and fixed before final. I agree very strongly with your point here. Raising umpteen issues over installation failures when a full release comes out strikes me as below the belt when there have been multiple previous releases without a squeak. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-09-11 - 2015-09-18)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open5130 (+54)
closed 31798 (+45)
total 36928 (+99)
Open issues with patches: 2270
Issues opened (67)
==
#22627: Calling timestamp() on a datetime object modifies the timestam
http://bugs.python.org/issue22627 reopened by belopolsky
#25072: CGI large POST data string truncated
http://bugs.python.org/issue25072 opened by Vincent Caloone
#25074: Bind logger and waninigs modules for asyncio __del__ methods
http://bugs.python.org/issue25074 opened by asvetlov
#25077: Compiler warnings: initialization from incompatible pointer ty
http://bugs.python.org/issue25077 opened by mgedmin
#25080: The example-code for making XML-RPC requests through proxy, fa
http://bugs.python.org/issue25080 opened by ankostis
#25081: Windows installer Upgrade->Customize->Back goes to Install pag
http://bugs.python.org/issue25081 opened by steve.dower
#25083: Python can sometimes create incorrect .pyc files
http://bugs.python.org/issue25083 opened by tzickel
#25084: remove semi-busy loop in py2.7 threading.Condition.wait(timeou
http://bugs.python.org/issue25084 opened by flavio
#25085: Windows x86-64 embeddable zip file contains test directorys
http://bugs.python.org/issue25085 opened by tds333
#25086: Windows x86-64 embeddable zip file, lot of big EXE files in di
http://bugs.python.org/issue25086 opened by tds333
#25087: Type variable substitution in type instances
http://bugs.python.org/issue25087 opened by skrah
#25089: Can't run Python Launcher on Windows
http://bugs.python.org/issue25089 opened by BreamoreBoy
#25090: IDLE: remove noisy icons from class (module) browser
http://bugs.python.org/issue25090 opened by markroseman
#25091: Windows Installer uses small font
http://bugs.python.org/issue25091 opened by terry.reedy
#25092: Regression: test_datetime fails on 3.5, Win 7, works on 3.4
http://bugs.python.org/issue25092 opened by terry.reedy
#25093: New 3.5.0 failure in test_tcl on win7
http://bugs.python.org/issue25093 opened by terry.reedy
#25094: Test_tools not working on Windows.
http://bugs.python.org/issue25094 opened by terry.reedy
#25095: test_httpservers hangs on 3.5.0, win 7
http://bugs.python.org/issue25095 opened by terry.reedy
#25097: test_logging may fail with 'Access is denied' when pywin32 is
http://bugs.python.org/issue25097 opened by zach.ware
#25098: test_uuid fails with pywin32 installed
http://bugs.python.org/issue25098 opened by zach.ware
#25099: test_compileall fails when run by unprivileged user on install
http://bugs.python.org/issue25099 opened by zach.ware
#25100: Test_distutils fails instead of skipping if no VS2015
http://bugs.python.org/issue25100 opened by terry.reedy
#25101: test_zipfile failure when run by unprivileged user with instal
http://bugs.python.org/issue25101 opened by zach.ware
#25102: Windows installer: 'precompile standard library' option should
http://bugs.python.org/issue25102 opened by zach.ware
#25103: 3.5.0 installed standard library on Windows has LF line ending
http://bugs.python.org/issue25103 opened by zach.ware
#25106: Hash computation speedup for {buffer, string, unicode}object
http://bugs.python.org/issue25106 opened by alecsandru.patrascu
#25109: test_code_module tests fail when run from the installed locati
http://bugs.python.org/issue25109 opened by doko
#25111: Broken compatibility in FrameSummary equality
http://bugs.python.org/issue25111 opened by serhiy.storchaka
#25112: Windows installer assigns non-existent icons to Python file ty
http://bugs.python.org/issue25112 opened by thijsvandien
#25114: asynico: add ssl_object extra info
http://bugs.python.org/issue25114 opened by haypo
#25115: SSL_set_verify_depth not exposed by the ssl module
http://bugs.python.org/issue25115 opened by gbremer
#25116: It failed to install Py3.5 on win2008R2
http://bugs.python.org/issue25116 opened by Kevin Zhang
#25117: Windows installer: precompiling stdlib fails with missing DLL
http://bugs.python.org/issue25117 opened by mgedmin
#25123: Logging Documentation - dictConfig disable_existing_loggers
http://bugs.python.org/issue25123 opened by coderobot
#25124: No single .msi available for 3.5 release
http://bugs.python.org/issue25124 opened by Christian.Ullrich
#25125: "Edit with IDLE" does not work for shortcuts
http://bugs.python.org/issue25125 opened by thijsvandien
#25126: Non-web installer fails without a connection when doing debug
http://bugs.python.org/issue25126 opened by thijsvandien
#25129: Rounding mode of floating-point division is not well documente
http://bugs.python.org/issue25129 opened by pitrou
#25130: Make tests more PyPy compatible
http://bugs.python.org/issue25130 opened by serhiy.storchaka
#25131: The AST for dict and set displays has the l
Re: [Python-Dev] My collection of Python 3.5.0 regressions
On 9/18/2015 9:18 AM, Victor Stinner wrote: Sadly, Python 3.5.0 comes with regressions. FYI I fixed the following regressions: The tracker needs a new keyword: '3.5regression', to match others. "OSError in os.waitpid() on Windows" http://bugs.python.org/issue25118 "Windows: datetime.datetime.now() raises an OverflowError for date after year 2038" http://bugs.python.org/issue25155 "3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5)" http://bugs.python.org/issue25150 It may be good to not wait too long before releasing a first 3.5.1 bugfix version :-) I just pushed fixes. We may wait a little bit for buildbots ;-) -- There are some more issues which may be Python 3.5 regressions: "Regression: test_datetime fails on 3.5, Win 7, works on 3.4" http://bugs.python.org/issue25092 "asynico: add ssl_object extra info" http://bugs.python.org/issue25114 "test_httpservers hangs on 3.5.0, win 7" http://bugs.python.org/issue25095 You also diagnosed another regression: "AST for dict and set displays has the lineno of the first value" https://bugs.python.org/issue25131 -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing the deprecation of the pyvenv script
On 19 September 2015 at 01:16, Barry Warsaw wrote: > On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote: > >>I currently use pyvenv directly, but I agree with starting a migration >>to only supporting the more explicit "python -m venv". There's always >>an inherent ambiguity on *nix with unqualified version sensitive >>Python commands as to whether they're referring to Python 2 or 3, as >>the answer often depends on *how old* the particular script is (e.g. >>pip and virtualenv relate to the Python 2 installation, while pyvenv >>relates to the Python 3 installation). > > On Debian, we often use things like -2 or -3 suffixes, but there's no naming > standard, and you inevitably get to monstrosities like nose2-3. ;) For > scripts which have to be Python-version specific, the slight loss of usability > for `python -m blah` outweighs the ambiguity and ugliness of the direct > alternative. > >>There's one slightly oddity in the migration, which is that "pyvenv" >>will still run even if you're in an activated Python 2 virtual >>environment, while "python -m venv" fails. The answer is to use a >>qualified Python version in the latter call. > > One thing that came up in a similar discussion is pip, and the suggested move > to > `python -m pip`, which makes a lot of sense. However, *inside* a virtualenv, > there's no ambiguity about the Python version associated with direct `pip` > invocation, so it still makes sense to install that there. Right. This is moving more into python-ideas and/or distutils-sig territory, but this point also gave me an idea regarding what we might want to do with the "python" command on Linux systems that have migrated to using Python 3 as the system Python: what if we agreed to change "python" on Linux systems to be a script that launches a "default" virtual environment stored in the user's home directory (location TBD), and similarly changed the unqualified system "pip" command to manipulate that default virtual environment? The question of "Which Python does 'python' run and 'pip' manipulate?" would then be determined by how that default virtual environment was set up rather than using a distro specific runtime switching technology. If could either be Python 2.7 based using virtualenv, or else a native Python 3 venv. Switching to a different default runtime (e.g. PyPy) would be a matter of replacing that default virtual environment with one created using a different interpreter. (This approach would likely also deal with the perennial "Should pip default to --user for global installs?" question). Presumably, we could figure out a way to make that work on Windows as well, such that "python" and "pip" *always* meant activating and working in the user's default virtual environment, if there wasn't already a virtual environment activated. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing the deprecation of the pyvenv script
Barry Warsaw writes: > One thing that came up in a similar discussion is pip, and the > suggested move to `python -m pip`, which makes a lot of sense. > However, *inside* a virtualenv, there's no ambiguity about the > Python version associated with direct `pip` invocation, so it still > makes sense to install that there. And then the poor newbie who's just following orders (eg, in mailman3/src/mailman/docs/INSTALL) will try pip'ing outside of the virtualenv for some reason, and have a WTF experience. I think we should KISS the pip command good-bye. A somewhat different way I look at it: the OS provides a shell, and you invoke aptitude (CLI) or synaptic (from clickety-clickety GUI shell) from that OS shell to manage OS packages. By analogy (always slippery but this one feels good to me), to manage python packages you should be working in the Python "shell". R does it that way with great success. Emacsen do it (with lesser success :-P ). perl and TeX don't -- but they don't have interactive shells (at least not universally available to the users). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My collection of Python 3.5.0 regressions
Mark Lawrence writes: > I agree very strongly with your point here. Raising umpteen issues > over installation failures when a full release comes out strikes me > as below the belt when there have been multiple previous releases > without a squeak. Raising issues is always useful and appropriate. It's up to Larry Hastings to decide whether he personally needs to do more work. I suspect he probably will, though. I knew these changes were risky on the lead time given, even though I don't do Windows, and I'm not a core Python developer. I would hope that Steve Dower and Larry were at least as well aware of what they were getting into, and there are a lot of Windows users we *want* to support well. (*Not* "have to", and YMMV. But the Python developer community clearly has a working consensus on supporting Windows well.) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing the deprecation of the pyvenv script
On 9/19/2015 1:24 AM, Stephen J. Turnbull wrote: Barry Warsaw writes: > One thing that came up in a similar discussion is pip, and the > suggested move to `python -m pip`, which makes a lot of sense. > However, *inside* a virtualenv, there's no ambiguity about the > Python version associated with direct `pip` invocation, so it still > makes sense to install that there. And then the poor newbie who's just following orders (eg, in mailman3/src/mailman/docs/INSTALL) will try pip'ing outside of the virtualenv for some reason, and have a WTF experience. I think we should KISS the pip command good-bye. A somewhat different way I look at it: the OS provides a shell, and you invoke aptitude (CLI) or synaptic (from clickety-clickety GUI shell) from that OS shell to manage OS packages. By analogy (always slippery but this one feels good to me), to manage python packages you should be working in the Python "shell". It is somewhat possible to do this by importing pip.main and translating pip command line calls to main() calls. I reported proof-of-concept experiments on issue 23551. To be practical, this should be wrapped in a tkinter gui. Once written, I will add it to the Idle menu. Other gui shells, could and probably would do the same. R does it that way with great success. Emacsen do it (with lesser success :-P ). perl and TeX don't -- but they don't have interactive shells (at least not universally available to the users). Am I correct in guessing that on Windows, at least, R and Emacs do *not* run in Command Prompt? -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
