Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 08:57, Greg Ewing wrote: > Nick Coghlan wrote: > > Personally, I *like* CPython fitting into the "simple-and-portable" >> niche in the Python interpreter space. >> > > Me, too! I like that I can read the CPython source and > understand what it's doing most of the time. Ple

Re: [Python-Dev] PEP 393 review

> I don't compare ASCII and ISO-8859-1 decoders. I was asking if decoding > b'abc' > from ISO-8859-1 is faster than decoding b'ab\xff' from ISO-8859-1, and if > yes: > why? No, that makes no difference. > > Your patch replaces PyUnicode_New(size, 255) ... memcpy(), by > PyUnicode_FromUCS1(

Re: [Python-Dev] Python 3 optimizations continued...

Nick Coghlan wrote: Personally, I *like* CPython fitting into the "simple-and-portable" niche in the Python interpreter space. Me, too! I like that I can read the CPython source and understand what it's doing most of the time. Please don't screw that up by attempting to perform heroic optimisa

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

Guido van Rossum wrote: On Mon, Aug 29, 2011 at 2:17 PM, Greg Ewing wrote: All you need to do when writing the .pyx file is follow the same API that you would if you were writing C code to use the library. Interesting. Then how does Pyrex/Cython typecheck your code at compile time? You m

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 12:38 PM, Gregory P. Smith wrote: > Some in this thread seemed to give the impression that CPython performance > is not something to care about. I disagree. I see CPython being the main > implementation of Python used in most places for a long time. Improving its > performa

Re: [Python-Dev] Python 3 optimizations continued...

On Mon, Aug 29, 2011 at 2:05 PM, stefan brunthaler wrote: > > The question really is whether this is an all-or-nothing deal. If you > > could identify smaller parts that can be applied independently, interest > > would be higher. > > > Well, it's not an all-or-nothing deal. In my current architect

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, 30 Aug 2011 10:00:28 +1000 Nick Coghlan wrote: > > > > Having a word-sized "bytecode" format would probably be acceptable in > > itself, so if you want to submit a patch for that, go ahead. > > Although any such patch should discuss how it compares with Cesare's > work on wpython. > Perso

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

On 8/29/2011 3:41 PM, Nir Aides wrote: I am not familiar with the python-dev definition for deprecation, but Possible to planned eventual removal when I used the word in the bug discussion I meant to advertize to users that they should not mix threading and forking since that mix is and will

Re: [Python-Dev] Python 3 optimizations continued...

> Personally, I *like* CPython fitting into the "simple-and-portable" > niche in the Python interpreter space. Armin Rigo made the judgment > years ago that CPython was a poor platform for serious optimisation > when he stopped working on Psyco and started PyPy instead, and I think > the contrastin

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

On Mon, Aug 29, 2011 at 2:17 PM, Greg Ewing wrote: > Guido van Rossum wrote: >> >> (Just like Python's own .h files -- >> e.g. the extensive renaming of the Unicode APIs depending on >> narrow/wide build) How does Cython deal with these? > > Pyrex/Cython deal with it by generating C code that incl

Re: [Python-Dev] Python 3 optimizations continued...

On Tue, Aug 30, 2011 at 7:14 AM, Antoine Pitrou wrote: > On Mon, 29 Aug 2011 11:33:14 -0700 > stefan brunthaler wrote: >> * The optimized dispatch routine has a changed instruction format >> (word-sized instead of bytecodes) that allows for regular instruction >> decoding (without the HAS_ARG-che

Re: [Python-Dev] Ctypes and the stdlib

On Mon, Aug 29, 2011 at 2:39 AM, Stefan Behnel wrote: > Guido van Rossum, 29.08.2011 04:27: >> Hm, the main use that was proposed here for ctypes is to wrap existing >> libraries (not to create nicer APIs, that can be done in pure Python >> on top of this). > > The same applies to Cython, obviousl

Re: [Python-Dev] PEP 3151 from the BDFOP

On Tue, Aug 30, 2011 at 7:18 AM, Barry Warsaw wrote: > Okay, so here's what's still outstanding for me: > > * Should we eliminate FileSystemError? (probably "yes") I've also been persuaded that this isn't a generally meaningful categorisation, so +1 for dropping it. ConnectionError is worth keepi

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

On Sat, Aug 27, 2011 at 11:58 PM, Terry Reedy wrote: > Dan, I once had the more or less the same opinion/question as you with > regard to ctypes, but I now see at least 3 problems. > > 1) It seems hard to write it correctly. There are currently 47 open ctypes > issues, with 9 being feature reques

Re: [Python-Dev] Python 3 optimizations continued...

> Does it speed up Python? :-) Could you provide numbers (benchmarks)? > Yes, it does ;) The maximum overall speedup I achieved was by a factor of 2.42 on my i7-920 for the spectralnorm benchmark of the computer language benchmark game. Others from the same set are: binarytrees: 1.9257 (1.9891)

