I just want to talk about it - for now.
python-ideas is a better place to just talk than python-dev.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Dan Stromberg, 27.08.2011 21:58:
On Sat, Aug 27, 2011 at 9:04 AM, Nick Coghlan wrote:
On Sun, Aug 28, 2011 at 1:58 AM, Nadeem Vawda wrote:
On Sat, Aug 27, 2011 at 5:52 PM, Nick Coghlan wrote:
It's acceptable for the Python version to use ctypes in the case of
wrapping an existing library, but
On Sun, Aug 28, 2011 at 2:28 PM, Guido van Rossum gu...@python.org wrote:
On Sat, Aug 27, 2011 at 8:59 PM, Ezio Melotti ezio.melo...@gmail.com 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);
On Sun, Aug 28, 2011 at 6:58 AM, Terry Reedy tjre...@udel.edu 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
On Sat, Aug 27, 2011 at 6:08 AM, Armin Rigo ar...@tunes.org wrote:
Hi Nick,
On Sat, Aug 27, 2011 at 2:40 PM, Nick Coghlan ncogh...@gmail.com 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
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
On Sat, Aug 27, 2011 at 10:36 PM, Dan Stromberg drsali...@gmail.com wrote:
On Sat, Aug 27, 2011 at 8:57 PM, Guido van Rossum gu...@python.org wrote:
On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg drsali...@gmail.com
wrote:
IMO, we really, really need some common way of accessing C libraries
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:
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
On Sun, 28 Aug 2011 20:13:11 +0200
martin.v.loewis python-check...@python.org 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
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/
I now
- 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 ASCII
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 decoder; I
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 (154 MB/s vs.
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 decoder; I
Guido van Rossum wrote:
On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg drsali...@gmail.com 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
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 O(1)
On Sun, Aug 28, 2011 at 11:23 AM, Stefan Behnel stefan...@behnel.de 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.
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 Mon, Aug 29, 2011 at 12:27 PM, Guido van Rossum gu...@python.org 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
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-16, an
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 calling
22 matches
Mail list logo
