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 that affect the linker-level callin
Raymond Hettinger writes:
> The naming convention for codecs is that the UTF prefix is used for
> lossless encodings that cover the entire range of Unicode.
Sure. The operative word here is "codec", not "str", though.
> "The first amendment to the original edition of the UCS defined
> UTF-1
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. :-)
SWIG is nice when you control the C/C++ side of the API as well and
can tweak it to be SWIG-fri
Guido van Rossum writes:
> I don't think anyone else has that impression. Please cite chapter and
> verse if you really think this is important. IIUC, UCS-2 does not
> allow surrogate pairs,
In the original definition of UCS-2 in draft ISO 10646 (1990),
everything in the BMP except for 0x
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 the game.
>
> Terry Reedy, 28.0
Paul Moore writes:
> IronPython and Jython can retain UTF-16 as their native form if that
> makes interop cleaner, but in doing so they need to ensure that basic
> operations like indexing and len work in terms of code points, not
> code units, if they are to conform.
[...]
> They lose the
Guido van Rossum wrote:
On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg wrote:
IMO, we really, really need some common way of accessing C libraries that
works for all major Python variants.
We have one. It's called writing an extension module.
I think Dan means some way of doing this withou
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
>> difference is probably in the UTF-8 dec
Le dimanche 28 août 2011 à 22:23 +0200, "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 (
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
>> difference is probably in the UTF-8 dec
> - 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
> difference is probably in the UTF-8 decoder; I have already
> restored the "runs of ASCI
> I would say no more than a 15% slowdown on each of the following
> benchmarks:
>
> - stringbench.py -u
> (http://svn.python.org/view/sandbox/trunk/stringbench/)
> - iobench.py -t
> (in Tools/iobench/)
> - the json_dump, json_load and regex_v8 tests from
> http://hg.python.org/benchmarks/
On Sun, 28 Aug 2011 20:13:11 +0200
martin.v.loewis wrote:
>
> +Performance
> +---
> +
> +Performance of this patch must be considered for both memory
> +consumption and runtime efficiency. For memory consumption, the
> +expectation is that applications that have many large strings will s
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 the game.
Terry Reedy, 28.08.2011 06:58:
Dan, I once had the more or less the same opinion
Am 26.08.2011 16:56, schrieb Guido van Rossum:
> Also, please add the table (and the reasoning that led to it) to the PEP.
Done!
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
On Sat, Aug 27, 2011 at 10:36 PM, Dan Stromberg wrote:
>
> On Sat, Aug 27, 2011 at 8:57 PM, Guido van Rossum wrote:
>>
>> On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg
>> wrote:
>> > IMO, we really, really need some common way of accessing C libraries
>> > that
>> > works for all major Python v
Someone asked me off-line what I wanted besides talk. Here's the list
I came up with:
You could try for instance volunteer to do a thorough code review of
the regex code, trying to think of ways to break it (e.g. bad syntax
or extreme use of nesting etc., or bad data). Or you could volunteer
to ma
On Sat, Aug 27, 2011 at 6:08 AM, Armin Rigo wrote:
> Hi Nick,
>
> On Sat, Aug 27, 2011 at 2:40 PM, Nick Coghlan wrote:
>> 1. How does the patch interact with C code that explicitly releases
>> the GIL? (e.g. IO commands inside a "with atomic:" block)
>
> As implemented, any code in a "with atomic
On Sun, Aug 28, 2011 at 6:58 AM, Terry Reedy wrote:
> 2) It is not trivial to use it correctly. 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 (with the
> .h bundled with
On Sun, Aug 28, 2011 at 2:28 PM, Guido van Rossum wrote:
> On Sat, Aug 27, 2011 at 8:59 PM, Ezio Melotti wrote:
>> I think it would be good to:
>> 1) have some document that explains the general design and main (internal)
>> functions of the module (e.g. a PEP);
>
> I don't think that such a do
20 matches
Mail list logo
