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 pronou
On Sun, 12 Feb 2012 19:04:30 +1000
Nick Coghlan 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 immi
> 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 regul
In article
,
Nick Coghlan 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.
>> 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.
Yo
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.
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" 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
> 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/p
> 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
On Sun, 12 Feb 2012 21:44:22 +0100
"Martin v. Löwis" 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?
On Sun, Feb 5, 2012 at 11:23 AM, Ned Deily wrote:
> In article ,
> georg.brandl 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
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
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 a
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,
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
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 h
On Mon, Feb 13, 2012 at 6:42 AM, "Martin v. Löwis" 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 PE
On Mon, Feb 13, 2012 at 10:28 AM, Victor Stinner
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 too
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
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 contex
22 matches
Mail list logo