Re: [Python-Dev] PEP 393 review

Le lundi 29 août 2011 21:34:48, vous avez écrit : > >> Those haven't been ported to the new API, yet. Consider, for example, > >> d9821affc9ee. Before that, I got 253 MB/s on the 4096 units read test; > >> with that change, I get 610 MB/s. The trunk gives me 488 MB/s, so this > >> is a 25% speedup

Re: [Python-Dev] Python 3 optimizations continued...

Le lundi 29 août 2011 19:35:14, stefan brunthaler a écrit : > pretty much a year ago I wrote about the optimizations I did for my > PhD thesis that target the Python 3 series interpreters Does it speed up Python? :-) Could you provide numbers (benchmarks)? Victor

Re: [Python-Dev] PEP 3151 from the BDFOP

On Mon, 29 Aug 2011 17:18:33 -0400 Barry Warsaw wrote: > On Aug 24, 2011, at 01:57 AM, Antoine Pitrou wrote: > > >> One guiding principle for me is that we should keep the abstraction as thin > >> as possible. In particular, I'm concerned about mapping multiple errnos > >> into a single Error.

Re: [Python-Dev] SWIG (was Re: Ctypes and the stdlib)

Thanks for an insightful post, Dave! I took the liberty of mentioning it on Google+: https://plus.google.com/115212051037621986145/posts/NyEiLEfR6HF (PS. Anyone wanting a G+ invite, go here: https://plus.google.com/i/7w3niYersIA:8fxDrfW-6TA ) --Guido On Mon, Aug 29, 2011 at 5:41 AM, David Beazl

Re: [Python-Dev] PEP 3151 from the BDFOP

On Aug 24, 2011, at 01:57 AM, Antoine Pitrou wrote: >> One guiding principle for me is that we should keep the abstraction as thin >> as possible. In particular, I'm concerned about mapping multiple errnos >> into a single Error. For example both EPIPE and ESHUTDOWN mapping to >> BrokePipeError,

Re: [Python-Dev] PEP 3151 from the BDFOP

On Aug 24, 2011, at 12:51 PM, Nick Coghlan wrote: >On Wed, Aug 24, 2011 at 9:57 AM, Antoine Pitrou wrote: >> Using IOError.__new__ is the easiest way to ensure that all code >> raising IO errors takes advantage of the errno mapping. Otherwise you >> may get APIs raising the proper subclasses, and

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

