On 24 June 2013 13:37, Raymond Hettinger wrote:
> But it isn't worth all the second guessing (and what feels like sniping).
> I've worked on this code for almost a decade. As far as I can tell, none
> of the participants in this thread has ever previously shown any interest
> in the deque object.
2013/6/23 Alexander Belopolsky :
>
> On Sun, Jun 23, 2013 at 11:37 PM, Raymond Hettinger
> wrote:
>>
>> As far as I can tell, none
>> of the participants in this thread has ever previously shown any interest
>> in the deque object. It is discouraging to have a simple parameter
>> change and struc
Your work is great! I even agree with the changes on a coding best
practices level.
It's just that it belongs on the default (3.4) branch as it is an
enhancement, not a bug fix.
We don't do new things on release branches.
I agree that can be extremely frustrating at times, knowing that code won'
On Sun, Jun 23, 2013 at 11:37 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> As far as I can tell, none
> of the participants in this thread has ever previously shown any interest
> in the deque object. It is discouraging to have a simple parameter
> change and struct reordering re
On Jun 23, 2013, at 6:52 PM, Scott Dial wrote:
> Nowadays, cache lines are still 64 bytes but pointers are 8 bytes, and
> we still allocating on 16 byte alignment, so you have a 25% chance of a
> cache miss now.
Honestly, I'm not sure what you're arguing for or against.
The struct should to be
On 6/23/2013 8:16 PM, Raymond Hettinger wrote:
> Yes, this is a micro-optimization. In working on implementing
> deque slicing for 3.4, I restudied the block access patterns.
> On an appendleft(), popleft() or extendleft() operation, the left link is
> accessed immediately before or after the l
On Jun 18, 2013, at 12:00 AM, Gregory P. Smith wrote:
> Why did you do this in the 2.7 branch?
>
> It hasn't been done in 3.3 or default
I worked on the 2.7 branch first because that was the one I had loaded
and the one where I did timings and code disassembly. I intended to
post it to 3.3 an
On 23 cze 2013, at 21:07, Antoine Pitrou wrote:
> The most annoying thing here is that OverflowError doesn't subclass
> ValueError.
My intuition would rather make OverflowError subclass RuntimeError. Am I wrong?
That means I support Serhiy's point that %c would be less surprising raising a
Va
On Sun, 23 Jun 2013 21:59:37 +0300
Serhiy Storchaka wrote:
> Currently %c formatting raises OverflowError if an argument is out of range.
>
> >>> '%c' % 1114112
> Traceback (most recent call last):
>File "", line 1, in
> OverflowError: %c arg not in range(0x11)
> >>> '{:c}'.format(1114
Currently %c formatting raises OverflowError if an argument is out of range.
>>> '%c' % 1114112
Traceback (most recent call last):
File "", line 1, in
OverflowError: %c arg not in range(0x11)
>>> '{:c}'.format(1114112)
Traceback (most recent call last):
File "", line 1, in
OverflowError
I've backed this one out, too.
2013/6/22 Scott Dial :
> On 6/22/2013 2:17 PM, Benjamin Peterson wrote:
>> Many people have raised concerns about this change, so I've now backed it
>> out.
>
> I think that change also goes with this change:
>
> http://hg.python.org/cpython/rev/f1dc30a1be72
>
> cha
On Sun, 23 Jun 2013 17:40:13 +0200, Maciej Fijalkowski wrote:
> On Thu, Jun 20, 2013 at 3:36 PM, Brett Cannon wrote:
> > On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran
> > wrote:
> >> .TP
> >> +.BI "\-X " option
> >> +Set implementation specific option.
> >
> >
> > Should probably be "Set th
On Thu, Jun 20, 2013 at 3:36 PM, Brett Cannon wrote:
>
>
>
> On Wed, Jun 19, 2013 at 11:20 PM, senthil.kumaran
> wrote:
>>
>> http://hg.python.org/cpython/rev/dfead0696a71
>> changeset: 84224:dfead0696a71
>> branch: 3.3
>> parent: 84221:0113247f894b
>> user:Senthil Kumaran
>>
Hi,
2013/6/21 Antoine Pitrou :
> I've been appointed PEP 445 delegate by Nick and Guido. I would like to
> know if there are still pending changes to the PEP. If not, I expect to
> give it a review in the coming days or weeks, and then make a final
> pronouncement (which will probably be positive
14 matches
Mail list logo
