On 5/25/06, Runar Petursson <[EMAIL PROTECTED]> wrote:
>
> On 5/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > If you really need this for speed, I recommend you make it a custom
> extension.
> >
> >
>  The custom extension is a good idea, and what we do now.  But now that the
> long algorithm is so fast, it would be nice to expose it at least at the C
> level to use a substring.  Any solution--be it buffer based or even an
> module could have no reuse of the code without an End Pointer.  If we added
> the end pointer to a FromSubstring (or somesuch) function (leaving
> PyLong_FromString alone), it would be easily reused from any parsing module.
>  Assuming it didn't have any negative performance implication.

This discussion about conversion of longs is very much related to the
new hot buffer class I'm currently adding in the bytebuf branch, which
will directly tackle the issue of I/O on a fixed buffer without
intermediate string creation or memory copy.  You will be able to pack
and unpack structs directly into and out of a fixed memory buffer.  In
case you're interested, it is a clone of the Java NIO ByteBuffer class
for Python.  I'm making minor modifications to the socket and struct
modules to support I/O using the buffer protocol.  The hot buffer
class will live in a module and neither of the socket nor struct
modules will depend on it.

Following Fredrik's suggestion I will write up a mini-PEP for
discussion of this idea and will move the code in the sandbox (and out
of a branch).

Additionally, I must say, all that hot water in the blue lagoon this
morning was a really hot justficiation for the "hot buffer" name.
http://furius.ca/tmp/nfs3/html/2006-05-25.11185801.html




--
Martin Blais
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to