Martin v. Löwis, 08.10.2011 16:54:
In benchmarking PEP 393, I noticed that many UTF-8 decode
calls originate from C code with static strings, in particular
PyObject_CallMethod. Many of such calls already have been optimized
to cache a string object, however, PyObject_CallMethod remains
Greg Ewing, 02.09.2011 02:36:
Guido van Rossum wrote:
But in a word like coëxistentie (coexistence) the o
and e do not form the oe-sound, and to emphasize this to Dutch readers
(who believe their spelling is very logical :-), the official spelling
puts the umlaut on the e.
Sometimes this is
stefan brunthaler, 02.09.2011 06:37:
as promised, I created a publicly available preview of an
implementation with my optimizations, which is available under the
following location:
https://bitbucket.org/py3_pio/preview/wiki/Home
I followed Nick's advice and added some valuable advice and
stefan brunthaler, 02.09.2011 17:55:
4) Regarding inlined object references, I would expect that it's much more
worthwhile to speed up LOAD_GLOBAL and LOAD_NAME than LOAD_CONST. I guess
that this would be best helped by watching the module dict and the builtin
dict internally and invalidating
Maciej Fijalkowski, 02.09.2011 20:42:
For a comparative real world benchmark I tested Martin von Loewis'
django port (there are not that many meaningful Python 3 real world
benchmarks) and got a speedup of 1.3 (without IIS). This is reasonably
well, US got a speedup of 1.35 on this benchmark. I
Guido van Rossum, 01.09.2011 18:31:
On Thu, Sep 1, 2011 at 9:03 AM, Antoine Pitrou wrote:
Le jeudi 01 septembre 2011 à 08:45 -0700, Guido van Rossum a écrit :
This is definitely thought of as a separate
mark added to the e; ë is not a new letter. I have a feeling it's the
same way for the
Antoine Pitrou, 01.09.2011 18:46:
AFAIR, road signs also keep the accents, but I'm no driver
Right, I noticed that, too. That's certainly not uncommon. I think it's
mostly because of local pride (after all, the road signs are all that many
drivers ever see of a city), but sometimes also
Dan Stromberg, 01.09.2011 19:56:
On Tue, Aug 30, 2011 at 10:05 AM, Guido van Rossum wrote:
The problem lies with the PyPy backend -- there it generates ctypes
code, which means that the signature you declare to Cython/Pyrex must
match the *linker* level API, not the C compiler level API.
stefan brunthaler, 30.08.2011 22:41:
Ok, there there's something else you haven't told us. Are you saying
that the original (old) bytecode is still used (and hence written to
and read from .pyc files)?
Short answer: yes.
Long answer: I added an invocation counter to the code object and keep
Nick Coghlan, 30.08.2011 02:00:
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
Martin v. Löwis, 30.08.2011 10:46:
You might be reading more into that statement than I meant.
You have to supply Pyrex/Cython versions of the C declarations,
either hand-written or generated by a tool. But you write them
based on the advertised C API -- you don't have to manually
expand macros,
Guido van Rossum, 30.08.2011 19:05:
On Tue, Aug 30, 2011 at 9:49 AM, Martin v. Löwis wrote:
I can understand how that works when building a CPython extension.
But what about creating Jython/IronPython modules with Cython?
At what point get the header files considered there?
I had written a
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
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:
# file mymath.pxd
cdef
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
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
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
Martin v. Löwis, 26.08.2011 11:29:
You seem to assume it is ok for Jython/IronPython to provide indexing in
O(n). It is not.
I think we can leave this discussion aside. Jython and IronPython have
their own platform specific constraints to which they need to adapt their
implementation. For a
Antoine Pitrou, 26.08.2011 12:51:
Why would PEP 393 apply to other implementations than CPython?
Not the PEP itself, just the implications of the result.
The question was whether the language specification in a post PEP-393 can
(and if so, should) be changed into requiring unicode objects to
Stefan Behnel, 25.08.2011 23:30:
Sadly, a quick look at a couple of recent commits in the pep-393 branch
suggested that it is not even always obvious to you as the authors which
macros can be called safely and which cannot. I immediately spotted a bug
in one of the updated core functions
Guido van Rossum, 26.08.2011 19:02:
On Fri, Aug 26, 2011 at 3:29 AM, Stefan Behnel wrote:
Besides, what if these implementations provided indexing in, say, O(log N)
instead of O(1) or O(N), e.g. by building a tree index into each string? You
could have an index that simply marks runs
Martin v. Löwis, 26.08.2011 18:56:
I agree with your observation that somebody should be done about error
handling, and will update the PEP shortly. I propose that
PyUnicode_Ready should be explicitly called on input where raising an
exception is feasible. In contexts where it is not feasible
Stefan Behnel, 26.08.2011 20:28:
Martin v. Löwis, 26.08.2011 18:56:
I agree with your observation that somebody should be done about error
handling, and will update the PEP shortly. I propose that
PyUnicode_Ready should be explicitly called on input where raising an
exception is feasible
Martin v. Löwis, 24.08.2011 20:15:
- issues to be considered (unclarities, bugs, limitations, ...)
A problem of the current implementation is the need for calling
PyUnicode_(FAST_)READY(), and the fact that it can fail (e.g. due to
insufficient memory). Basically, this means that even
Stefan Behnel, 25.08.2011 20:47:
Martin v. Löwis, 24.08.2011 20:15:
- issues to be considered (unclarities, bugs, limitations, ...)
A problem of the current implementation is the need for calling
PyUnicode_(FAST_)READY(), and the fact that it can fail (e.g. due to
insufficient memory
Isaac Morland, 26.08.2011 04:28:
On Thu, 25 Aug 2011, Guido van Rossum wrote:
I'm not sure what should happen with UTF-8 when it (in flagrant
violation of the standard, I presume) contains two separately-encoded
surrogates forming a valid surrogate pair; probably whatever the UTF-8
codec does
Stefan Behnel, 25.08.2011 23:30:
Stefan Behnel, 25.08.2011 20:47:
Martin v. Löwis, 24.08.2011 20:15:
- issues to be considered (unclarities, bugs, limitations, ...)
A problem of the current implementation is the need for calling
PyUnicode_(FAST_)READY(), and the fact that it can fail (e.g
Torsten Becker, 24.08.2011 04:41:
Also, common, now simple, checks for unicode-str == NULL would look
more ambiguous with a union (unicode-str.latin1 == NULL).
You could just add yet another field any, i.e.
union {
unsigned char* latin1;
Py_UCS2* ucs2;
Py_UCS4* ucs4;
Nick Coghlan, 24.08.2011 15:06:
On Wed, Aug 24, 2011 at 10:46 AM, Terry Reedy wrote:
In utf16.py, attached to http://bugs.python.org/issue12729
I propose for consideration a prototype of different solution to the 'mostly
BMP chars, few non-BMP chars' case. Rather than expand every character
Victor Stinner, 25.08.2011 00:29:
With this PEP, the unicode object overhead grows to 10 pointer-sized
words (including PyObject_HEAD), that's 80 bytes on a 64-bit machine.
Does it have any adverse effects?
For pure ASCII, it might be possible to use a shorter struct:
typedef struct {
Martin v. Löwis, 24.08.2011 20:15:
Guido has agreed to eventually pronounce on PEP 393. Before that can
happen, I'd like to collect feedback on it. There have been a number
of voice supporting the PEP in principle
Absolutely.
- conditions you would like to pose on the implementation before
Torsten Becker, 22.08.2011 20:58:
I have implemented an initial version of PEP 393 -- Flexible String
Representation as part of my Google Summer of Code project. My patch
is hosted as a repository on bitbucket [1] and I created a related
issue on the bug tracker [2]. I posted documentation for
Martin v. Löwis, 23.08.2011 10:55:
- “The UTF-8 decoding fast path for ASCII only characters was removed
and replaced with a memcpy if the entire string is ASCII.”
The fast path would still be useful for mostly-ASCII strings, which
are extremely common (unless UTF-8 has become a
Torsten Becker, 22.08.2011 20:58:
I have implemented an initial version of PEP 393 -- Flexible String
Representation as part of my Google Summer of Code project. My patch
is hosted as a repository on bitbucket [1] and I created a related
issue on the bug tracker [2]. I posted documentation for
Martin v. Löwis, 23.08.2011 15:17:
Has this been considered before? Was there a reason to decide against it?
I think we simply didn't consider it. An early version of the PEP used
the lower bits for the pointer to encode the kind, in which case it even
stopped being a pointer. Modules are not
Antoine Pitrou, 23.08.2011 16:08:
On Tue, 23 Aug 2011 16:02:54 +0200
Stefan Behnel wrote:
Martin v. Löwis, 23.08.2011 15:17:
Has this been considered before? Was there a reason to decide against it?
I think we simply didn't consider it. An early version of the PEP used
the lower bits
Nick Coghlan, 15.08.2011 14:35:
On Mon, Aug 15, 2011 at 10:17 PM, Antoine Pitrousolip...@pitrou.net wrote:
AFAICT, often with True and False:
x = (some condition) ? Py_True : Py_False;
Py_INCREF(x);
return x;
And that's an idiom that works better with a Py_RETURN macro than it
Guido van Rossum, 12.08.2011 23:38:
On Fri, Aug 12, 2011 at 12:57 PM, Rene Nejsum wrote:
I think I understand the background and need for GIL. Without it Python
programs would have been cluttered with lock/synchronized statements and
C-extensions would be harder to write.
No, sorry, the first
Марк Коренберг, 09.08.2011 11:31:
In a summary: Please say clearly why, actually, my variant is not
still implemented.
This question comes up on the different Python lists every once in a while.
In general, if you want something to be implemented in a specific way, feel
free to provide the
Joao S. O. Bueno, 29.07.2011 13:22:
On Fri, Jul 29, 2011 at 1:37 AM, Stefan Behnel wrote:
Brett Cannon, 28.07.2011 23:49:
On Thu, Jul 28, 2011 at 11:25, Matt wrote:
- What policies are in place for keeping parity with other HTML
parsers (such as those in web browsers)?
There aren't any
Brett Cannon, 28.07.2011 23:49:
On Thu, Jul 28, 2011 at 11:25, Matt wrote:
- What policies are in place for keeping parity with other HTML
parsers (such as those in web browsers)?
There aren't any beyond it would be nice.
[...]
It's more of an issue of someone caring enough to do the coding
Georg Brandl, 06.07.2011 07:35:
Well, it was stated that even non-joking use of such words can offend
(the example given was your argument is blind to (these facts)).
I consider use in jokes to be more serious, since it's careless use.
Sorry if I overreacted here.
There's a common saying that
Georg Brandl, 06.07.2011 09:08:
Am 06.07.2011 08:51, schrieb Stefan Behnel:
Georg Brandl, 06.07.2011 07:35:
Well, it was stated that even non-joking use of such words can offend
(the example given was your argument is blind to (these facts)).
I consider use in jokes to be more serious, since
Victor Stinner, 28.06.2011 15:43:
In Python 2, open() opens the file in binary mode (e.g. file.readline()
returns a byte string). codecs.open() opens the file in binary mode by
default, you have to specify an encoding name to open it in text mode.
In Python 3, open() opens the file in text mode
Tom Whittock, 27.06.2011 12:48:
I'm writing a module to proxy C++ objects into Python for a large C++
application. There are hundreds of thousands of C++ objects, some of
which are temporary while others are very long lived.
Currently every time one of these objects is accessed from Python, a
Maciej Fijalkowski, 24.05.2011 13:31:
CPython was not designed for CPU cache usage as far as I'm aware.
That's a pretty bold statement to make on this list. Even if it wasn't
originally designed for (efficient?) CPU cache usage, it's certainly been
around for long enough to have received
Antoine Pitrou, 24.05.2011 14:32:
On Tue, 24 May 2011 14:05:26 +0200Stefan Behnel wrote:
I doubt that efficient CPU cache usage was a major design goal of PyPy
right from the start. IMHO, the project has changed its objectives way too
many times to claim something like that, especially at the
Hi,
since May 19, I get the exception below in the latest py3k site.py when
trying to run a distutils build with it (building Cython). The changelog
since the previous (working) CPython build is here:
https://sage.math.washington.edu:8091/hudson/job/py3k-hg/374/
The failing build is here:
Greg Ewing, 19.05.2011 00:02:
Georg Brandl wrote:
We do have
bytes.fromhex('deadbeef')
But again, there is a run-time overhead to this.
Well, yes, but it's negligible if you assign it to a suitable variable first.
Stefan
___
Python-Dev mailing
Xavier Morel, 19.05.2011 09:41:
On 2011-05-19, at 07:28 , Georg Brandl wrote:
On 19.05.2011 00:39, Greg Ewing wrote:
If someone sees that
some_var[3] == b'd'
is true, and that
some_var[3] == 100
is also true, they might expect to be able to do things
like
n = b'd' + 1
and get
Łukasz Langa, 19.05.2011 11:25:
Wiadomość napisana przez Stefan Behnel w dniu 2011-05-19, o godz. 10:37:
But why wouldn't they expect `b'de' + 1` to work as well in this case? If a
1-byte bytes is equivalent to an integer, why not an arbitrary one as well?
The result of this must obviously
[forwarded to the python-ideas list]
Stefan
___
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
Eli Bendersky, 09.05.2011 14:56:
It's a known Python gotcha (*) that the following code:
x = 5
def foo():
print(x)
x = 1
print(x)
foo()
Will throw:
UnboundLocalError: local variable 'x' referenced before assignment
On the usage of 'x' in the *first* print. Recently,
Greg Ewing, 07.05.2011 02:26:
Stefan Behnel wrote:
After all, the described crash case indicates that the Document
destructor was called before all of the Element destructors had been
called, although all Elements reference their Document, but the Document
does not refer to any of the Elements
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1: You can't have meaningful destructors, because when destruction
happens is
Michael Foord, 06.05.2011 19:06:
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail/mercurial-devel/2011-May/031055.html
From that note:
1
Mark Shannon, 06.05.2011 20:45:
Stefan Behnel wrote:
Michael Foord, 06.05.2011 19:06:
On 06/05/2011 17:51, Stefan Behnel wrote:
Mark Shannon, 06.05.2011 18:33:
s...@pobox.com wrote:
Antoine Since we're sharing links, here's Matt Mackall's take:
Antoine
http://www.selenic.com/pipermail
DasIch, 28.04.2011 20:55:
the CPython
benchmarks have an extensive set of microbenchmarks in the pybench
package
Try not to care too much about pybench. There is some value in it, but some
of its microbenchmarks are also tied to CPython's interpreter behaviour.
For example, the benchmarks
M.-A. Lemburg, 28.04.2011 22:23:
Stefan Behnel wrote:
DasIch, 28.04.2011 20:55:
the CPython
benchmarks have an extensive set of microbenchmarks in the pybench
package
Try not to care too much about pybench. There is some value in it, but
some of its microbenchmarks are also tied to CPython's
Nick Coghlan, 19.04.2011 10:57:
On Tue, Apr 19, 2011 at 3:06 PM, Stefan Behnel wrote:
I think this social problem of the PEP can only be solved if the CPython
project stops doing the major share of the stdlib maintenance, thus freeing
its own developer capacities to focus on CPython related
Maciej Fijalkowski, 18.04.2011 19:11:
On Mon, Apr 18, 2011 at 6:32 PM, Éric Araujo wrote:
We try very hard to optimize for usual python idioms. They're very
often much better than specific cpython hacks. Unless you mean things
like rebiding a global into default a pythonic idiom. We had to
Raymond Hettinger, 18.04.2011 19:26:
On Apr 18, 2011, at 10:11 AM, Maciej Fijalkowski wrote:
* we usually target CPython version that's already frozen, which is
pretty inconvinient to post this changes back. Example would be a
socket module where it has changed enough in 3.x that 2.7 changes
R. David Murray, 18.04.2011 14:30:
On Mon, 18 Apr 2011 09:36:20 +0100, Paul Moore wrote:
On 18 April 2011 08:05, Maciej Fijalkowski wrote:
On Sun, Apr 17, 2011 at 4:19 AM, Raymond Hettinger wrote:
The PEP seems to be predicated on a notion that anything written in C is
bad and that all
Brett Cannon, 05.04.2011 01:46:
At both the VM and language summits at PyCon this year, the issue of
compatibility of the stdlib amongst the various VMs came up. Two issues came
about in regards to modules that use C code. One is that code that comes in
only as C code sucks for all other VMs
Matt Billenstein, 17.04.2011 00:47:
On Sat, Apr 16, 2011 at 01:30:13PM +0200, Antoine Pitrou wrote:
On Sat, 16 Apr 2011 00:41:03 +
Matt Billenstein wrote:
Slightly less crude benchmark showing simplejson is quite a bit faster:
http://pastebin.com/g1WqUPwm
250ms vs 5.5s encoding and
Antoine Pitrou, 16.04.2011 19:27:
On Sat, 16 Apr 2011 16:47:49 + (UTC)
Vinay Sajip wrote:
Bob made a comment in passing that simplejson (Python) is about as fast as
stdlib json (C extension), on 2.x.
I think Bob tested with an outdated version of the stdlib json module
(2.6 or 2.7,
Vinay Sajip, 17.04.2011 12:33:
Antoine Pitrou writes:
Feel free to share your numbers.
I've now got my fork working on Python 3.2 with speedups. According to a
non-scientific simple test:
Python 2.7
==
Python version: 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
[GCC 4.5.2]
11.21484375
Antoine Pitrou, 16.04.2011 16:19:
On Sat, 16 Apr 2011 09:50:25 + (UTC)
Vinay Sajip wrote:
If it is generally considered desirable to maintain some synchrony between
simplejson and stdlib json, then since Bob has stated that he no interest in
Python 3, it may be better to:
1. Convert the
Georg Brandl, 13.04.2011 08:54:
On 13.04.2011 02:07, Antoine Pitrou wrote:
On Tue, 12 Apr 2011 19:50:34 -0400
Tres Seaver wrote:
Trying to accelerate existing code which doesn't have the coverage is
insane: how can you know that the accelerator doesn't subtly change the
semantics without
Antoine Pitrou, 13.04.2011 02:07:
On Tue, 12 Apr 2011 19:50:34 -0400
Tres Seaver wrote:
Trying to accelerate existing code which doesn't have the coverage is
insane: how can you know that the accelerator doesn't subtly change the
semantics without tests?
Well, why do you think tests
Maciej Fijalkowski, 11.04.2011 11:39:
On Fri, Apr 8, 2011 at 11:22 AM, Stefan Behnelstefan...@behnel.de wrote:
Jesse Noller, 07.04.2011 22:28:
On Thu, Apr 7, 2011 at 3:54 PM, Anthony Scopatz wrote:
Hi Daniel,
Thanks for putting this together. I am a huge supporter of benchmarking
efforts.
Jesse Noller, 07.04.2011 22:28:
On Thu, Apr 7, 2011 at 3:54 PM, Anthony Scopatz wrote:
Hi Daniel,
Thanks for putting this together. I am a huge supporter of benchmarking
efforts. My brief comment is below.
On Wed, Apr 6, 2011 at 11:52 AM, DasIch wrote:
1. Definition of the benchmark suite.
Maciej Fijalkowski, 08.04.2011 11:41:
On Fri, Apr 8, 2011 at 11:22 AM, Stefan Behnelstefan...@behnel.de wrote:
Jesse Noller, 07.04.2011 22:28:
On Thu, Apr 7, 2011 at 3:54 PM, Anthony Scopatz wrote:
Hi Daniel,
Thanks for putting this together. I am a huge supporter of benchmarking
efforts.
Maciej Fijalkowski, 08.04.2011 13:37:
On Fri, Apr 8, 2011 at 12:18 PM, Stefan Behnel wrote:
So, once CPython is up and running in the benchmark test, adding Cython
should be as easy as copying the configuration, installing Cython and
adding
two lines to site.py.
can you provide a simple
James Y Knight, 06.04.2011 17:03:
On Apr 6, 2011, at 10:08 AM, Nick Coghlan wrote:
Argument handling is certainly a tricky one - getting positional only
arguments requires a bit of a hack in pure Python code (accepting
*args and unpacking the arguments manually), but it comes reasonably
Brett Cannon, 06.04.2011 19:40:
On Tue, Apr 5, 2011 at 05:01, Nick Coghlan wrote:
However, there actually *is* a significant semantic discrepancy in the
heapq case, which is that py_heapq is duck-typed, while c_heapq is
not:
TypeError: heap argument must be a list
That's true. I will re-word
Brett Cannon, 05.04.2011 01:46:
At both the VM and language summits at PyCon this year, the issue of
compatibility of the stdlib amongst the various VMs came up. Two issues came
about in regards to modules that use C code. One is that code that comes in
only as C code sucks for all other VMs
Steven D'Aprano, 22.03.2011 22:12:
anatoly techtonik wrote:
I didn't touch Python3 until PyCon, and my first user experience is
not really good. I've got a feeling that Python3 became more ugly,
because it doesn't allow me to think about the logic anymore, and
requires more low-level
[long post ahead, again]
Guido van Rossum, 21.03.2011 03:46:
Thanks for the clarifications. I now have a much better understanding
of what Cython is. But I'm not sold. For one, your attitude about
strict language compatibility worries me when it comes to the stdlib.
Not sure what you mean
Victor Stinner, 21.03.2011 15:21:
Le lundi 21 mars 2011 à 04:09 +0100, Martin v. Löwis a écrit :
Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
one outputting int; the other one outputting Py_ssize_t.
The former should have been removed in 3.0, but this was forgotten.
Still,
Victor Stinner, 21.03.2011 16:26:
Le lundi 21 mars 2011 à 15:35 +0100, Stefan Behnel a écrit :
Victor Stinner, 21.03.2011 15:21:
Le lundi 21 mars 2011 à 04:09 +0100, Martin v. Löwis a écrit :
Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
one outputting int; the other one
Stefan Behnel, 21.03.2011 11:58:
Guido van Rossum, 21.03.2011 03:46:
Have you tried replacing selected stdlib modules with their
Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g.
what about Enthought's Python distros?) Depending on how well that
goes I might warm up
Nick Coghlan, 12.03.2011 12:43:
I posted my rough notes and additional write-ups for Wednesday's VM
summit and Thursday's language summit:
http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html
Jesse Noller, 20.03.2011 12:32:
On Sun, Mar 20, 2011 at 7:19 AM, Stefan Behnel wrote:
It appears that there has been little mention of Cython at the summit,
despite of the speed of CPython being a major topic, according to the notes.
I can see several areas where Cython could help in speeding
Antoine Pitrou, 20.03.2011 12:40:
On Sun, 20 Mar 2011 07:32:34 -0400 Jesse Noller wrote:
The reason why there was no mention is probably because no one
intimately familiar with Cython was there, and if they were - it was
not brought up. If Cython supports PyPy - and Jython, and IronPython,
Jesse Noller, 20.03.2011 13:51:
...snip
IMHO, taking modules that currently only have a C implementation due to
performance constraints and rewriting them in Cython is a much more
worthwhile thing to do than adding an alternative pure Python implementation
that other Python runtimes wouldn't
Antoine Pitrou, 20.03.2011 15:51:
On Sun, 20 Mar 2011 14:39:20 +0100, Stefan Behnel wrote:
If anyone knows about a good benchmark for a currently pure Python standard
library module, preferably a smaller, self-contained one that's somewhat
computationally intensive, I'd be happy to hear about
[warning, long post ahead]
Guido van Rossum, 20.03.2011 17:17:
Hi Stefan,
Hi!
I'm glad to see Cython picking up steam and trying to compete with
CPython, PyPy, and possibly others.
We do, although our main focus is much more on targeted manual optimisation
rather than whole applications.
Lennart Regebro, 16.03.2011 00:04:
On Tue, Mar 15, 2011 at 18:56, Nick Coghlan wrote:
why not just consider this another
instance of the 2.x/3.x incompatibility? That's what it is after all.
Apparently not, as the code already ran under Python 3.1.
Personally, I would expect that breaking
Eric Smith, 16.03.2011 04:12:
On 3/15/2011 10:58 PM, Lennart Regebro wrote:
On Tue, Mar 15, 2011 at 22:42, Guido van Rossum wrote:
Fortunately there may not be any more such cases since no new major
versions of Python 2 will be released. So I'm not sure what an update
of PEP 5 will buy us.
Armin Ronacher, 16.03.2011 16:57:
On 3/16/11 3:48 AM, Antoine Pitrou wrote:
I may be mistaken, but you seem to conflate two things: encoding of
file names, and encoding of file contents. I guess that virtualenv
chokes on the file contents, but most of your argument seems related to
encoding of
James Y Knight, 10.03.2011 06:52:
But you're also left with not being able to 'import hashlib'. While python has
fallback code, those modules (_md5, _sha, _sha256, _sha512) aren't built if
openssl was found at build time. So you can't just select at runtime that you
didn't want to use
Martin v. Löwis, 08.03.2011 23:47:
I think everything here is as it should be. People who really cared
about forwards compatibility could have known, but factually, most
people don't care enough. Those then learn for the first time that
some feature was deprecated after it is actually removed.
John Arbash Meinel, 07.03.2011 09:36:
On 3/7/2011 3:56 AM, Terry Reedy wrote:
On 3/6/2011 6:09 PM, Barry Scott wrote:
I see that PyCObject_AsVoidPtr has been removed from python 3.2.
The 3.2 docs do not seem to explain this has happened and what
to replace it with.
I searched the 3.2 docs and
Reid Kleckner, 22.02.2011 21:21:
On Tue, Feb 22, 2011 at 2:09 PM, Eric Smith wrote:
Also changing it now would be a giant hassle, leading to so-called const
poisoning where many, many APIs need to be changed before everything would
again work.
The poisoning will not break any users of the
Georg Brandl, 19.02.2011 21:53:
BTW, I haven't seen an issue yet.
http://bugs.python.org/issue11254
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Hi,
sorry for asking here instead of filing a bug, but given that 3.2 final is
pretty close, I wanted to make sure this gets considered.
A Cython user noticed that the installation (setup.py install or bdist)
puts several .pyc files into the installed source directory, instead of
moving
Mark Shannon, 10.02.2011 11:16:
Of course 743 functions is about 700 too many,
Sorry, but that's so wrong, it's just being mean.
What do you expect from a platform that has grown for more than 20 years?
And which has been the only (real) Python implementation for most of that time.
I'm
Jurjen N.E. Bos, 31.01.2011 10:17:
I single stepped a simple loop in Python to see where the efficiency
bottlenecks are.
What version of CPython did you try that with? The latest py3k branch?
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
Martin v. Löwis, 29.01.2011 10:05:
None of the functions in this PEP become part of the stable ABI.
I think that's only part of the truth. This PEP can potentially have an
impact on the stable ABI in the sense that the build-time size of
Py_UNICODE may no longer be important for extensions
401 - 500 of 622 matches
Mail list logo