Guido van Rossum wrote: (Just like Python's own .h files -- e.g. the extensive renaming of the Unicode APIs depending on narrow/wide build) How does Cython deal with these? Pyrex/Cython deal with it by generating C code that includes the relevant headers, so the C compiler expands all the macro

Re: [Python-Dev] Python 3 optimizations continued...

On Mon, 29 Aug 2011 11:33:14 -0700 stefan brunthaler wrote: > * The optimized dispatch routine has a changed instruction format > (word-sized instead of bytecodes) that allows for regular instruction > decoding (without the HAS_ARG-check) and inlinind of some objects in > the instruction format on

Re: [Python-Dev] Python 3 optimizations continued...

> The question really is whether this is an all-or-nothing deal. If you > could identify smaller parts that can be applied independently, interest > would be higher. > Well, it's not an all-or-nothing deal. In my current architecture, I can selectively enable most of the optimizations as I see fit.

Re: [Python-Dev] PEP 393 review

On Mon, 29 Aug 2011 22:32:01 +0200 "Martin v. Löwis" wrote: > I have now written a Django application to measure the effect of PEP > 393, using the debug mode (to find all strings), and sys.getsizeof: > > https://bitbucket.org/t0rsten/pep-393/src/ad02e1b4cad9/pep393utils/djmemprof/count/views.py

Re: [Python-Dev] PEP 393 review

"Martin v. Löwis" wrote: > tl;dr: PEP-393 reduces the memory usage for strings of a very small > Django app from 7.4MB to 4.4MB, all other objects taking about 1.9MB. > > Am 26.08.2011 16:55, schrieb Guido van Rossum: >> It would be nice if someone wrote a test to roughly verify these >> numbers,

Re: [Python-Dev] Python 3 optimizations continued...

> So, the two big issues aside, is there any interest in incorporating > these optimizations in Python 3? The question really is whether this is an all-or-nothing deal. If you could identify smaller parts that can be applied independently, interest would be higher. Also, I'd be curious whether yo

Re: [Python-Dev] PEP 393 review

tl;dr: PEP-393 reduces the memory usage for strings of a very small Django app from 7.4MB to 4.4MB, all other objects taking about 1.9MB. Am 26.08.2011 16:55, schrieb Guido van Rossum: > It would be nice if someone wrote a test to roughly verify these > numbers, e.v. by allocating lots of strings

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

On Mon, Aug 29, 2011 at 8:42 PM, Jesse Noller wrote: > On Mon, Aug 29, 2011 at 1:22 PM, Antoine Pitrou wrote: >> >> That sanitization is generally useful, though. For example if you want >> to use any I/O after a fork(). > > Oh! I don't disagree; I'm just against the removal of the ability to > m

Re: [Python-Dev] PEP 393 review

>> Those haven't been ported to the new API, yet. Consider, for example, >> d9821affc9ee. Before that, I got 253 MB/s on the 4096 units read test; >> with that change, I get 610 MB/s. The trunk gives me 488 MB/s, so this >> is a 25% speedup for PEP 393. > > If I understand correctly, the performan

Re: [Python-Dev] SWIG (was Re: Ctypes and the stdlib)

Then there is gccxml, although I'm not sure how active it is now. ___ 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.

Re: [Python-Dev] Should we move to replace re with regex?

On 8/29/2011 9:00 AM, Barry Warsaw wrote: On Aug 27, 2011, at 07:11 PM, Martin v. Löwis wrote: A PEP should IMO only cover end-user aspects of the new re module. Code organization is typically not in the PEP. To give a specific example: you mentioned that there is (near) code duplication MRAB's

Re: [Python-Dev] PEP 393 review

Am 29.08.2011 11:03, schrieb Dirkjan Ochtman: > On Sun, Aug 28, 2011 at 21:47, "Martin v. Löwis" wrote: >> result strings. In PEP 393, a buffer must be scanned for the >> highest code point, which means that each byte must be inspected >> twice (a second time when the copying occurs). > > This

Re: [Python-Dev] LZMA compression support in 3.3

I've updated the issue with a patch containing my work so far - the LZMACompressor and LZMADecompressor classes, along with some tests. These two classes should provide a fairly complete interface to liblzma; it will be possible to implement LZMAFile on top of the

Re: [Python-Dev] PEP categories (was Re: PEP 393 review)

On Aug 29, 2011, at 06:40 PM, Antoine Pitrou wrote: >I like the 3k numbers myself :)) Me too. :) But I think we've pretty much abandoned that convention for any new PEPs. Well, until Guido announces Python 4k. :) -Barry signature.asc Description: PGP signature ___

Re: [Python-Dev] PEP categories (was Re: PEP 393 review)

On Aug 29, 2011, at 06:55 PM, Stefan Behnel wrote: >These things tend to get somewhat clumsy over time, though. What about a >stdlib change that only applies to CPython for some reason, e.g. because no >other implementation currently has that module? I think it's ok to make a >coarse-grained dist

Re: [Python-Dev] SWIG (was Re: Ctypes and the stdlib)

