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
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
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
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
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, 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
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: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
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 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
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?
> 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
> 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
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
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.
__
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, which is practically useless if I
> have both python3.3 and python3.2 in that directory.
Yo
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.
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
> 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,
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
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
22 matches
Mail list logo
