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?
-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 wa
[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
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 mak
[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. Wo
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
> > - reman
[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 contrar
[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 f
[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
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 bloa
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
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. The
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, IM
[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 intend
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:
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.
>
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 real
[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?
[A
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 an
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 po
[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 yo
[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 d
[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
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 cas
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
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 i
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 redundan
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 documentatio
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
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 handle
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
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 FR
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
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 unpickli
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 tha
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 NTPat
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
37 matches
Mail list logo