On Mon, Aug 29, 2011 at 7:14 PM, Eli Bendersky wrote: > >> >> I've sometimes thought it might be interesting to create a Swig >> replacement purely in Python.  When I work on the PLY project, this is often >> what I think about.   In that project, I've actually built a number of the >> parsing to

Re: [Python-Dev] Python 3 optimizations continued...

> Perhaps there would be something to say given patches/overviews/specifics. > Currently I don't have patches, but for an overview and specifics, I can provide the following: * My optimizations basically rely on quickening to incorporate run-time information. * I use two separate instruction dispat

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

On Mon, Aug 29, 2011 at 8:16 PM, Antoine Pitrou wrote: > > On Mon, 29 Aug 2011 13:03:53 -0400 Jesse Noller wrote: > > > > Yes; but spawning and forking are both slow to begin with - it's > > documented (I hope heavily enough) that you should spawn > > multiprocessing children early, and keep them

Re: [Python-Dev] Python 3 optimizations continued...

2011/8/29 stefan brunthaler : > So, the two big issues aside, is there any interest in incorporating > these optimizations in Python 3? Perhaps there would be something to say given patches/overviews/specifics. -- Regards, Benjamin ___ Python-Dev mail

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

On Mon, Aug 29, 2011 at 1:22 PM, Antoine Pitrou wrote: > Le lundi 29 août 2011 à 13:23 -0400, Jesse Noller a écrit : >> >> Yes, it is annoying; but again - this makes it more consistent with >> the windows implementation. I'd rather that restriction than the >> "sanitization" of the ability to use

[Python-Dev] Python 3 optimizations continued...

Hi, pretty much a year ago I wrote about the optimizations I did for my PhD thesis that target the Python 3 series interpreters. While I got some replies, the discussion never really picked up and no final explicit conclusion was reached. AFAICT, because of the following two factors, my optimizati

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

Le lundi 29 août 2011 à 13:23 -0400, Jesse Noller a écrit : > > Yes, it is annoying; but again - this makes it more consistent with > the windows implementation. I'd rather that restriction than the > "sanitization" of the ability to use threading and multiprocessing > alongside one another. That

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

On Mon, Aug 29, 2011 at 1:16 PM, Antoine Pitrou wrote: > On Mon, 29 Aug 2011 13:03:53 -0400 > Jesse Noller wrote: >> 2011/8/29 Charles-François Natali : >> >> +3 (agreed to Jesse, Antoine and Ask here). >> >>  The http://bugs.python.org/issue8713 described "non-fork" implementation >> >> that alw

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

On Mon, 29 Aug 2011 13:03:53 -0400 Jesse Noller wrote: > 2011/8/29 Charles-François Natali : > >> +3 (agreed to Jesse, Antoine and Ask here). > >>  The http://bugs.python.org/issue8713 described "non-fork" implementation > >> that always uses subprocesses rather than plain forked processes is the

Re: [Python-Dev] SWIG (was Re: Ctypes and the stdlib)

> I've sometimes thought it might be interesting to create a Swig replacement > purely in Python. When I work on the PLY project, this is often what I > think about. In that project, I've actually built a number of the parsing > tools that would be useful in creating such a thing. The only c

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

2011/8/29 Charles-François Natali : >> +3 (agreed to Jesse, Antoine and Ask here). >>  The http://bugs.python.org/issue8713 described "non-fork" implementation >> that always uses subprocesses rather than plain forked processes is the >> right way forward for multiprocessing. > > I see two drawback

Re: [Python-Dev] PEP categories (was Re: PEP 393 review)

Barry Warsaw, 29.08.2011 18:24: On Aug 29, 2011, at 11:03 AM, Dirkjan Ochtman wrote: Also, this PEP makes me wonder if there should be a way to distinguish between language PEPs and (CPython) implementation PEPs, by adding a tag or using the PEP number ranges somehow. I've thought about this,

Re: [Python-Dev] PEP categories (was Re: PEP 393 review)

On Mon, 29 Aug 2011 18:38:23 +0200 Dirkjan Ochtman wrote: > On Mon, Aug 29, 2011 at 18:24, Barry Warsaw wrote: > >>Also, this PEP makes me wonder if there should be a way to distinguish > >>between language PEPs and (CPython) implementation PEPs, by adding a > >>tag or using the PEP number ranges

