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
On 19 November 2013 22:24, Walter Dörwald wal...@livinglogic.de 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
On Sun, Nov 17, 2013 at 6:20 AM, Brett Cannon br...@python.org wrote:
On Nov 17, 2013 8:58 AM, Eli Bendersky eli...@gmail.com wrote:
On Sat, Nov 16, 2013 at 3:44 PM, Brett Cannon br...@python.org wrote:
On Sat, Nov 16, 2013 at 1:40 PM, Eric Snow ericsnowcurren...@gmail.com
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
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
On Mon, 18 Nov 2013 16:48:05 -0800
Guido van Rossum gu...@python.org 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
So why is framing different?
On Tue, Nov 19, 2013 at 10:51 AM, Antoine Pitrou solip...@pitrou.netwrote:
On Mon, 18 Nov 2013 16:48:05 -0800
Guido van Rossum gu...@python.org wrote:
Food for thought: maybe we should have variable-encoding lengths for all
opcodes, rather than the current
On Tue, 19 Nov 2013 19:51:10 +0100
Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 18 Nov 2013 16:48:05 -0800
Guido van Rossum gu...@python.org 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 10:52:58 -0800
Guido van Rossum gu...@python.org 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.
___
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 solip...@pitrou.netwrote:
On Tue, 19 Nov 2013 10:52:58 -0800
Guido van Rossum gu...@python.org wrote:
So why is framing different?
Because it doesn't use
On Tue, 19 Nov 2013 11:05:45 -0800
Guido van Rossum gu...@python.org 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
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
[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's my firm
On Tue, 19 Nov 2013 13:22:52 -0600
Tim Peters tim.pet...@gmail.com 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
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 logic
On Tue, 19 Nov 2013 21:25:34 +0100
Martin v. Löwis mar...@v.loewis.de 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
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
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 buffering.
Well,
On Tue, 19 Nov 2013 15:17:06 -0600
Tim Peters tim.pet...@gmail.com 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
[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,
ignore it,
On Tue, 19 Nov 2013 15:41:51 -0600
Tim Peters tim.pet...@gmail.com 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
On Tue, Nov 19, 2013 at 4:04 PM, Antoine Pitrou solip...@pitrou.net 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
[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 on that, but
On Tue, 19 Nov 2013 17:02:15 -0500
Brett Cannon br...@python.org wrote:
On Tue, Nov 19, 2013 at 4:04 PM, Antoine Pitrou solip...@pitrou.net 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
On Tue, 19 Nov 2013 16:06:22 -0600
Tim Peters tim.pet...@gmail.com 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
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 mar...@v.loewis.de 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
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 pickle.load()
2013/11/11 Charles-François Natali cf.nat...@gmail.com:
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
On Wed, 20 Nov 2013 00:56:13 +0100
Martin v. Löwis mar...@v.loewis.de 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
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 victor.stin...@gmail.comwrote:
2013/11/11 Charles-François Natali cf.nat...@gmail.com:
After several exchanges with
2013/11/20 Guido van Rossum gu...@python.org:
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
(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 special cases
On 20 Nov 2013 10:48, Victor Stinner victor.stin...@gmail.com wrote:
2013/11/20 Guido van Rossum gu...@python.org:
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
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 g.bra...@gmx.net 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
[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 a
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
39 matches
Mail list logo
