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
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
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,
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:
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
22 matches
Mail list logo
