Re: [Python-Dev] Adding numbering to PEP 20, the Zen of Python
Why not quoting the whole sentence? Victor Le 19 sept. 2014 03:31, Ben Hoyt benh...@gmail.com a écrit : I was emailing someone today about implementing something (for PEP 471, as it happens) and wanted to link to the Zen of Python [1] and note a particular clause (in this case If the implementation is hard to explain, it's a bad idea.). However, there are no clause numbers, so you can't refer to specific phrases. I know it's a short enough document that it probably doesn't matter. And maybe numbering them would make it less Zen. Would be handy in code reviews and the like, for example: Not very Pythonic. See PEP 20 point 5. Is it just my pedantic self, or have others wanted to do this too? [1] http://legacy.python.org/dev/peps/pep-0020/ -Ben ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 394 - Clarification of what python command should invoke
Hi, as Fedora is getting closer to having python3 as a default, I'm being more and more asked by Fedora users/contributors what'll /usr/bin/python invoke when we achieve this (Fedora 22 hopefully). So I was rereading PEP 394 and I think I need a small clarification regarding two points in the PEP: - for the time being, all distributions should ensure that python refers to the same target as python2. - Similarly, the more general python command should be installed whenever any version of Python is installed and should invoke the same version of Python as either python2 or python3. The important word in the second point is, I think, *whenever*. Trying to apply these two points to Fedora 22 situation, I can think of several approaches: - /usr/bin/python will always point to python3 (seems to go against the first mentioned PEP recommendation) - /usr/bin/python will always point to python2 (seems to go against the second mentioned PEP recommendation, there is no /usr/bin/python if python2 is not installed) - /usr/bin/python will point to python3 if python2 is not installed, else it will point to python2 (inconsistent; also the user doesn't know he's running and what libraries he'll be able to import - the system can have different sets of python2-* and python3-* extension modules installed) - there will be no /usr/bin/python (goes against PEP and seems just wrong) I'd really appreciate upstream guidance and perhaps a PEP clarification for distributions that ship both python2 and python3, but can live without python2 (and are not Arch :)). Thanks a lot! -- Regards, Slavek Kabrda ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Sep 19, 2014, at 3:31 AM, Bohuslav Kabrda bkab...@redhat.com wrote: Hi, as Fedora is getting closer to having python3 as a default, I'm being more and more asked by Fedora users/contributors what'll /usr/bin/python invoke when we achieve this (Fedora 22 hopefully). So I was rereading PEP 394 and I think I need a small clarification regarding two points in the PEP: - for the time being, all distributions should ensure that python refers to the same target as python2. - Similarly, the more general python command should be installed whenever any version of Python is installed and should invoke the same version of Python as either python2 or python3. The important word in the second point is, I think, *whenever*. Trying to apply these two points to Fedora 22 situation, I can think of several approaches: - /usr/bin/python will always point to python3 (seems to go against the first mentioned PEP recommendation) - /usr/bin/python will always point to python2 (seems to go against the second mentioned PEP recommendation, there is no /usr/bin/python if python2 is not installed) - /usr/bin/python will point to python3 if python2 is not installed, else it will point to python2 (inconsistent; also the user doesn't know he's running and what libraries he'll be able to import - the system can have different sets of python2-* and python3-* extension modules installed) - there will be no /usr/bin/python (goes against PEP and seems just wrong) I'd really appreciate upstream guidance and perhaps a PEP clarification for distributions that ship both python2 and python3, but can live without python2 (and are not Arch :)). Thanks a lot! I don’t know for a fact, but I assume that as long as Python 2.x is installed by default than ``python`` should point to ``python2``. If Python 3.x is the default version and Python 2.x is the “optional” version than I think personally it makes sense to switch eventually. Maybe not immediately to give people time to update though? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Fri, Sep 19, 2014 at 04:44:26AM -0400, Donald Stufft wrote: On Sep 19, 2014, at 3:31 AM, Bohuslav Kabrda bkab...@redhat.com wrote: Hi, as Fedora is getting closer to having python3 as a default, I'm being more and more asked by Fedora users/contributors what'll /usr/bin/python invoke when we achieve this (Fedora 22 hopefully). So I was rereading PEP 394 and I think I need a small clarification regarding two points in the PEP: - for the time being, all distributions should ensure that python refers to the same target as python2. - Similarly, the more general python command should be installed whenever any version of Python is installed and should invoke the same version of Python as either python2 or python3. The important word in the second point is, I think, *whenever*. Trying to apply these two points to Fedora 22 situation, I can think of several approaches: - /usr/bin/python will always point to python3 (seems to go against the first mentioned PEP recommendation) Definitely not that. Arch Linux pointed /usr/bin/python at Python 3 some years ago, and I understand that this has caused no end of trouble for the folks on #python. I haven't seen any sign of this being an issue on the tutor@ or python-l...@python.org mailing lists, but the demographics are quite different so that's not surprising. - /usr/bin/python will always point to python2 (seems to go against the second mentioned PEP recommendation, there is no /usr/bin/python if python2 is not installed) My understanding is that this is the intention of the PEP, at least until such time as Python 2 is end-of-lifed. My interpretion would be that the second recommendation in the PEP is just confused :-) Perhaps the PEP author could clarify what the intention is. - /usr/bin/python will point to python3 if python2 is not installed, else it will point to python2 (inconsistent; also the user doesn't know he's running and what libraries he'll be able to import - the system can have different sets of python2-* and python3-* extension modules installed) Likely to cause all sorts of problems, and I understood that this was not the intention. Perhaps it was added *only* as a grand-father clause so that people don't yell at Arch Linux See, the PEP says you're doing it wrong!. - there will be no /usr/bin/python (goes against PEP and seems just wrong) Seems like the least-worst to me. If you think of python == Python 2.x (at least for the next few years), then if Python 2.x isn't installed, there should be no /usr/bin/python either. I don’t know for a fact, but I assume that as long as Python 2.x is installed by default than ``python`` should point to ``python2``. If Python 3.x is the default version and Python 2.x is the “optional” version than I think personally it makes sense to switch eventually. Maybe not immediately to give people time to update though? Agreed. Once Python 2 is finally end-of-lifed in 2023 or thereabouts, then we can reconsider pointing /usr/bin/python at Python 3 (or 4, whatever is current by then). If Arch Linux jumped the gun by a decade or so, that's their problem :-) -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On 19 Sep 2014 17:38, Bohuslav Kabrda bkab...@redhat.com wrote: - Similarly, the more general python command should be installed whenever any version of Python is installed and should invoke the same version of Python as either python2 or python3. The important word in the second point is, I think, *whenever*. Trying to apply these two points to Fedora 22 situation, I can think of several approaches: - /usr/bin/python will always point to python3 (seems to go against the first mentioned PEP recommendation) - /usr/bin/python will always point to python2 (seems to go against the second mentioned PEP recommendation, there is no /usr/bin/python if python2 is not installed) I think this is what should happen, and the PEP is currently wrong. When writing the PEP, I don't think we accounted properly for the case where the system Python has migrated to Python 3, but the default Python for end user scripts that don't specify otherwise is still Python 2 (which is the migration strategy both Fedora and Ubuntu are adopting). How does this sound as a possible revised recommendation (keep in mind I haven't checked this against the larger context yet): The more general python command should only be installed whenever the corresponding version of Python is installed (whether python2 or python3). Regards, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
- Original Message - On 19 Sep 2014 17:38, Bohuslav Kabrda bkab...@redhat.com wrote: - Similarly, the more general python command should be installed whenever any version of Python is installed and should invoke the same version of Python as either python2 or python3. The important word in the second point is, I think, *whenever*. Trying to apply these two points to Fedora 22 situation, I can think of several approaches: - /usr/bin/python will always point to python3 (seems to go against the first mentioned PEP recommendation) - /usr/bin/python will always point to python2 (seems to go against the second mentioned PEP recommendation, there is no /usr/bin/python if python2 is not installed) I think this is what should happen, and the PEP is currently wrong. When writing the PEP, I don't think we accounted properly for the case where the system Python has migrated to Python 3, but the default Python for end user scripts that don't specify otherwise is still Python 2 (which is the migration strategy both Fedora and Ubuntu are adopting). Thanks, that was my thinking, too. How does this sound as a possible revised recommendation (keep in mind I haven't checked this against the larger context yet): The more general python command should only be installed whenever the corresponding version of Python is installed (whether python2 or python3). It seems to me that it is a bit unclear what corresponding is. Would it make sense to explicitly say that python command should be installed whenever the distro-chosen default system Python is installed? Regards, Nick. Thanks a lot -- Regards, Slavek Kabrda ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
There are many python2 only scripts with #!/usr/bin/python or #!/usr/bin/env python shebang in the world. I think Ubuntu and Fedora's strategy is better for now. On Fri, Sep 19, 2014 at 7:12 PM, Bohuslav Kabrda bkab...@redhat.com wrote: On 19 Sep 2014 17:38, Bohuslav Kabrda bkab...@redhat.com wrote: - Similarly, the more general python command should be installed whenever any version of Python is installed and should invoke the same version of Python as either python2 or python3. The important word in the second point is, I think, *whenever*. Trying to apply these two points to Fedora 22 situation, I can think of several approaches: - /usr/bin/python will always point to python3 (seems to go against the first mentioned PEP recommendation) - /usr/bin/python will always point to python2 (seems to go against the second mentioned PEP recommendation, there is no /usr/bin/python if python2 is not installed) I think this is what should happen, and the PEP is currently wrong. When writing the PEP, I don't think we accounted properly for the case where the system Python has migrated to Python 3, but the default Python for end user scripts that don't specify otherwise is still Python 2 (which is the migration strategy both Fedora and Ubuntu are adopting). Thanks, that was my thinking, too. How does this sound as a possible revised recommendation (keep in mind I haven't checked this against the larger context yet): The more general python command should only be installed whenever the corresponding version of Python is installed (whether python2 or python3). It seems to me that it is a bit unclear what corresponding is. Would it make sense to explicitly say that python command should be installed whenever the distro-chosen default system Python is installed? Regards, Nick. Thanks a lot -- Regards, Slavek Kabrda ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com -- INADA Naoki songofaca...@gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Sep 19, 2014, at 03:31 AM, Bohuslav Kabrda wrote: as Fedora is getting closer to having python3 as a default, I'm being more and more asked by Fedora users/contributors what'll /usr/bin/python invoke when we achieve this (Fedora 22 hopefully). So I was rereading PEP 394 and I think I need a small clarification regarding two points in the PEP: As Nick points out, I think that the Fedora and Debian ecosystems are aligned on what we *should* do, even if the PEP text needs updating. The way I look at it is that /usr/bin/python is user interface. Distributions are completely free to choose whichever Python they want for system scripts, and it's great to see that Fedora is well on their way to making Python 3 the default for system scripts. Debian is also making good progress, though we likely won't complete the transition until Jessie+1. But none of that matters for /usr/bin/python because system scripts will just shebang /usr/bin/python3 and nobody cares. Users almost certainly don't care as long as the script just keeps working, although if there are plugins, it will indirectly matter for them. Only the maintainers of those system scripts really care what the shebang is. For those system scripts, or other /usr/bin entries, that still require Python 2, I think they should already be shebanged /usr/bin/python2. OTOH, users have /usr/bin on their $PATH and they're just going to type 'python' so for them, it's ui, and it *does* matter. In that case I think /usr/bin/python should always point to /usr/bin/python2 which always points to the default Python 2 version (these days, for modern OS versions, almost always 2.7). I don't care how that pointing actually works. TL;DR: use #!/usr/bin/python3 for Python 3 system scripts, #!/usr/bin/python2 for Python 2 system scripts, and leave /usr/bin/python to invoke the default Python 2 version. The important word in the second point is, I think, *whenever*. Trying to apply these two points to Fedora 22 situation, I can think of several approaches: - /usr/bin/python will always point to python3 (seems to go against the first mentioned PEP recommendation) - /usr/bin/python will always point to python2 (seems to go against the second mentioned PEP recommendation, there is no /usr/bin/python if python2 is not installed) - /usr/bin/python will point to python3 if python2 is not installed, else it will point to python2 (inconsistent; also the user doesn't know he's running and what libraries he'll be able to import - the system can have different sets of python2-* and python3-* extension modules installed) - there will be no /usr/bin/python (goes against PEP and seems just wrong) I think the second point is right. If /usr/bin/python2 is not installed, neither should there be a /usr/bin/python. The reasoning is aligned with my views above. Python 2 won't go away, so even if it is not installed *by default* (and I hope we get there in both Debian and Ubuntu), it is entirely reasonable to assume it will eventually get installed. Someday a user is going to install a script that is Python 2, and then they'll get /usr/bin/python2 installed for that script's shebang. At that point, they'll *also* get /usr/bin/python which of course points to /usr/bin/python2. If the user wants to invoke Python 3, it's not hard to type 'python3' and I think that's the message we should be spreading. That already seems pretty ingrained in user habits afaict. If there's general agreement on that, we can work on improving the PEP's wording to make that policy more clear. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Sep 19, 2014, at 10:16 AM, Barry Warsaw ba...@python.org wrote: If the user wants to invoke Python 3, it's not hard to type 'python3' and I think that's the message we should be spreading. That already seems pretty ingrained in user habits afaict. My biggest problem with ``python3``, is what happens after 3.9. I know Guido doesn’t particularly like two digit version numbers and it’s been suggested on this list that instead of 3.10 we’re likely to move directly into 4.0 regardless of if it’s a “big” change or not. If that is the case, then all of the user education, ui, etc around ``python3`` would then need to be again updated to ``python4`` *OR* we’d need a ``python3`` bin which points to ``python4``. If there’s a call to action for at some point moving ``python`` to invoke Python 3.x at some point then hopefully at that point Python 4.x could just be ``python``. All of this assuming of course that 4.0 isn’t a major break like 3.0 and that we do 4.0 instead of 3.10 as has been suggested. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 3.5 release schedule PEP
Hi Larry, I think we need a Python 3.5 Release Schedule PEP. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Sep 19, 2014, at 10:23 AM, Donald Stufft wrote: My biggest problem with ``python3``, is what happens after 3.9. FWIW, 3.9 by my rough calculation is 7 years away. I know Guido doesn’t particularly like two digit version numbers and it’s been suggested on this list that instead of 3.10 we’re likely to move directly into 4.0 regardless of if it’s a “big” change or not. If that is the case, then all of the user education, ui, etc around ``python3`` would then need to be again updated to ``python4`` *OR* we’d need a ``python3`` bin which points to ``python4``. If there’s a call to action for at some point moving ``python`` to invoke Python 3.x at some point then hopefully at that point Python 4.x could just be ``python``. All of this assuming of course that 4.0 isn’t a major break like 3.0 and that we do 4.0 instead of 3.10 as has been suggested. I seem to recall Guido saying that *if* there's a 4.0, it won't be a major break like Python 3, whatever that says about the numbering scheme after 3.9. Is 7 years enough to eradicate Python 2 the way we did for Python 1? Then maybe Python 4 can reclaim /usr/bin/python. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Fri, Sep 19, 2014 at 10:41:58AM -0400, Barry Warsaw wrote: On Sep 19, 2014, at 10:23 AM, Donald Stufft wrote: My biggest problem with ``python3``, is what happens after 3.9. FWIW, 3.9 by my rough calculation is 7 years away. That makes it 2021, one year after Python 2.7 free support ends, but two years before Red Hat commercial support for it ends. I seem to recall Guido saying that *if* there's a 4.0, it won't be a major break like Python 3, whatever that says about the numbering scheme after 3.9. Is 7 years enough to eradicate Python 2 the way we did for Python 1? Then maybe Python 4 can reclaim /usr/bin/python. I expect not quite. Perhaps 10 years though. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Fri, 19 Sep 2014 10:16:20 -0400, Barry Warsaw ba...@python.org wrote: The way I look at it is that /usr/bin/python is user interface. Distributions are completely free to choose whichever Python they want for system scripts, and it's great to see that Fedora is well on their way to making Python 3 the default for system scripts. Debian is also making good progress, though we likely won't complete the transition until Jessie+1. Yep, user interface. Therefore I think the distribution should let the user choose :) Most users will chose python2, because that's what other scripts they might download and install will expect. So that should be the default. But I'll choose python3 (and have, on most of my gentoo linux systems, which supports having both quite well, for system installed packages). On the gripping hand, given what Fedora is doing, it is not that hard to change (or create) the symlinks as an end user to point to the python3 programs even if Fedora doesn't support it directly, so I don't see a problem with the proposed strategy. If the user wants to invoke Python 3, it's not hard to type 'python3' and I think that's the message we should be spreading. That already seems pretty ingrained in user habits afaict. As Donald pointed out, that presents a problem for the future. But since there is no good alternative to putting /usr/bin/python3 in the shebang of scripts that require python3, I don't think there is a solution and we're just going to have to cross that further bridge when we come to it. --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
python should always be the same as python2. On Fri, Sep 19, 2014 at 8:03 AM, Steven D'Aprano st...@pearwood.info wrote: On Fri, Sep 19, 2014 at 10:41:58AM -0400, Barry Warsaw wrote: On Sep 19, 2014, at 10:23 AM, Donald Stufft wrote: My biggest problem with ``python3``, is what happens after 3.9. FWIW, 3.9 by my rough calculation is 7 years away. That makes it 2021, one year after Python 2.7 free support ends, but two years before Red Hat commercial support for it ends. I seem to recall Guido saying that *if* there's a 4.0, it won't be a major break like Python 3, whatever that says about the numbering scheme after 3.9. Is 7 years enough to eradicate Python 2 the way we did for Python 1? Then maybe Python 4 can reclaim /usr/bin/python. I expect not quite. Perhaps 10 years though. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
Donald Stufft don...@stufft.io: My biggest problem with ``python3``, is what happens after 3.9. I know Guido doesn’t particularly like two digit version numbers and it’s been suggested on this list that instead of 3.10 we’re likely to move directly into 4.0 regardless of if it’s a “big” change or not. python3 should be the name of the programming language specification. If CPython-4.0 supports all of the python3 programming language, /usr/bin/python3 should be a symbolic link to CPython-4.0. Or, if I reimplemented python3 with cyphon0.7, python3 could be a link to that. If CPython-4.x dropped support for some python3 features, you would no longer link python3 to it. Now, what would plain python be? It would make life easier for a lot of people if it were python2 for all eternity. By analogy, look at #!/bin/sh, which used to invoke the Bourne shell, later /bin/bash and on modern Debian, /bin/dash. Marko ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Fri, 19 Sep 2014 08:20:48 -0700 Guido van Rossum gu...@python.org wrote: python should always be the same as python2. Always as in eternally? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Sep 19, 2014 8:36 AM, Antoine Pitrou solip...@pitrou.net wrote: On Fri, 19 Sep 2014 08:20:48 -0700 Guido van Rossum gu...@python.org wrote: python should always be the same as python2. Always as in eternally? Until I say so. Which will happen in the distant future. ___ Python-Dev mailing list Python-Dev@python.org 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 (2014-09-12 - 2014-09-19) 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: open4662 (+10) closed 29544 (+35) total 34206 (+45) Open issues with patches: 2197 Issues opened (33) == #22166: test_codecs leaks references http://bugs.python.org/issue22166 reopened by haypo #22395: test_pathlib error for complex symlinks on Windows http://bugs.python.org/issue22395 opened by jfoo #22396: AIX posix_fadvise and posix_fallocate http://bugs.python.org/issue22396 opened by David.Edelsohn #22397: test_socket failure on AIX http://bugs.python.org/issue22397 opened by David.Edelsohn #22401: argparse: 'resolve' conflict handler damages the actions of th http://bugs.python.org/issue22401 opened by paul.j3 #22406: uu-codec trailing garbage workaround is Python 2 code http://bugs.python.org/issue22406 opened by vadmium #22407: re.LOCALE is nonsensical for Unicode http://bugs.python.org/issue22407 opened by serhiy.storchaka #22408: Tkinter doesn't handle Unicode key events on Windows http://bugs.python.org/issue22408 opened by Drekin #22410: Locale dependent regexps on different locales http://bugs.python.org/issue22410 opened by serhiy.storchaka #22411: Embedding Python on Windows http://bugs.python.org/issue22411 opened by Joakim.Karlsson #22413: Bizarre StringIO(newline=\r\n) translation http://bugs.python.org/issue22413 opened by vadmium #22415: Fix re debugging output http://bugs.python.org/issue22415 opened by serhiy.storchaka #22417: PEP 476: verify HTTPS certificates by default http://bugs.python.org/issue22417 opened by ncoghlan #22418: ipaddress.py new IPv6 Method for Solicited Multicast Address http://bugs.python.org/issue22418 opened by Jason.Nadeau #22420: Use print(file=sys.stderr) instead of sys.stderr.write() in ID http://bugs.python.org/issue22420 opened by serhiy.storchaka #22422: IDLE closes all when in dropdown menu http://bugs.python.org/issue22422 opened by mandolout #22423: Errors in printing exceptions raised in a thread http://bugs.python.org/issue22423 opened by serhiy.storchaka #22425: 2to3 import fixer writes dotted_as_names into import_as_names http://bugs.python.org/issue22425 opened by simonmweber #22426: strptime accepts the wrong '2010-06-01 MSK' string but rejects http://bugs.python.org/issue22426 opened by akira #22427: TemporaryDirectory attempts to clean up twice http://bugs.python.org/issue22427 opened by oconnor663 #22428: asyncio: KeyboardInterrupt inside a coroutine causes Attribute http://bugs.python.org/issue22428 opened by oconnor663 #22429: asyncio: pending call to loop.stop() if a coroutine raises a B http://bugs.python.org/issue22429 opened by haypo #22430: Build failure if configure flags --prefix or --exec-prefix is http://bugs.python.org/issue22430 opened by diff.812 #22431: Change format of test runner output http://bugs.python.org/issue22431 opened by googol #22433: Argparse considers unknown optional arguments with spaces as a http://bugs.python.org/issue22433 opened by DenKoren #22434: Use named constants internally in the re module http://bugs.python.org/issue22434 opened by serhiy.storchaka #22435: socketserver.TCPSocket leaks socket to garbage collector if se http://bugs.python.org/issue22435 opened by vadmium #22437: re module: number of named groups is limited to 100 max http://bugs.python.org/issue22437 opened by yselivanov #22438: eventlet broke by python 2.7.x http://bugs.python.org/issue22438 opened by alex #22440: Setting SSLContext object's check_hostname manually might acci http://bugs.python.org/issue22440 opened by orsenthil #22441: Not all attributes of the console for a subprocess with creati http://bugs.python.org/issue22441 opened by Sworddragon #22442: subprocess.check_call hangs on large PIPEd data. http://bugs.python.org/issue22442 opened by juj #22443: read(1) blocks on unflushed output http://bugs.python.org/issue22443 opened by Sworddragon Most recent 15 issues with no replies (15) == #22441: Not all attributes of the console for a subprocess with creati http://bugs.python.org/issue22441 #22435: socketserver.TCPSocket leaks socket to garbage collector if se http://bugs.python.org/issue22435 #22429: asyncio: pending call to loop.stop() if a coroutine raises a B http://bugs.python.org/issue22429 #22425: 2to3 import fixer writes dotted_as_names into import_as_names http://bugs.python.org/issue22425 #22423: Errors in printing exceptions raised in a thread http://bugs.python.org/issue22423 #22422: IDLE closes all when in dropdown menu http://bugs.python.org/issue22422 #22411: Embedding Python on Windows http://bugs.python.org/issue22411 #22397: test_socket failure on AIX http://bugs.python.org/issue22397 #22394: Update documentation building to use venv and pip
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Sep 19, 2014, at 08:40 AM, Guido van Rossum wrote: Until I say so. Which will happen in the distant future. I'm gonna hid your time machine keys so you didn't find them. -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP476: Enabling certificate validation by default
Hi all, I've just updated the PEP to reflect the API suggestions from Nick, and the fact that the necessary changes to urllib were landed. I think this is ready for pronouncement, Guido? Cheers, Alex ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.5 release schedule PEP
Yep. I plan to write it on Monday, at the PyCon UK sprints, right after 3.4.2rc1 goes out. FWIW it'll be 3.4 + 18 months. //arry/ On 09/19/2014 03:31 PM, Barry Warsaw wrote: Hi Larry, I think we need a Python 3.5 Release Schedule PEP. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP476: Enabling certificate validation by default
The PEP doesn't specify any of the API changes for Python 2.7. I feel it is necessary for the PEP to show a few typical code snippets using urllib in Python 2.7 and how one would modify these in order to disable the cert checking. There are also a few typos; especially this paragraph puzzled me: This will be acheived by adding a new ``ssl._create_default_https_context`` function, which is the same as ``ssl.create_default``. ``http.client`` can then replace it's usage of ``ssl._create_stdlib_context`` with the new ``ssl._create_default_https_context``. (1) spelling: it's achieved, not achieved (2) method name: it's ssl.create_default_context, not ssl.create_default (3) There's not enough whitespace (in the rendered HTML on legacy.python.org) before http.client -- I kept reading it as ... which is the same as ssl.create_default.http.client ... (4) There's no mention of the Python 2 equivalent of http.client. Finally, it's kind of non-obvious in the PEP that this affects Python 2.7.X (I guess the one after the next) as well as 3.4 and 3.5. On Fri, Sep 19, 2014 at 9:53 AM, Alex Gaynor alex.gay...@gmail.com wrote: Hi all, I've just updated the PEP to reflect the API suggestions from Nick, and the fact that the necessary changes to urllib were landed. I think this is ready for pronouncement, Guido? Cheers, Alex ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP476: Enabling certificate validation by default
Pushed a new version which I believe adresses all of these. I added an example of opting-out with urllib.urlopen, let me know if there's any other APIs you think I should show an example with. On Fri, Sep 19, 2014 at 3:06 PM, Guido van Rossum gu...@python.org wrote: The PEP doesn't specify any of the API changes for Python 2.7. I feel it is necessary for the PEP to show a few typical code snippets using urllib in Python 2.7 and how one would modify these in order to disable the cert checking. There are also a few typos; especially this paragraph puzzled me: This will be acheived by adding a new ``ssl._create_default_https_context`` function, which is the same as ``ssl.create_default``. ``http.client`` can then replace it's usage of ``ssl._create_stdlib_context`` with the new ``ssl._create_default_https_context``. (1) spelling: it's achieved, not achieved (2) method name: it's ssl.create_default_context, not ssl.create_default (3) There's not enough whitespace (in the rendered HTML on legacy.python.org) before http.client -- I kept reading it as ... which is the same as ssl.create_default.http.client ... (4) There's no mention of the Python 2 equivalent of http.client. Finally, it's kind of non-obvious in the PEP that this affects Python 2.7.X (I guess the one after the next) as well as 3.4 and 3.5. On Fri, Sep 19, 2014 at 9:53 AM, Alex Gaynor alex.gay...@gmail.com wrote: Hi all, I've just updated the PEP to reflect the API suggestions from Nick, and the fact that the necessary changes to urllib were landed. I think this is ready for pronouncement, Guido? Cheers, Alex ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On 20 September 2014 00:23, Donald Stufft don...@stufft.io wrote: On Sep 19, 2014, at 10:16 AM, Barry Warsaw ba...@python.org wrote: If the user wants to invoke Python 3, it's not hard to type 'python3' and I think that's the message we should be spreading. That already seems pretty ingrained in user habits afaict. My biggest problem with ``python3``, is what happens after 3.9. I know Guido doesn’t particularly like two digit version numbers and it’s been suggested on this list that instead of 3.10 we’re likely to move directly into 4.0 regardless of if it’s a “big” change or not. FWIW, I think we actually do this better on Windows these days, where PEP 397 made py a switchable entry point. I'd like to bring the same scheme to POSIX systems at some point, but that's a *long* way down the todo list (like, so far down I can't even see it any more). I'd be willing to review proposals, though :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP476: Enabling certificate validation by default
On 20 September 2014 08:34, Alex Gaynor alex.gay...@gmail.com wrote: Pushed a new version which I believe adresses all of these. I added an example of opting-out with urllib.urlopen, let me know if there's any other APIs you think I should show an example with. It would be worth explicitly stating the process global monkeypatching hack: import ssl ssl._create_default_https_context = ssl._create_unverified_context Adding that hack to sitecustomize allows corporate sysadmins that can update their standard operating environment more easily than they can fix invalid certificate infrastructure to work around the problem on behalf of their users. It also helps out users that will be able to deal with such broken infrastructure without updating each and every one of their scripts. It's deliberately ugly because it's a genuinely bad idea that folks should want to avoid using, but as a matter of practical reality, corporate IT departments are chronically understaffed, and often fully committed to fighting the crisis du jour, without sufficient time being available for regular infrastructure maintenance tasks. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP476: Enabling certificate validation by default
+1 on Nick's suggestion. (Might also mention that this is the reason why both functions should exist and have compatible signatures.) Also please, please, please add explicit mention of Python 2.7, 3.4 and 3.5 in the Abstract (for example in the 3rd paragraph of the abstract). On Fri, Sep 19, 2014 at 3:52 PM, Nick Coghlan ncogh...@gmail.com wrote: On 20 September 2014 08:34, Alex Gaynor alex.gay...@gmail.com wrote: Pushed a new version which I believe adresses all of these. I added an example of opting-out with urllib.urlopen, let me know if there's any other APIs you think I should show an example with. It would be worth explicitly stating the process global monkeypatching hack: import ssl ssl._create_default_https_context = ssl._create_unverified_context Adding that hack to sitecustomize allows corporate sysadmins that can update their standard operating environment more easily than they can fix invalid certificate infrastructure to work around the problem on behalf of their users. It also helps out users that will be able to deal with such broken infrastructure without updating each and every one of their scripts. It's deliberately ugly because it's a genuinely bad idea that folks should want to avoid using, but as a matter of practical reality, corporate IT departments are chronically understaffed, and often fully committed to fighting the crisis du jour, without sufficient time being available for regular infrastructure maintenance tasks. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
Donald Stufft wrote: My biggest problem with ``python3``, is what happens after 3.9. Python2 technically includes 1.x versions as well, so it wouldn't be unprecedented for python3 to imply versions beyond 3.x. It would be a bit confusing, though. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
On Sep 19, 2014, at 8:02 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Donald Stufft wrote: My biggest problem with ``python3``, is what happens after 3.9. Python2 technically includes 1.x versions as well, so it wouldn't be unprecedented for python3 to imply versions beyond 3.x. It would be a bit confusing, though. My problem isn’t that it *includes* it, it’s that either people have to go through the mess to update all of their things to ``python4`` at some point in the future, or Python 3.x will need to eventually mean ``python``. Well that or Python 4.x has a ``python3`` binary. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 - Clarification of what python command should invoke
Barry Warsaw wrote: On Sep 19, 2014, at 08:40 AM, Guido van Rossum wrote: Until I say so. Which will happen in the distant future. I'm gonna hid your time machine keys so you didn't find them. Hiding someone's time machine keys never works. Chances are he's already taken a trip to the future in which you get kidnapped and tortured until you reveal where you hid them, and then nipped over there to take them back. Which means he *might* be able to avoid carrying out the actual torture now, as long as it doesn't create too big a temporal paradox. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
