Re: [Python-Dev] NTPath or WindowsPath?
18.11.13 04:31, Brian Curtin написав(ла): On Sat, Nov 16, 2013 at 2:50 PM, Serhiy Storchaka wrote: 16.11.13 21:15, Antoine Pitrou написав(ла): In a (private) discussion about PEP 428 and pathlib, Guido proposed that maybe NTPath should be renamed to WindowsPath, since the name is more likely to stay relevant in the middle term. What do you think? What about nturl2path, os.name, sysconfig.get_scheme_names()? What about them? Should nturl2path be renamed to windowsurl2path? Should os.name return "windows" on Windows, and should sysconfig support "windows" scheme name? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] NTPath or WindowsPath?
On 18/11/2013 10:08, Serhiy Storchaka wrote: > 18.11.13 04:31, Brian Curtin написав(ла): >> On Sat, Nov 16, 2013 at 2:50 PM, Serhiy Storchaka >> wrote: >>> 16.11.13 21:15, Antoine Pitrou написав(ла): >>> In a (private) discussion about PEP 428 and pathlib, Guido proposed that maybe NTPath should be renamed to WindowsPath, since the name is more likely to stay relevant in the middle term. What do you think? >>> >>> >>> What about nturl2path, os.name, sysconfig.get_scheme_names()? >> >> What about them? > > Should nturl2path be renamed to windowsurl2path? Should os.name return > "windows" on Windows, and should sysconfig support "windows" scheme name? I think the answer's fairly obviously "no" for reasons of backwards compatibility. (Although that doesn't rule out aliases if someone felt strongly enough about it). I don't say that there's no case for trying address the considerable variety of Python & C ways of saying "I'm on Windows" with the core & stdlib. But I do say that whoever makes a case had better be *very* sure of the impact. Going forwards, however, I'm happy to see new Python code using "Windows" rather than the size-specific "Win32/64" or the dated and over-specific "NT". TJG ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] NTPath or WindowsPath?
On 18 November 2013 10:18, Tim Golden wrote: >> Should nturl2path be renamed to windowsurl2path? Should os.name return >> "windows" on Windows, and should sysconfig support "windows" scheme name? > > I think the answer's fairly obviously "no" for reasons of backwards > compatibility. (Although that doesn't rule out aliases if someone felt > strongly enough about it). > > I don't say that there's no case for trying address the considerable > variety of Python & C ways of saying "I'm on Windows" with the core & > stdlib. But I do say that whoever makes a case had better be *very* sure > of the impact. > > Going forwards, however, I'm happy to see new Python code using > "Windows" rather than the size-specific "Win32/64" or the dated and > over-specific "NT". Agreed on all counts. Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
18.11.13 07:53, Tim Peters написав(ла): - Some easy sanity checking due to the tiny redundancy (if the byte immediately following the current frame is not a FRAME opcode, the pickle is corrupt; and also corrupt if a FRAME opcode is encountered _inside_ the current frame). For efficient unpickling a FRAME opcode followed by 8-byte count should be *last* thing in a frame (unless it is a last frame). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, Nov 18, 2013 at 3:28 AM, Serhiy Storchaka wrote: > 18.11.13 07:53, Tim Peters написав(ла): > > - Some easy sanity checking due to the tiny redundancy (if the byte >> immediately following the current frame is not a FRAME opcode, the >> pickle is corrupt; and also corrupt if a FRAME opcode is encountered >> _inside_ the current frame). >> > > For efficient unpickling a FRAME opcode followed by 8-byte count should be > *last* thing in a frame (unless it is a last frame). > I don't understand that. Clearly the framing is the weakest point of the PEP (== elicits the most bikeshedding). I am also unsure about the value of framing when pickles are written to strings. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, 18 Nov 2013 07:48:27 -0800 Guido van Rossum wrote: > On Mon, Nov 18, 2013 at 3:28 AM, Serhiy Storchaka wrote: > > > 18.11.13 07:53, Tim Peters написав(ла): > > > > - Some easy sanity checking due to the tiny redundancy (if the byte > >> immediately following the current frame is not a FRAME opcode, the > >> pickle is corrupt; and also corrupt if a FRAME opcode is encountered > >> _inside_ the current frame). > >> > > > > For efficient unpickling a FRAME opcode followed by 8-byte count should be > > *last* thing in a frame (unless it is a last frame). > > > > I don't understand that. > > Clearly the framing is the weakest point of the PEP (== elicits the most > bikeshedding). I am also unsure about the value of framing when pickles are > written to strings. It hasn't much value in that case, but the cost is also small (8 bytes every 64KB, roughly). Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Sun, 17 Nov 2013 23:53:09 -0600
Tim Peters wrote:
>
> But I wonder why it isn't done with a new framing opcode instead (say,
> FRAME followed by 8-byte count). I suppose that would be like the
> "prefetch" idea, except that framing opcodes would be mandatory
> (instead of optional) in proto 4. Why I initially like that:
>
> - Uniform decoding loop ("the next thing" _always_ starts with an opcode).
But it's not actually uniform. A frame isn't a normal opcode, it's a
large section of bytes that contains potentially many opcodes.
The framing layer is really below the opcode layer, it makes also sense
to implement it like that.
(I also tried to implement Serhiy's PREFETCH idea, but it didn't bring
any actual simplification)
> When slinging 8-byte counts, _some_ sanity-checking seems like a good idea ;-)
I don't know. It's not much worse (for denial of service opportunities)
than a 4-byte count, which already exists in earlier protocols.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode Exception messages in py2.7
Folks, It seems changing anything about how Exception messages are handles is off the table for 2.7, and a non-issue in 3.* Is it worth opening an issue on this, just so we can close it as won't fix? Or is this thread documentation enough? NOTE about py3: I'm assuming unicode messages are handled properly, as unicode is the default text in py3. However, this has got me thinking about how Exception messages are handled in general. I'm still not clear on where it tries to convert to a string -- it seems to do different things depending on whether you are running on the console, or using the traceback module's print_exception function. I'm thinking that perhaps Exception messages should be as generic as possible. i.e allow any python object as an Exception message, and simple pass that off to whatever wants to do something with it. So far, that seems to be happening with the traceback.print_exception message, but I'm not sure where that conversion is happening in the console report -- clearly it's not using traceback.print_exception, but it is doing it before a final simple: print exp.message at the console. But perhaps it should defer to that last step, i.e. out of the Exception handling code altogether. (or maybe py3 already does that -- in which case, never mind). -Chris -Chris On Fri, Nov 15, 2013 at 3:58 PM, Greg Ewing wrote: > Armin Rigo wrote: > >> I figured that even using the traceback.py module and getting >> "Exception: \u1234\u1235\u5321" is rather useless if you tried to >> raise an exception with a message in Thai. >> > > But at least it tells you that *something* went wrong, > and points to the place in the code where it happened. > That has to be better than pretending that nothing > happened at all. > > Also, if the escaping preserves the original byte > sequence of the message, there's a chance that someone > will be able to figure out what the message said. > > -- > Greg > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > chris.barker%40noaa.gov > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New to the community - Introduction
Hello, I'm Avichal Dayal and I'm new to this community rather the whole open source world. I've been "lurking" around for a while, reading bugs, code and asking relevant doubts on the core-mentorship mailing list. Now I intend to see how the development goes on and be a part of it. Hope to be a part of this community and contribute! Regards, Avichal ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unicode Exception messages in py2.7
On Mon, Nov 18, 2013 at 12:15 PM, Chris Barker wrote: > Folks, > > It seems changing anything about how Exception messages are handles is off > the table for 2.7, and a non-issue in 3.* > > Is it worth opening an issue on this, just so we can close it as won't > fix? Or is this thread documentation enough? > A closed bug wouldn't hurt, but I wouldn't view it as necessary. > > NOTE about py3: I'm assuming unicode messages are handled properly, as > unicode is the default text in py3. However, this has got me thinking about > how Exception messages are handled in general. I'm still not clear on where > it tries to convert to a string -- it seems to do different things > depending on whether you are running on the console, or using the traceback > module's print_exception function. I'm thinking that perhaps Exception > messages should be as generic as possible. i.e allow any python object as > an Exception message, and simple pass that off to whatever wants to > do something with it. So far, that seems to be happening with the > traceback.print_exception message, but I'm not sure where that conversion > is happening in the console report -- clearly it's not using > traceback.print_exception, but it is doing it before a final simple: > > print exp.message > > at the console. But perhaps it should defer to that last step, i.e. out of > the Exception handling code altogether. (or maybe py3 already does that -- > in which case, never mind). > > The conversion is probably happening in Exception.__str__ (don't know about the traceback module w/o looking at it; probably skipping `str(exc)` and building the string from scratch). -Brett > -Chris > > > > > > > > > > > > > -Chris > > > > > On Fri, Nov 15, 2013 at 3:58 PM, Greg Ewing > wrote: > >> Armin Rigo wrote: >> >>> I figured that even using the traceback.py module and getting >>> "Exception: \u1234\u1235\u5321" is rather useless if you tried to >>> raise an exception with a message in Thai. >>> >> >> But at least it tells you that *something* went wrong, >> and points to the place in the code where it happened. >> That has to be better than pretending that nothing >> happened at all. >> >> Also, if the escaping preserves the original byte >> sequence of the message, there's a chance that someone >> will be able to figure out what the message said. >> >> -- >> Greg >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ >> chris.barker%40noaa.gov >> > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [email protected] > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, Nov 18, 2013 at 8:10 AM, Antoine Pitrou wrote: > On Mon, 18 Nov 2013 07:48:27 -0800 > Guido van Rossum wrote: > > On Mon, Nov 18, 2013 at 3:28 AM, Serhiy Storchaka >wrote: > > > > > 18.11.13 07:53, Tim Peters написав(ла): > > > > > > - Some easy sanity checking due to the tiny redundancy (if the byte > > >> immediately following the current frame is not a FRAME opcode, the > > >> pickle is corrupt; and also corrupt if a FRAME opcode is encountered > > >> _inside_ the current frame). > > >> > > > > > > For efficient unpickling a FRAME opcode followed by 8-byte count > should be > > > *last* thing in a frame (unless it is a last frame). > > > > > > > I don't understand that. > > > > Clearly the framing is the weakest point of the PEP (== elicits the most > > bikeshedding). I am also unsure about the value of framing when pickles > are > > written to strings. > > It hasn't much value in that case, but the cost is also small (8 bytes > every 64KB, roughly). > That's small if your pickle is large, but for small pickles it can add up. Still, not enough to reject the PEP. Just get Tim to agree with you, or switch to Tim's proposal. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New to the community - Introduction
On Mon, 18 Nov 2013 23:24:36 +0530 Avichal Dayal wrote: > Hello, > > I'm Avichal Dayal and I'm new to this community rather the whole open > source world. > > I've been "lurking" around for a while, reading bugs, code and asking > relevant doubts on the core-mentorship mailing list. > > Now I intend to see how the development goes on and be a part of it. > Hope to be a part of this community and contribute! Welcome, Avichal. I hope you'll find something to work on that will make you want to contribute! Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, 18 Nov 2013 17:14:21 +0100
Antoine Pitrou wrote:
> On Sun, 17 Nov 2013 23:53:09 -0600
> Tim Peters wrote:
> >
> > But I wonder why it isn't done with a new framing opcode instead (say,
> > FRAME followed by 8-byte count). I suppose that would be like the
> > "prefetch" idea, except that framing opcodes would be mandatory
> > (instead of optional) in proto 4. Why I initially like that:
> >
> > - Uniform decoding loop ("the next thing" _always_ starts with an opcode).
>
> But it's not actually uniform. A frame isn't a normal opcode, it's a
> large section of bytes that contains potentially many opcodes.
>
> The framing layer is really below the opcode layer, it makes also sense
> to implement it like that.
>
> (I also tried to implement Serhiy's PREFETCH idea, but it didn't bring
> any actual simplification)
>
> > When slinging 8-byte counts, _some_ sanity-checking seems like a good idea
> > ;-)
>
> I don't know. It's not much worse (for denial of service opportunities)
> than a 4-byte count, which already exists in earlier protocols.
Actually, now that I think of it, it's even better. A 2**63 bytes
allocation is guaranteed to fail, since most 64-bit CPUs have a smaller
address space than that (for example, x86-64 CPUs seem to have a 48
bits virtual address space).
On the other hand, a 2**31 bytes allocation may very well succeed, eat
almost all the RAM and/or slow down the machine by swapping out.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, 18 Nov 2013 16:02:31 -0600 Tim Peters wrote: > [Guido] > >> Clearly the framing is the weakest point of the PEP (== elicits the most > >> bikeshedding). I am also unsure about the value of framing when pickles are > >> written to strings. > > [Antoine] > > It hasn't much value in that case, > > It has _no_ value in that case, yes? It doesn't appear to have _much_ > value in the case of a seekable stream, either - the implementation > has always been free to read ahead then. The real value appears to be > in cases of non-seekable streams. > > > > but the cost is also small (8 bytes every 64KB, roughly). > > >> That's small if your pickle is large, but for small pickles it can add up. > > Which is annoying. It was already annoying when the PROTO opcode was > introduced, and the size of small pickles increased by 2 bytes. That > added up too :-( Are very small pickles that size-sensitive? I have the impression that if 8 bytes vs. e.g. 15 bytes makes a difference for your application, you'd be better off with a hand-made format. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Guido] >> Clearly the framing is the weakest point of the PEP (== elicits the most >> bikeshedding). I am also unsure about the value of framing when pickles are >> written to strings. [Antoine] > It hasn't much value in that case, It has _no_ value in that case, yes? It doesn't appear to have _much_ value in the case of a seekable stream, either - the implementation has always been free to read ahead then. The real value appears to be in cases of non-seekable streams. > but the cost is also small (8 bytes every 64KB, roughly). >> That's small if your pickle is large, but for small pickles it can add up. Which is annoying. It was already annoying when the PROTO opcode was introduced, and the size of small pickles increased by 2 bytes. That added up too :-( >> Still, not enough to reject the PEP. Just get Tim to agree with you, >> or switch to Tim's proposal. I just asked a question ;-) If a mandatory proto 4 FRAME opcode were added, it would just increase the bloat for small pickles (up from the currently proposed 8 bytes of additional overhead to 9). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Tim]
>> But I wonder why it isn't done with a new framing opcode instead (say,
>> FRAME followed by 8-byte count). I suppose that would be like the
>> "prefetch" idea, except that framing opcodes would be mandatory
>> (instead of optional) in proto 4. Why I initially like that:
>>
>> - Uniform decoding loop ("the next thing" _always_ starts with an opcode).
> But it's not actually uniform. A frame isn't a normal opcode, it's a
> large section of bytes that contains potentially many opcodes.
>
> The framing layer is really below the opcode layer, it makes also sense
> to implement it like that.
That makes sense to me.
> (I also tried to implement Serhiy's PREFETCH idea, but it didn't bring
> any actual simplification)
But it has a different kind of advantage: PREFETCH was optional. As
Guido said, it's annoying to bloat the size of small pickles (which
may, although individually small, occur in great numbers) by 8 bytes
each. There's really no point to framing small chunks of data, right?
Which leads to another idea: after the PROTO opcode, there is, or is
not, an optional PREFETCH opcde with an 8-byte argument. If the
PREFETCH opcode exists, then it gives the number of bytes up to and
including the pickle's STOP opcode. So there's exactly 0 or 1
PREFETCH opcodes per pickle.
Is there an advantage to spraying multiple 8-byte "frame counts"
throughout a pickle stream? 8 bytes is surely enough to specify the
size of any single pickle for half a generation ;-) to come.
>> When slinging 8-byte counts, _some_ sanity-checking seems like a good idea
>> ;-)
> I don't know. It's not much worse (for denial of service opportunities)
> than a 4-byte count, which already exists in earlier protocols.
I'm not thinking of DOS at all, just general sanity as data objects
get larger & larger. Pickles have almost no internal checks now. But
I've seen my share of corrupted pickles! About the only thing that
catches them early is hitting a byte that isn't a legitimate pickle
opcode. That _used_ to be a much stronger check than it is now,
because the 8-bit opcode space was sparsely populated at first. But,
over time, more and more opcodes get added, so the chance of mistaking
a garbage byte for a legit opcode has increased correspondingly.
A PREFETCH opcode with a "bytes until STOP" makes for a decent bad ;-)
sanity check too ;-)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Tim] >> ... >> It was already annoying when the PROTO opcode was introduced, >> and the size of small pickles increased by 2 bytes. That >> added up too :-( [Antoine] > Are very small pickles that size-sensitive? I have the impression that > if 8 bytes vs. e.g. 15 bytes makes a difference for your application, > you'd be better off with a hand-made format. The difference between 8 and 15 is, e.g., nearly doubling the amount of network traffic (for apps that use pickles across processes or machines). A general approach has no way to guess how it will be used. For example, `multiprocessing` uses pickles extensively for inter-process communication of Python data. Some users try broadcasting giant arrays across processes, while others broadcast oceans of tiny integers (like indices into giant arrays inherited via fork()). Since pickle intends to be "the" Python serialization format, it really should try to be friendly for all plausible uses. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, 18 Nov 2013 16:18:21 -0600 Tim Peters wrote: > > But it has a different kind of advantage: PREFETCH was optional. As > Guido said, it's annoying to bloat the size of small pickles (which > may, although individually small, occur in great numbers) by 8 bytes > each. There's really no point to framing small chunks of data, right? You can't know how much space the pickle will take until the pickling ends, though, which makes it difficult to decide whether you want to emit a PREFETCH opcode or not. > Which leads to another idea: after the PROTO opcode, there is, or is > not, an optional PREFETCH opcde with an 8-byte argument. If the > PREFETCH opcode exists, then it gives the number of bytes up to and > including the pickle's STOP opcode. So there's exactly 0 or 1 > PREFETCH opcodes per pickle. > > Is there an advantage to spraying multiple 8-byte "frame counts" > throughout a pickle stream? Well, yes: much better memory usage for large pickles. Some people use pickles to store huge data, which was the motivation to add the 8-byte-size opcodes after all. > I'm not thinking of DOS at all, just general sanity as data objects > get larger & larger. Pickles have almost no internal checks now. But > I've seen my share of corrupted pickles! IMO, any validation should use a dedicated CRC-like scheme, rather than relying on the fact that correct pickles are statistically unlikely :-) (or you can implicitly rely on TCP or UDP checksums, or you disk subsystem's own sanity checks) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, 18 Nov 2013 16:25:07 -0600 Tim Peters wrote: > > [Antoine] > > Are very small pickles that size-sensitive? I have the impression that > > if 8 bytes vs. e.g. 15 bytes makes a difference for your application, > > you'd be better off with a hand-made format. > > The difference between 8 and 15 is, e.g., nearly doubling the amount > of network traffic (for apps that use pickles across processes or > machines). > > A general approach has no way to guess how it will be used. For > example, `multiprocessing` uses pickles extensively for inter-process > communication of Python data. Some users try broadcasting giant > arrays across processes, while others broadcast oceans of tiny > integers (like indices into giant arrays inherited via fork()). Well, sending oceans of tiny integers will also incur many system calls and additional synchronization costs, since sending data on a multiprocessing Queue has to acquire a semaphore. So it generally sounds like a bad idea, IMHO. That said, I agree with: > Since pickle intends to be "the" Python serialization format, it > really should try to be friendly for all plausible uses. I simply don't think adding a fixed 8-byte overhead is actually annoying. It's less than the PyObject overhead in 64-bit mode... Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Tim] >> But it has a different kind of advantage: PREFETCH was optional. As >> Guido said, it's annoying to bloat the size of small pickles (which >> may, although individually small, occur in great numbers) by 8 bytes >> each. There's really no point to framing small chunks of data, right? [Antoine] > You can't know how much space the pickle will take until the pickling > ends, though, which makes it difficult to decide whether you want to > emit a PREFETCH opcode or not. Ah, of course. Presumably the outgoing pickle stream is first stored in some memory buffer, right? If pickling completes before the buffer is first flushed, then you know exactly how large the entire pickle is. If "it's small" (say, < 100 bytes), don't write out the PREFETCH part. Else do. >> Which leads to another idea: after the PROTO opcode, there is, or is >> not, an optional PREFETCH opcde with an 8-byte argument. If the >> PREFETCH opcode exists, then it gives the number of bytes up to and >> including the pickle's STOP opcode. So there's exactly 0 or 1 >> PREFETCH opcodes per pickle. >> >> Is there an advantage to spraying multiple 8-byte "frame counts" >> throughout a pickle stream? > Well, yes: much better memory usage for large pickles. > Some people use pickles to store huge data, which was the motivation to > add the 8-byte-size opcodes after all. We'd have the same advantage _if_ it were feasible to know the entire size up front. I understand now that it's not feasible. > ... > IMO, any validation should use a dedicated CRC-like scheme, rather than > relying on the fact that correct pickles are statistically unlikely :-) OK! A new CRC opcode every two bytes ;-) > (or you can implicitly rely on TCP or UDP checksums, or you disk > subsystem's own sanity checks) Of course we've been doing that all along. Yet I've still seen my share of corrupted pickles anyway. Don't underestimate the determination of users to screw up everything possible in every way possible ;-) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On 19 Nov 2013 08:52, "Tim Peters" wrote: > > [Tim] > >> But it has a different kind of advantage: PREFETCH was optional. As > >> Guido said, it's annoying to bloat the size of small pickles (which > >> may, although individually small, occur in great numbers) by 8 bytes > >> each. There's really no point to framing small chunks of data, right? > > [Antoine] > > You can't know how much space the pickle will take until the pickling > > ends, though, which makes it difficult to decide whether you want to > > emit a PREFETCH opcode or not. > > Ah, of course. Presumably the outgoing pickle stream is first stored > in some memory buffer, right? If pickling completes before the buffer > is first flushed, then you know exactly how large the entire pickle > is. If "it's small" (say, < 100 bytes), don't write out the PREFETCH > part. Else do. > > > >> Which leads to another idea: after the PROTO opcode, there is, or is > >> not, an optional PREFETCH opcde with an 8-byte argument. If the > >> PREFETCH opcode exists, then it gives the number of bytes up to and > >> including the pickle's STOP opcode. So there's exactly 0 or 1 > >> PREFETCH opcodes per pickle. > >> > >> Is there an advantage to spraying multiple 8-byte "frame counts" > >> throughout a pickle stream? > > > Well, yes: much better memory usage for large pickles. > > Some people use pickles to store huge data, which was the motivation to > > add the 8-byte-size opcodes after all. > > We'd have the same advantage _if_ it were feasible to know the entire > size up front. I understand now that it's not feasible. This may be a dumb suggestion (since I don't know the pickle infrastructure at all), but could there be a short section of unframed data before switching to framing mode? For example, emit up to 256 bytes unframed in all pickles, then start emitting appropriate FRAME opcodes if the pickle continues on? Cheers, Nick. > > > ... > > IMO, any validation should use a dedicated CRC-like scheme, rather than > > relying on the fact that correct pickles are statistically unlikely :-) > > OK! A new CRC opcode every two bytes ;-) > > > (or you can implicitly rely on TCP or UDP checksums, or you disk > > subsystem's own sanity checks) > > Of course we've been doing that all along. Yet I've still seen my > share of corrupted pickles anyway. Don't underestimate the > determination of users to screw up everything possible in every way > possible ;-) > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
Ok, how about merging the two sub-threads :-) On Mon, 18 Nov 2013 16:44:59 -0600 Tim Peters wrote: > [Antoine] > > You can't know how much space the pickle will take until the pickling > > ends, though, which makes it difficult to decide whether you want to > > emit a PREFETCH opcode or not. > > Ah, of course. Presumably the outgoing pickle stream is first stored > in some memory buffer, right? If pickling completes before the buffer > is first flushed, then you know exactly how large the entire pickle > is. If "it's small" (say, < 100 bytes), don't write out the PREFETCH > part. Else do. That's true. We could also have a SMALLPREFETCH opcode with a one-byte length to still get the benefits of prefetching. > > Well, yes: much better memory usage for large pickles. > > Some people use pickles to store huge data, which was the motivation to > > add the 8-byte-size opcodes after all. > > We'd have the same advantage _if_ it were feasible to know the entire > size up front. I understand now that it's not feasible. AFAICT, it would only be possible by doing two-pass pickling, which would also slow it down massively. > A long-running process can legitimately put billions of items on work > queues, far more than could ever fit in RAM simultaneously. Comparing > this to PyObject overhead makes no sense to me. Neither does the line > of argument "there are several kinds of overheads, so making this > overhead worse too doesn't matter". Well, it's a question of cost / benefit: does it make sense to optimize something that will be dwarfed by other factors in real world situations? > When possible, we should strive not to add overheads that don't repay > their costs. For small pickles, an 8-byte size field doesn't appear > to buy anything. But I appreciate that it costs implementation effort > to avoid producing it in these cases. I share the concern, although I still don't think the "ocean of tiny pickles" is a reasonable use case :-) That said, assuming you think this is important (do you?), we're left with the following constraints: - it would be nice to have this PEP in 3.4 - 3.4 beta1 and feature freeze is in approximately one week - switching to the PREFETCH scheme requires some non-trivial work on the current patch, work done by either Alexandre or me (but I already have pathlib (PEP 428) on my plate, so it'll have to be Alexandre) - unless you want to do it, of course? What do you think? Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On 18/11/2013 10:25pm, Tim Peters wrote: The difference between 8 and 15 is, e.g., nearly doubling the amount of network traffic (for apps that use pickles across processes or machines). I tried using multiprocessing.Pipe() and send_bytes()/recv_bytes() to send messages between processes: 8 bytes messages -- 525,000 msgs/sec 15 bytes messages -- 556,000 msgs/sec So the size of small messages does not seem to make much difference. (This was in a Linux VM with Python 2.7. Python 3.3 is much slower because it is not implemented in C, but gives similarly close results.) -- Richard ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Antoine] > Well, sending oceans of tiny integers will also incur many system calls > and additional synchronization costs, since sending data on a > multiprocessing Queue has to acquire a semaphore. So it generally > sounds like a bad idea, IMHO. > > That said, I agree with: >> Since pickle intends to be "the" Python serialization format, it >> really should try to be friendly for all plausible uses. > > I simply don't think adding a fixed 8-byte overhead is actually > annoying. It's less than the PyObject overhead in 64-bit mode... A long-running process can legitimately put billions of items on work queues, far more than could ever fit in RAM simultaneously. Comparing this to PyObject overhead makes no sense to me. Neither does the line of argument "there are several kinds of overheads, so making this overhead worse too doesn't matter". When possible, we should strive not to add overheads that don't repay their costs. For small pickles, an 8-byte size field doesn't appear to buy anything. But I appreciate that it costs implementation effort to avoid producing it in these cases. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On 19 Nov 2013 09:33, "Tim Peters" wrote: > > [Antoine] > > Well, sending oceans of tiny integers will also incur many system calls > > and additional synchronization costs, since sending data on a > > multiprocessing Queue has to acquire a semaphore. So it generally > > sounds like a bad idea, IMHO. > > > > That said, I agree with: > >> Since pickle intends to be "the" Python serialization format, it > >> really should try to be friendly for all plausible uses. > > > > I simply don't think adding a fixed 8-byte overhead is actually > > annoying. It's less than the PyObject overhead in 64-bit mode... > > A long-running process can legitimately put billions of items on work > queues, far more than could ever fit in RAM simultaneously. Comparing > this to PyObject overhead makes no sense to me. Neither does the line > of argument "there are several kinds of overheads, so making this > overhead worse too doesn't matter". > > When possible, we should strive not to add overheads that don't repay > their costs. For small pickles, an 8-byte size field doesn't appear > to buy anything. But I appreciate that it costs implementation effort > to avoid producing it in these cases. Given that cases where the overhead matters can drop back to proto 3 if absolutely necessary, perhaps it's reasonable to just run with the current proposal? Cheers, Nick. > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, 18 Nov 2013 16:44:59 -0600 Tim Peters wrote: > [Tim] > >> But it has a different kind of advantage: PREFETCH was optional. As > >> Guido said, it's annoying to bloat the size of small pickles (which > >> may, although individually small, occur in great numbers) by 8 bytes > >> each. There's really no point to framing small chunks of data, right? > > [Antoine] > > You can't know how much space the pickle will take until the pickling > > ends, though, which makes it difficult to decide whether you want to > > emit a PREFETCH opcode or not. > > Ah, of course. Presumably the outgoing pickle stream is first stored > in some memory buffer, right? If pickling completes before the buffer > is first flushed, then you know exactly how large the entire pickle > is. If "it's small" (say, < 100 bytes), don't write out the PREFETCH > part. Else do. Yet another possibility: keep framing but use a variable-length encoding for the frame size: - first byte: bits 7-5: N (= frame size bytes length - 1) - first byte: bits 4-0: first 5 bits of frame size - remaning N bytes: remaining bits of frame size With this scheme, very small pickles have a one byte overhead; small ones a two byte overhead; and the max frame size is 2**61 rather than 2**64, which should still be sufficient. And the frame size is read using either one or two read() calls, which is efficient. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On 19 November 2013 09:57, Antoine Pitrou wrote: > On Mon, 18 Nov 2013 16:44:59 -0600 > Tim Peters wrote: >> [Tim] >> >> But it has a different kind of advantage: PREFETCH was optional. As >> >> Guido said, it's annoying to bloat the size of small pickles (which >> >> may, although individually small, occur in great numbers) by 8 bytes >> >> each. There's really no point to framing small chunks of data, right? >> >> [Antoine] >> > You can't know how much space the pickle will take until the pickling >> > ends, though, which makes it difficult to decide whether you want to >> > emit a PREFETCH opcode or not. >> >> Ah, of course. Presumably the outgoing pickle stream is first stored >> in some memory buffer, right? If pickling completes before the buffer >> is first flushed, then you know exactly how large the entire pickle >> is. If "it's small" (say, < 100 bytes), don't write out the PREFETCH >> part. Else do. > > Yet another possibility: keep framing but use a variable-length > encoding for the frame size: > > - first byte: bits 7-5: N (= frame size bytes length - 1) > - first byte: bits 4-0: first 5 bits of frame size > - remaning N bytes: remaining bits of frame size > > With this scheme, very small pickles have a one byte overhead; small > ones a two byte overhead; and the max frame size is 2**61 rather than > 2**64, which should still be sufficient. > > And the frame size is read using either one or two read() calls, which > is efficient. And it's only a minimal change from the current patch. Sounds good to me. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, Nov 18, 2013 at 4:30 PM, Nick Coghlan wrote: > On 19 November 2013 09:57, Antoine Pitrou wrote: > > On Mon, 18 Nov 2013 16:44:59 -0600 > > Tim Peters wrote: > >> [Tim] > >> >> But it has a different kind of advantage: PREFETCH was optional. As > >> >> Guido said, it's annoying to bloat the size of small pickles (which > >> >> may, although individually small, occur in great numbers) by 8 bytes > >> >> each. There's really no point to framing small chunks of data, > right? > >> > >> [Antoine] > >> > You can't know how much space the pickle will take until the pickling > >> > ends, though, which makes it difficult to decide whether you want to > >> > emit a PREFETCH opcode or not. > >> > >> Ah, of course. Presumably the outgoing pickle stream is first stored > >> in some memory buffer, right? If pickling completes before the buffer > >> is first flushed, then you know exactly how large the entire pickle > >> is. If "it's small" (say, < 100 bytes), don't write out the PREFETCH > >> part. Else do. > > > > Yet another possibility: keep framing but use a variable-length > > encoding for the frame size: > > > > - first byte: bits 7-5: N (= frame size bytes length - 1) > > - first byte: bits 4-0: first 5 bits of frame size > > - remaning N bytes: remaining bits of frame size > > > > With this scheme, very small pickles have a one byte overhead; small > > ones a two byte overhead; and the max frame size is 2**61 rather than > > 2**64, which should still be sufficient. > > > > And the frame size is read using either one or two read() calls, which > > is efficient. > > And it's only a minimal change from the current patch. Sounds good to me. > Food for thought: maybe we should have variable-encoding lengths for all opcodes, rather than the current cumbersome scheme? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Antoine] > Yet another possibility: keep framing but use a variable-length > encoding for the frame size: > > - first byte: bits 7-5: N (= frame size bytes length - 1) > - first byte: bits 4-0: first 5 bits of frame size > - remaning N bytes: remaining bits of frame size > > With this scheme, very small pickles have a one byte overhead; small > ones a two byte overhead; and the max frame size is 2**61 rather than > 2**64, which should still be sufficient. > > And the frame size is read using either one or two read() calls, which > is efficient. That would be a happy compromise :-) I'm unclear on how that would work for, e.g., encoding 40 = 0b000101000. That has 6 significant bits. Would you store 0 in the leading byte and 40 in the second byte? That would work. 2**61 = 2,305,843,009,213,693,952 is a lot of bytes, especially for a pickle ;-) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Guido] > Food for thought: maybe we should have variable-encoding lengths for all > opcodes, rather than the current cumbersome scheme? Yes, but not for protocol 4 - time's running out fast for that. When we "only" had the XXX1, XXX2, and XXX4 opcodes, it was kinda silly, but after adding XXX8 flavors to all of those it's become unbearable. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Richard Oudkerk] > I tried using multiprocessing.Pipe() and send_bytes()/recv_bytes() to send > messages between processes: > > 8 bytes messages -- 525,000 msgs/sec > 15 bytes messages -- 556,000 msgs/sec > > So the size of small messages does not seem to make much difference. To the contrary, the lesson is clear: to speed up multiprocessing, the larger the messages the faster it goes ;-) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On Mon, 18 Nov 2013 18:50:01 -0600 Tim Peters wrote: > [Antoine] > > Yet another possibility: keep framing but use a variable-length > > encoding for the frame size: > > > > - first byte: bits 7-5: N (= frame size bytes length - 1) > > - first byte: bits 4-0: first 5 bits of frame size > > - remaning N bytes: remaining bits of frame size > > > > With this scheme, very small pickles have a one byte overhead; small > > ones a two byte overhead; and the max frame size is 2**61 rather than > > 2**64, which should still be sufficient. > > > > And the frame size is read using either one or two read() calls, which > > is efficient. > > That would be a happy compromise :-) > > I'm unclear on how that would work for, e.g., encoding 40 = > 0b000101000. That has 6 significant bits. Would you store 0 in the > leading byte and 40 in the second byte? That would work. Yeah, I haven't decided whether it would be big-endian or little-endian. It doesn't matter much. big-endian sounds a bit easier to decode and encode (no bit shifts needed), it's also less consistent with the rest of the pickle opcodes. > 2**61 = 2,305,843,009,213,693,952 is a lot of bytes, especially for a pickle > ;-) Let's call it a biggle :-) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Antoine] >>> - first byte: bits 7-5: N (= frame size bytes length - 1) >>> - first byte: bits 4-0: first 5 bits of frame size >>> - remaning N bytes: remaining bits of frame size [Tim] >> I'm unclear on how that would work for, e.g., encoding 40 = >> 0b000101000. That has 6 significant bits. Would you store 0 in the >> leading byte and 40 in the second byte? That would work. [Antoine] > Yeah, I haven't decided whether it would be big-endian or > little-endian. It doesn't matter much. big-endian sounds a bit easier > to decode and encode (no bit shifts needed), it's also less consistent > with the rest of the pickle opcodes. As you've told me, the framing layer is beneath the opcode layer, so what opcodes do is irrelevant ;-) Big-endian would be my choice (easier (en)(de)coding, both via software and via eyeball when staring at dumps);. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
On 19/11/2013 12:55am, Tim Peters wrote: [Richard Oudkerk] I tried using multiprocessing.Pipe() and send_bytes()/recv_bytes() to send messages between processes: 8 bytes messages -- 525,000 msgs/sec 15 bytes messages -- 556,000 msgs/sec So the size of small messages does not seem to make much difference. To the contrary, the lesson is clear: to speed up multiprocessing, the larger the messages the faster it goes ;-) Ah, yes. It was probably round the other way. -- Richard ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
[Antoine] > ... > Well, it's a question of cost / benefit: does it make sense to optimize > something that will be dwarfed by other factors in real world > situations? For most of my career, a megabyte of RAM was an unthinkable luxury. Now I'm running on an OS that needs a gigabyte of RAM just to boot. So I'm old enough to think from the opposite end: "does it make sense to bloat something that's already working fine?". It's the "death of a thousand cuts" (well, this thing doesn't matter _that_ much - and neither does that, nor those others over there ...) that leads to a GiB-swallowing OS and a once-every-4-years crusade to reduce Python's startup time. For examples ;-) > ... > That said, assuming you think this is important (do you?), Honestly, it's more important to me "in theory" to oppose unnecessary bloat (of all kinds). But, over time, it's attitude that shapes results, so I'm not apologetic about that. > we're left with the following constraints: > - it would be nice to have this PEP in 3.4 > - 3.4 beta1 and feature freeze is in approximately one week > - switching to the PREFETCH scheme requires some non-trivial work on the > current patch, work done by either Alexandre or me (but I already > have pathlib (PEP 428) on my plate, so it'll have to be Alexandre) - > unless you want to do it, of course? > > What do you think? I wouldn't hold up PEP acceptance for this. It won't be a disaster in any case, just - at worse - another little ratchet in the "needless bloat" direction. And the PEP has more things that are pure wins. If it's possible to squeeze in the variable-length encoding, that would be great. If I were you, though, I'd check the patch in as-is, just in case. I can't tell whether I'll have time to work on it (have other things going now outside my control). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.3.3 final
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm very happy to announce the release of Python 3.3.3. Python 3.3.3 includes several security fixes and over 150 bug fixes compared to the Python 3.3.2 release. Importantly, a security bug in CGIHTTPServer was fixed [1]. Thank you to those who tested the 3.3.3 release candidate! This release fully supports OS X 10.9 Mavericks. In particular, this release fixes an issue that could cause previous versions of Python to crash when typing in interactive mode on OS X 10.9. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in the 3.3 series, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.3 rc2 visit: http://www.python.org/download/releases/3.3.3/ This is a production release, please report any bugs to http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) [1] http://bugs.python.org/issue19435 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlKLDGYACgkQN9GcIYhpnLCjewCfQ+EJHpzGzIyTvYOrYmsRmnbv n40AniVM0UuQWpPrlCu349fu7Edt+d4+ =WSIj -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
19.11.13 01:10, Antoine Pitrou написав(ла): - switching to the PREFETCH scheme requires some non-trivial work on the current patch, work done by either Alexandre or me (but I already have pathlib (PEP 428) on my plate, so it'll have to be Alexandre) - unless you want to do it, of course? I had implemented optimized PREFETCH scheme months ago (the code was smaller than with the framing layer). I need a day or two to update the code to the current Alexandre's patch. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
