On 15.11.13 00:02, Greg Ewing wrote:
Walter Dörwald wrote:
Unfortunaty the frame from the decorator shows up in the traceback.
Maybe the decorator could remove its own frame from
the traceback?
True, this could be done via either an additional attribute on the
frame, or a special value for
On 19 November 2013 22:24, Walter Dörwald wrote:
> On 15.11.13 00:02, Greg Ewing wrote:
>
>> Walter Dörwald wrote:
>>>
>>> Unfortunaty the frame from the decorator shows up in the traceback.
>>
>>
>> Maybe the decorator could remove its own frame from
>> the traceback?
>
>
> True, this could be do
On Sun, Nov 17, 2013 at 6:20 AM, Brett Cannon wrote:
>
> On Nov 17, 2013 8:58 AM, "Eli Bendersky" wrote:
> >
> >
> >
> >
> > On Sat, Nov 16, 2013 at 3:44 PM, Brett Cannon wrote:
> >>
> >>
> >>
> >>
> >> On Sat, Nov 16, 2013 at 1:40 PM, Eric Snow
> wrote:
> >>>
> >>> If you look at the Python a
Food for thought: maybe we should have variable-encoding lengths for
all opcodes, rather than the current cumbersome scheme?
Funny, it sounds like UTF-8 :-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/
Food for thought: maybe we should have variable-encoding lengths for
all opcodes, rather than the current cumbersome scheme?
Funny, it sounds like UTF-8 :-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
On Mon, 18 Nov 2013 16:48:05 -0800
Guido van Rossum wrote:
>
> Food for thought: maybe we should have variable-encoding lengths for all
> opcodes, rather than the current cumbersome scheme?
Well, it's not that cumbersome... If you look at CPU encodings, they
also tend to have different opcodes f
So why is framing different?
On Tue, Nov 19, 2013 at 10:51 AM, Antoine Pitrou wrote:
> On Mon, 18 Nov 2013 16:48:05 -0800
> Guido van Rossum wrote:
> >
> > Food for thought: maybe we should have variable-encoding lengths for all
> > opcodes, rather than the current cumbersome scheme?
>
> Well,
On Tue, 19 Nov 2013 19:51:10 +0100
Antoine Pitrou wrote:
> On Mon, 18 Nov 2013 16:48:05 -0800
> Guido van Rossum wrote:
> >
> > Food for thought: maybe we should have variable-encoding lengths for all
> > opcodes, rather than the current cumbersome scheme?
>
> Well, it's not that cumbersome...
On Tue, 19 Nov 2013 10:52:58 -0800
Guido van Rossum wrote:
> So why is framing different?
Because it doesn't use opcodes, so it can't use different opcodes to
differentiate between different frame size widths :-)
Regards
Antoine.
___
Python-Dev mailin
So using an opcode for framing is out? (Sorry, I've lost track of the
back-and-forth.)
On Tue, Nov 19, 2013 at 10:57 AM, Antoine Pitrou wrote:
> On Tue, 19 Nov 2013 10:52:58 -0800
> Guido van Rossum wrote:
> > So why is framing different?
>
> Because it doesn't use opcodes, so it can't use diff
On Tue, 19 Nov 2013 11:05:45 -0800
Guido van Rossum wrote:
> So using an opcode for framing is out? (Sorry, I've lost track of the
> back-and-forth.)
It doesn't seem to bring anything, and it makes the overhead worse for
tiny pickles (since it will be two bytes at least, instead of one byte
with
Well, both fixed 8-byte framing and variable-size framing it introduces a
new way of representing numbers in the stream, which means that everyone
parsing and generating pickles must be able to support both styles. (But
fixed is easier since the XXX8 opcodes use the same format.)
I'm thinking of h
[Guido]
> So using an opcode for framing is out? (Sorry, I've lost track of the
> back-and-forth.)
It was never in ;-) I'd *prefer* one, but not enough to try to block
the PEP. As is, framing is done at a "lower level" than opcode
decoding. I fear this is brittle, for all the usual "explicit is
Am 19.11.2013 17:14, schrieb Mark Lawrence:
> On 19/11/2013 06:59, Georg Brandl wrote:
>>
>> To download Python 3.3.3 rc2 visit:
>>
>> http://www.python.org/download/releases/3.3.3/
>>
>
> Please make your mind up, final or rc2?
>
> Thanks everybody for your efforts, much appreciated :)
It'
On Tue, 19 Nov 2013 13:22:52 -0600
Tim Peters wrote:
> [Guido]
> > So using an opcode for framing is out? (Sorry, I've lost track of the
> > back-and-forth.)
>
> It was never in ;-) I'd *prefer* one, but not enough to try to block
> the PEP. As is, framing is done at a "lower level" than opcode
Am 19.11.13 20:59, schrieb Antoine Pitrou:
> That's integrated to the built-in buffering. It's not really an
> additional constraint: the frame sizes simply dictate how buffering
> happens in practice. The main point of framing is to *simplify* the
> buffering logic (of course, the old buffering lo
On Tue, 19 Nov 2013 21:25:34 +0100
"Martin v. Löwis" wrote:
> Am 19.11.13 20:59, schrieb Antoine Pitrou:
> > That's integrated to the built-in buffering. It's not really an
> > additional constraint: the frame sizes simply dictate how buffering
> > happens in practice. The main point of framing is
19.11.13 21:59, Antoine Pitrou написав(ла):
Note some drawbacks of frame opcodes:
- the decoder has to sanity check the frame opcodes (what if a frame
opcode is encountered when already inside a frame?)
This is only one simple check when reading the frame opcode.
- a pickle-mutating functi
Hello,
Guido has told me that he was ready to approve PEP 428 (pathlib) in its
latest amended form. Here is the last call for any comments or
arguments against approval, before Guido marks the PEP accepted (or
changes his mind :-)).
Regards
Antoine.
__
[Tim]
>> ...
>> better than implicit" kinds of reasons. The only way now to know that
>> you're looking at a frame size is to keep a running count of bytes
>> processed and realize you've reached a byte offset where a frame size
>> "is expected".
[Antoine]
> That's integrated to the built-in buff
On Tue, 19 Nov 2013 15:17:06 -0600
Tim Peters wrote:
>
> > Note some drawbacks of frame opcodes:
> > - the decoder has to sanity check the frame opcodes (what if a frame
> > opcode is encountered when already inside a frame?)
> > - a pickle-mutating function such as pickletools.optimize() may n
[Tim]
>> ...
>> But if some _other_ implementation of unpickling didn't give a hoot
>> about framing, having an explicit opcode means that implementation
>> could ignore the whole scheme very easily: just implement the FRAME
>> opcode in *its* opcode-decoding loop to consume the FRAME argument,
>>
On Tue, 19 Nov 2013 15:41:51 -0600
Tim Peters wrote:
> [Tim]
> >> ...
> >> But if some _other_ implementation of unpickling didn't give a hoot
> >> about framing, having an explicit opcode means that implementation
> >> could ignore the whole scheme very easily: just implement the FRAME
> >> opco
On Tue, Nov 19, 2013 at 4:04 PM, Antoine Pitrou wrote:
>
> Hello,
>
> Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> latest amended form. Here is the last call for any comments or
> arguments against approval, before Guido marks the PEP accepted (or
> changes his mind
[Antoine]
>>> Ahah, ok, I see where you're going. But how many other implementations
>>> of unpickling are there?
[Tim]
>> That's something you should have researched when writing the PEP ;-)
>> How many implementations of Python aren't CPython? That's probably
>> the answer. I'm not an expert o
On Tue, 19 Nov 2013 17:02:15 -0500
Brett Cannon wrote:
> On Tue, Nov 19, 2013 at 4:04 PM, Antoine Pitrou wrote:
>
> >
> > Hello,
> >
> > Guido has told me that he was ready to approve PEP 428 (pathlib) in its
> > latest amended form. Here is the last call for any comments or
> > arguments again
On Tue, 19 Nov 2013 16:06:22 -0600
Tim Peters wrote:
> [Antoine]
> >>> Ahah, ok, I see where you're going. But how many other implementations
> >>> of unpickling are there?
>
> [Tim]
> >> That's something you should have researched when writing the PEP ;-)
> >> How many implementations of Python
Am 19.11.13 21:28, schrieb Antoine Pitrou:
> Well, unless you propose a patch before Saturday, I will happily ignore
> your proposal.
See
http://bugs.python.org/file32709/framing.diff
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, 19 Nov 2013 23:05:07 +0100
"Martin v. Löwis" wrote:
> Am 19.11.13 21:28, schrieb Antoine Pitrou:
>
> > Well, unless you propose a patch before Saturday, I will happily ignore
> > your proposal.
>
> See
>
> http://bugs.python.org/file32709/framing.diff
Ok, thanks. So now that I look at
Am 19.11.13 23:50, schrieb Antoine Pitrou:
> Ok, thanks. So now that I look at the patch I see the following problems
> with this idea:
>
> - "pickle + framing" becomes a different protocol than "pickle" alone,
> which means we lose the benefit of protocol autodetection. It's as
> though pickl
2013/11/11 Charles-François Natali :
> After several exchanges with Victor, PEP 454 has reached a status
> which I consider ready for pronuncement [1]: so if you have any last
> minute comment, now is the time!
So, what's going on? The deadline is Saturday, in 5 days.
If the PEP is accepted (I ho
On Wed, 20 Nov 2013 00:56:13 +0100
"Martin v. Löwis" wrote:
> AFAICT, the real driving force is the desire to not read-ahead
> more than the pickle is long. This is what complicates the code.
> The easiest (and most space-efficient) solution to that problem
> would be to prefix the entire pickle w
I'm guessing CF is the PEP-BDFL? So he should approve it (the period for
final comments is long over) and then you can merge.
On Tue, Nov 19, 2013 at 4:09 PM, Victor Stinner wrote:
> 2013/11/11 Charles-François Natali :
> > After several exchanges with Victor, PEP 454 has reached a status
> > wh
2013/11/20 Guido van Rossum :
> I'm guessing CF is the PEP-BDFL?
Yes, you delegated him this PEP :-)
> So he should approve it (the period for
> final comments is long over) and then you can merge.
I'm asking if the code *must* be merged before the beta1, or if it can
be merged later. Charles-Fr
(Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote:
> Serhiy Storchaka wrote:
> > If the transform() method will be added, I prefer to have only
> > one transformation method and specify a direction by the
> > transformation name ("bzip2"/"unbzip2").
Me too. Until I consider specia
On 20 Nov 2013 10:48, "Victor Stinner" wrote:
>
> 2013/11/20 Guido van Rossum :
> > I'm guessing CF is the PEP-BDFL?
>
> Yes, you delegated him this PEP :-)
>
> > So he should approve it (the period for
> > final comments is long over) and then you can merge.
>
> I'm asking if the code *must* be m
How else would you know that anyone is listening? :)
[yay, thanks for our being release monkey!]
-gps
On Tue, Nov 19, 2013 at 11:40 AM, Georg Brandl wrote:
> Am 19.11.2013 17:14, schrieb Mark Lawrence:
> > On 19/11/2013 06:59, Georg Brandl wrote:
> >>
> >> To download Python 3.3.3 rc2 visit:
[Martin v. Löwis]
> ...
> AFAICT, the real driving force is the desire to not read-ahead
> more than the pickle is long. This is what complicates the code.
> The easiest (and most space-efficient) solution to that problem
> would be to prefix the entire pickle with a data size field
> (possibly in
My thought on this for the day, for what it's worth:
Anything that doesn't have directions clearly identifiable
as "encoding" and "decoding" maybe shouldn't be called
a "codec"?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
39 matches
Mail list logo
