[Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
PEP 394 [1] aims to document our collective recommendation for allowing shebang lines to specifically request some version of 2.x, without requiring that it be exactly 2.7 (or 2.6, etc). I'd let this drift for a while, but the imminent release of 2.7.3 makes it necessary to push for a final pronouncement. Kerrick has the necessary Makefile.pre.in patch up on the tracker [2] to add the hard link for the python2 name. We could, of course, make the recommendation to distributions without updating make install and make bininstall to follow our own advice, but that seems needlessly inconsistent. [1] http://www.python.org/dev/peps/pep-0394/ [2] http://bugs.python.org/issue12627 Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
On Sun, 12 Feb 2012 19:04:30 +1000 Nick Coghlan ncogh...@gmail.com wrote: PEP 394 [1] aims to document our collective recommendation for allowing shebang lines to specifically request some version of 2.x, without requiring that it be exactly 2.7 (or 2.6, etc). I'd let this drift for a while, but the imminent release of 2.7.3 makes it necessary to push for a final pronouncement. Kerrick has the necessary Makefile.pre.in patch up on the tracker [2] to add the hard link for the python2 name. Why hard links? Symlinks are much more introspectable. When looking at a hard link I have no easy way to know it's the same as whatever other file in the same directory. I also don't understand this mention: “The make install command in the CPython 3.x series will similarly install the python3.x, idle3.x, pydoc3.x, and python3.x-config binaries (with appropriate x), and python3, idle3, pydoc3, and python3-config as hard links. This feature will first appear in CPython 3.3.” This feature actually exists in 3.2 (but with a symlink, fortunately): $ ls -la ~/opt/bin/pydoc3 lrwxrwxrwx 1 antoine antoine 8 oct. 15 21:24 /home/antoine/opt/bin/pydoc3 - pydoc3.2* Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
Why hard links? Symlinks are much more introspectable. When looking at a hard link I have no easy way to know it's the same as whatever other file in the same directory. There actually *is* an easy way, in regular ls: look at the link count. It comes out of ls -l by default, and if it's 1, there will be an identical file. I agree with the question, though: this needs to be justified (but there may well be a justification). I also don't understand this mention: “The make install command in the CPython 3.x series will similarly install the python3.x, idle3.x, pydoc3.x, and python3.x-config binaries (with appropriate x), and python3, idle3, pydoc3, and python3-config as hard links. This feature will first appear in CPython 3.3.” This feature actually exists in 3.2 (but with a symlink, fortunately): If you look at the patch, you'll notice that the only change is to make the links hard links. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
Le dimanche 12 février 2012 à 16:52 +0100, Martin v. Löwis a écrit : Why hard links? Symlinks are much more introspectable. When looking at a hard link I have no easy way to know it's the same as whatever other file in the same directory. There actually *is* an easy way, in regular ls: look at the link count. It comes out of ls -l by default, and if it's 1, there will be an identical file. This doesn't tell me which file it is, which is practically useless if I have both python3.3 and python3.2 in that directory. If you look at the patch, you'll notice that the only change is to make the links hard links. This begs the question: why? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
In article CADiSq7cfuZ=22zcGkvcT4TH+GjjTaHHAh9XK6jUBwZv=alu...@mail.gmail.com, Nick Coghlan ncogh...@gmail.com wrote: PEP 394 [1] aims to document our collective recommendation for allowing shebang lines to specifically request some version of 2.x, without requiring that it be exactly 2.7 (or 2.6, etc). I'd let this drift for a while, but the imminent release of 2.7.3 makes it necessary to push for a final pronouncement. Kerrick has the necessary Makefile.pre.in patch up on the tracker [2] to add the hard link for the python2 name. We could, of course, make the recommendation to distributions without updating make install and make bininstall to follow our own advice, but that seems needlessly inconsistent. BTW, the patch is not sufficient to do all the right things for OS X intstaller builds, so, if you are thinking of approving this for 2.7.3, I'll need a few hours to develop and test the patch for that prior to code freeze, once there is agreement what it should do. Is there any work needed on the Windows installer side? -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
There actually *is* an easy way, in regular ls: look at the link count. It comes out of ls -l by default, and if it's 1, there will be an identical file. This doesn't tell me which file it is, which is practically useless if I have both python3.3 and python3.2 in that directory. You can use 'ls -i' to print the inode, or you could use find's 'samefile' option. But this is definitely not as straightforward as a it would be for a symlink, and I'm also curious to know the reason behind this choice. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
Am 12.02.2012 17:04, schrieb Antoine Pitrou: Le dimanche 12 février 2012 à 16:52 +0100, Martin v. Löwis a écrit : Why hard links? Symlinks are much more introspectable. When looking at a hard link I have no easy way to know it's the same as whatever other file in the same directory. There actually *is* an easy way, in regular ls: look at the link count. It comes out of ls -l by default, and if it's 1, there will be an identical file. This doesn't tell me which file it is Well, you didn't ask for that, it does to know it's the same as whatever other file nicely :-) As Charles-François explains, you can use ls -i for that, which isn't that easy, but still straight-forward. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding a maximum element count to parse_qs?
Hello, Given the randomization fix will ship disabled, I thought it would be nice to add a maximum element count argument to urlparse.parse_qs, with a default value of e.g. 1000 (including in bugfix releases). What do you think? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
On 12Feb2012 18:57, Martin v. Löwis mar...@v.loewis.de wrote: | Am 12.02.2012 17:04, schrieb Antoine Pitrou: | Le dimanche 12 février 2012 à 16:52 +0100, Martin v. Löwis a écrit : | Why hard links? Symlinks are much more introspectable. When looking at | a hard link I have no easy way to know it's the same as whatever other | file in the same directory. | | There actually *is* an easy way, in regular ls: look at the link count. | It comes out of ls -l by default, and if it's 1, there will be an | identical file. Yeah! Somewhere... :-( | This doesn't tell me which file it is | | Well, you didn't ask for that, it does to know it's the same as | whatever other file nicely :-) Sure, at the OS level. Not much use for _inspection_. | As Charles-François explains, you can use ls -i for that, which isn't | that easy, but still straight-forward. If the hardlink is nearby. Of course in this example it (almost certainly?) is, but it needn't be. A symlink is a much better solution to this problem because: - usability - ls -l shows it to the user by default - practicality: With a symlink, to find out what it attaches to you examine the symlink. With a hardlink you first examine a fairly opaque numeric attribute of python2, and _then_ you examine every other filename on the system! Admittedly starting with python2.* in the same directory, but in principle in other places. Arbitrary other places. IMO a symlink is far and away the better choice in this situation. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ I need your clothes, your boots, and your motorcycle. - Arnold Schwarzenegger, Terminator 2 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
IMO a symlink is far and away the better choice in this situation. Please wait with that judgment until you see the rationale of the PEP author. Thanks, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
Given the randomization fix will ship disabled, I thought it would be nice to add a maximum element count argument to urlparse.parse_qs, with a default value of e.g. 1000 (including in bugfix releases). What do you think? It's an API change, so it is a) in violation with current practice for bug fix releases, and b) of limited use for existing installations which won't use the API. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
On Sun, 12 Feb 2012 21:44:22 +0100 Martin v. Löwis mar...@v.loewis.de wrote: Given the randomization fix will ship disabled, I thought it would be nice to add a maximum element count argument to urlparse.parse_qs, with a default value of e.g. 1000 (including in bugfix releases). What do you think? It's an API change, so it is a) in violation with current practice for bug fix releases, and We are already violating a lot of things in order to fix this issue. b) of limited use for existing installations which won't use the API. Obviously it won't fix vulnerabilities due to some other API. If you propose other APIs we can also fix them. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
On Sun, Feb 5, 2012 at 11:23 AM, Ned Deily n...@acm.org wrote: In article e1ru7g3-0007mb...@dinsdale.python.org, georg.brandl python-check...@python.org wrote: +Bugfix Releases +=== + +- 3.2.1: released July 10, 2011 +- 3.2.2: released September 4, 2011 + +- 3.2.3: planned February 10-17, 2012 I would like to propose that we plan for 3.2.3 and 2.7.3 immediately after PyCon, so approximately March 17, if that works for all involved. I also like this idea because we tend to get a lot of bug fixing done during the PyCon sprints. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
It's an API change, so it is a) in violation with current practice for bug fix releases, and We are already violating a lot of things in order to fix this issue. Not really. There isn't any significant API change in the proposed patch (the ones that are there are safe to ignore in applications). There is, of course, a major behavior change, but that is deliberately opt-in. b) of limited use for existing installations which won't use the API. Obviously it won't fix vulnerabilities due to some other API. If you propose other APIs we can also fix them. No, you are missing my point. I assume you proposed (even though you didn't say so explicitly) that parse_qs gets an opt-in API change to limit the number of parameters. If that is added, it will have no effect on any existing applications, as they will all currently not pass that parameter. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
On Mon, 13 Feb 2012 00:08:45 +0100 mar...@v.loewis.de wrote: b) of limited use for existing installations which won't use the API. Obviously it won't fix vulnerabilities due to some other API. If you propose other APIs we can also fix them. No, you are missing my point. I assume you proposed (even though you didn't say so explicitly) that parse_qs gets an opt-in API change to limit the number of parameters. If that is added, it will have no effect on any existing applications, as they will all currently not pass that parameter. No, I said it would include a default value of (say) 1000 parameters. That default value would be applied to anyone doesn't use the new API. (the reason I'm proposing a new API is to allow people to change or disable the limit, in case they really want to pass a large number of parameters) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
No, you are missing my point. I assume you proposed (even though you didn't say so explicitly) that parse_qs gets an opt-in API change to limit the number of parameters. If that is added, it will have no effect on any existing applications, as they will all currently not pass that parameter. No, I said it would include a default value of (say) 1000 parameters. That default value would be applied to anyone doesn't use the new API. (the reason I'm proposing a new API is to allow people to change or disable the limit, in case they really want to pass a large number of parameters) I see. -1 on that proposal, then: there are certainly applications that will break with that. I don't find 1000 POST parameters a lot, and I'm sure that people use that in a programmatic fashion (e.g. to mass-upload stuff). If you really think that kind of change is necessary, develop a separate patch that people who are worried can apply. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding a maximum element count to parse_qs?
On Mon, 13 Feb 2012 00:32:07 +0100 mar...@v.loewis.de wrote: No, you are missing my point. I assume you proposed (even though you didn't say so explicitly) that parse_qs gets an opt-in API change to limit the number of parameters. If that is added, it will have no effect on any existing applications, as they will all currently not pass that parameter. No, I said it would include a default value of (say) 1000 parameters. That default value would be applied to anyone doesn't use the new API. (the reason I'm proposing a new API is to allow people to change or disable the limit, in case they really want to pass a large number of parameters) I see. -1 on that proposal, then: there are certainly applications that will break with that. I don't find 1000 POST parameters a lot, and I'm sure that people use that in a programmatic fashion (e.g. to mass-upload stuff). If you really think that kind of change is necessary, develop a separate patch that people who are worried can apply. Fair enough. Actually, people can simply call parse_qsl and check the len() of the returned list before stuffing the params into a dict. That said, we can still do the change (without any limiting default value) for 3.3. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Hi, I finished the implementation of the PEP 410 (Use decimal.Decimal type for timestamps). The PEP: http://www.python.org/dev/peps/pep-0410/ The implementation: http://bugs.python.org/issue13882 Rietveld code review tool for this issue: http://bugs.python.org/review/13882/show The patch is huge because it changes many modules, but I plan to split the patch into small commits. I'm still waiting for Nick Coghlan and Guido van Rossum for their decision on the PEP. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)
On Mon, Feb 13, 2012 at 6:42 AM, Martin v. Löwis mar...@v.loewis.de wrote: IMO a symlink is far and away the better choice in this situation. Please wait with that judgment until you see the rationale of the PEP author. Kerrick did post a rationale in the last thread [1], but it never made it into the PEP itself. The relevant comment: == Also, I updated the PEP with the clarification that commands like python3 should be hard links (because they'll be invoked from code and are more efficient; also, hard links are just as flexible as symlinks here), while commands like python should be soft links (because this makes it clear to sysadmins that they can be switched, and it's needed for flexibility if python3 changes). This really doesn't matter, but can we keep it this way unless there are serious objections? == I think Antoine makes a good point about ease of introspection when you have multiple versions in the same series installed, so I'd be fine with: - updating the PEP recommendation to say that either form of link is fine (with hard links marginally faster, but harder to introspect) - noting that python.org releases will consistently use symlinks for easier introspection via ls -l - updating Makefile.pre.in to ensure that we really do consistently use symlinks This does mean that launching Python may involve a slightly longer symlink chain in some cases (python - python2 - python2.7), but the impact of that is always going to be utterly dwarfed by other startup costs. [1] http://mail.python.org/pipermail/python-dev/2011-July/112322.html Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
On Mon, Feb 13, 2012 at 10:28 AM, Victor Stinner victor.stin...@gmail.com wrote: Hi, I finished the implementation of the PEP 410 (Use decimal.Decimal type for timestamps). The PEP: http://www.python.org/dev/peps/pep-0410/ The implementation: http://bugs.python.org/issue13882 Rietveld code review tool for this issue: http://bugs.python.org/review/13882/show The patch is huge because it changes many modules, but I plan to split the patch into small commits. I'm still waiting for Nick Coghlan and Guido van Rossum for their decision on the PEP. Only Guido, really. I'm already on record as being happy with the API design as documented in the latest version of the PEP. (I haven't reviewed the full patch yet, but that's the next step before checking things in, it isn't needed to mark the PEP as Accepted). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] http://pythonmentors.com/
Eli Bendersky writes: Well, I think the situation is pretty good now. I agree, but improvement is always possible. If one goes to python.org and is interested in contributing, clicking on the Core Development link is a sensible step, right? Maybe. But a lot of the Core Dev links I've seen are maintained by and for incumbent core devs, and are somewhat intimidating for new users and developers. How about moving the About | Getting Started link to the top level and giving it a set of links like - Standalone Scripting - Extending Apps Using Python as Extension Language - Developing Apps in Python (this is what I think of when I read the current Getting Started with Python page, FWIW YMMV) - Developing Library Modules to Extend Python - Developing Python (there's work you can do, too!) This is similar to the existing About | Getting Started page, but more accessible (in the sense of being an index, rather than a more verbose description containing scattered links). I think most of them can go to existing pages. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 411: Provisional packages in the Python standard library
Antoine Pitrou writes: I think the word provisional doesn't mean anything to many (non-native English speaking) people. I would like to suggest something clearer, e.g. experimental or unstable - which have the benefit of *already* having a meaning in other software-related contexts. I sympathize, but unfortunately, as Nick points out, those words have *different* and *inappropriate* meanings, which will definately mislead and confuse native speakers. Nor is provisional a difficult concept, as I understand it. At the very least, it has an exact translation into Japanese, which makes it about as hard to find exact translations as I can imagine a human language could! The X package has been included in the standard library on a provisional basis. While major changes are not anticipated, as long as this notice remains in place, backwards incompatible changes are permitted if deemed necessary by the standard library developers. Such changes will not be made gratuitously - they will occur only if serious API flaws are uncovered that were missed prior to inclusion of the package. That's too wordy. Let's stay clear and to the point: This package is unstable/experimental. Its API may change in the next release. (and put a link to the relevant FAQ section if necessary) How about this? This is a `provisional package`__. Its API may change in the next release. __ faq#provisional_package and the linked FAQ will also link to the full PEP and a dictionary definition. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