Re: [Python-Dev] PEP categories (was Re: PEP 393 review)

On Mon, Aug 29, 2011 at 18:24, Barry Warsaw wrote: >>Also, this PEP makes me wonder if there should be a way to distinguish >>between language PEPs and (CPython) implementation PEPs, by adding a >>tag or using the PEP number ranges somehow. > > I've thought about this, and about a similar split be

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

> +3 (agreed to Jesse, Antoine and Ask here). >  The http://bugs.python.org/issue8713 described "non-fork" implementation > that always uses subprocesses rather than plain forked processes is the > right way forward for multiprocessing. I see two drawbacks: - it will be slower, since the interpret

[Python-Dev] PEP categories (was Re: PEP 393 review)

On Aug 29, 2011, at 11:03 AM, Dirkjan Ochtman wrote: >Also, this PEP makes me wonder if there should be a way to distinguish >between language PEPs and (CPython) implementation PEPs, by adding a >tag or using the PEP number ranges somehow. I've thought about this, and about a similar split betwee

Re: [Python-Dev] Cython, ctypes and the stdlib

Hi, I agree that this is getting off-topic for this list. I'm answering here in a certain detail to lighten things up a bit regarding thin and thick wrappers, but please move further usage related questions to the cython-users mailing list. Paul Moore, 29.08.2011 12:37: On 29 August 2011 10

Re: [Python-Dev] issue 6721 "Locks in python standard library should be sanitized on fork"

On Sat, Aug 27, 2011 at 2:59 AM, Ask Solem wrote: > > On 26 Aug 2011, at 16:53, Antoine Pitrou wrote: > > > > > Hi, > > > >> I think that "deprecating" the use of threads w/ multiprocessing - or > >> at least crippling it is the wrong answer. Multiprocessing needs the > >> helper threads it uses

Re: [Python-Dev] Should we move to replace re with regex?

On Aug 27, 2011, at 01:15 PM, Ben Finney wrote: >My question is directed more to M-A Lemburg's passage above, and its >implicit assumption that the user understand the changes between >“Unicode 2.0/3.0 semantics” and “Unicode 6 semantics”, and how their own >needs relate to those semantics. More

Re: [Python-Dev] Should we move to replace re with regex?

On Aug 26, 2011, at 05:25 PM, Dan Stromberg wrote: >from __future__ import is an established way of trying something for a while >to see if it's going to work. Actually, no. The documentation says: -snip snip- __future__ is a real module, and serves three purposes: * To avoid confusing

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

2011/8/29 Glyph Lefkowitz : > > On Aug 28, 2011, at 7:27 PM, Guido van Rossum wrote: > > In general, an existing library cannot be called > without access to its .h files -- there are probably struct and > constant definitions, platform-specific #ifdefs and #defines, and > other things in there tha

Re: [Python-Dev] Should we move to replace re with regex?

On Aug 27, 2011, at 07:11 PM, Martin v. Löwis wrote: >A PEP should IMO only cover end-user aspects of the new re module. >Code organization is typically not in the PEP. To give a specific >example: you mentioned that there is (near) code duplication >MRAB's module. As a reviewer, I would discuss w

Re: [Python-Dev] Software Transactional Memory for Python

Hi Charles-François, 2011/8/27 Charles-François Natali : > The problem is that many locks are actually acquired implicitely. > For example, `print` to a buffered stream will acquire the fileobject's mutex. Indeed. After looking more at the kind of locks used throughout the stdlib, I notice that

Re: [Python-Dev] Software Transactional Memory for Python

On Mon, Aug 29, 2011 at 5:20 AM, Antoine Pitrou wrote: > On Sun, 28 Aug 2011 09:43:33 -0700 > Guido van Rossum wrote: > > > > This sounds like a very interesting idea to pursue, even if it's late, > > and even if it's experimental, and even if it's possible to cause > > deadlocks (no news there)

[Python-Dev] SWIG (was Re: Ctypes and the stdlib)

On Mon, Aug 29, 2011 at 12:27 PM, Guido van Rossum wrote: > I wonder if for > this particular purpose SWIG isn't the better match. (If SWIG weren't > universally hated, even by its original author. :-) Hate is probably a strong word, but as the author of Swig, let me chime in here ;-). I thin

Re: [Python-Dev] LZMA compression support in 3.3

On Aug 27, 2011, at 10:36 PM, Nadeem Vawda wrote: >I talked to Antoine about this on IRC; he didn't seem to think a PEP would be >necessary. But a summary of the discussion on the tracker issue might still >be a useful thing to have, given how long it's gotten. I agree with Antoine - no PEP shoul

Re: [Python-Dev] Software Transactional Memory for Python

On Sun, 28 Aug 2011 09:43:33 -0700 Guido van Rossum wrote: > > This sounds like a very interesting idea to pursue, even if it's late, > and even if it's experimental, and even if it's possible to cause > deadlocks (no news there). I propose that we offer a C API in Python > 3.3 as well as an exte

Re: [Python-Dev] PEP 393 Summer of Code Project

On Mon, 29 Aug 2011 12:43:24 +0900 "Stephen J. Turnbull" wrote: > > Since when can s[0] represent a code point outside the BMP, for s a > Unicode string in a narrow build? > > Remember, the UCS-2/narrow vs. UCS-4/wide distinction is *not* about > what Python supports vs. the outside world. It's

Re: [Python-Dev] Should we move to replace re with regex?

On Sun, Aug 28, 2011 at 7:28 AM, Guido van Rossum wrote: > > Are you volunteering? (Even if you don't want to be the only > maintainer, it still sounds like you'd be a good co-maintainer of the > regex module.) > My name is listed in the experts index for 're' [0], and that should make me alread

Re: [Python-Dev] Ctypes and the stdlib

On 29 August 2011 10:39, Stefan Behnel wrote: > In the CPython backend, the header files are normally #included by the > generated C code, so they are used at C compilation time. > > Cython has its own view on the header files in separate declaration files > (.pxd). Basically looks like this: > >

Re: [Python-Dev] Ctypes and the stdlib

Guido van Rossum, 29.08.2011 04:27: On Sun, Aug 28, 2011 at 11:23 AM, Stefan Behnel wrote: Terry Reedy, 28.08.2011 06:58: I think it needs a SWIG-like companion script that can write at least first-pass ctypes code from the .h header files. Or maybe it could/should use header info at runtime (w

Re: [Python-Dev] Software Transactional Memory for Python

Hi Guido, On Sun, Aug 28, 2011 at 6:43 PM, Guido van Rossum wrote: > This sounds like a very interesting idea to pursue, even if it's late, > and even if it's experimental, and even if it's possible to cause > deadlocks (no news there). I propose that we offer a C API in Python > 3.3 as well as a

Re: [Python-Dev] PEP 393 review

Le 28/08/2011 23:06, "Martin v. Löwis" a écrit : Am 28.08.2011 22:01, schrieb Antoine Pitrou: - the iobench results are between 2% acceleration (seek operations), 16% slowdown for small-sized reads (4.31MB/s vs. 5.22 MB/s) and 37% for large sized reads (154 MB/s vs. 235 MB/s). The speed

Re: [Python-Dev] PEP 393 review

Le 29/08/2011 11:03, Dirkjan Ochtman a écrit : On Sun, Aug 28, 2011 at 21:47, "Martin v. Löwis" wrote: result strings. In PEP 393, a buffer must be scanned for the highest code point, which means that each byte must be inspected twice (a second time when the copying occurs). This may be

Re: [Python-Dev] PEP 393 review

On Sun, Aug 28, 2011 at 21:47, "Martin v. Löwis" wrote: >  result strings. In PEP 393, a buffer must be scanned for the >  highest code point, which means that each byte must be inspected >  twice (a second time when the copying occurs). This may be a silly question: are there things in place to

Re: [Python-Dev] Ctypes and the stdlib (was Re: LZMA compression support in 3.3)

Guido van Rossum wrote: > On Sun, Aug 28, 2011 at 11:23 AM, Stefan Behnel wrote: >> Hi, >> >> sorry for hooking in here with my usual Cython bias and promotion. When the >> question comes up what a good FFI for Python should look like, it's an >> obvious reaction from my part to throw Cython into