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
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().
You
On Tue, Aug 30, 2011 at 08:57, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
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
On Tue, Aug 30, 2011 at 4:22 PM, Eli Bendersky eli...@gmail.com wrote:
On Tue, Aug 30, 2011 at 08:57, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Following this argument to the extreme, the bytecode evaluation code of
CPython can be simplified quite a bit. Lose 2x performance but gain a lot
This looks very nice. Is 3.3 a wide build? (how about a narrow build?)
It's a wide build. For reference, I also attach 64-bit narrow build
results, and 32-bit results (wide, narrow, and PEP 393). Savings are
much smaller in narrow builds (larger on 32-bit systems than on
64-bit systems).
(is
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
Nick Coghlan wrote:
On Tue, Aug 30, 2011 at 7:14 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 29 Aug 2011 11:33:14 -0700
stefan brunthaler s.bruntha...@uci.edu wrote:
* The optimized dispatch routine has a changed instruction format
(word-sized instead of bytecodes) that allows for
Martin v. Löwis wrote:
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,
Although any such patch should discuss how it compares with Cesare's
work on wpython.
Personally, I *like* CPython fitting into the simple-and-portable
niche in the Python interpreter space.
Changing the bytecode width wouldn't make the interpreter more complex.
No, but I think Stefan is
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, work out the low-level layout
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,
On Sat, Aug 27, 2011 at 2:35 AM, Brett Cannon br...@python.org wrote:
On Tue, Aug 23, 2011 at 19:42, Nick Coghlan ncogh...@gmail.com wrote:
Unless I hear any objections, I plan to adjust the current PEP
statuses as follows some time this weekend:
Move from Accepted to Finished:
389
By the way, I don't know if you're working on it, but StringIO seems a
bit broken right now. test_memoryio crashes here:
test_newline_cr (test.test_memoryio.CStringIOTest) ... Fatal Python error:
Segmentation fault
Current thread 0x7f3f6353b700:
File
On Tue, 30 Aug 2011 13:29:59 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Anecdotal, non-reproducible performance figures are *not* the way to
go about serious optimisation efforts.
What about anecdotal *and* reproducible performance figures? :)
I may be half-joking, but we already have a set
On Tue, Aug 30, 2011 at 9:38 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 30 Aug 2011 13:29:59 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Anecdotal, non-reproducible performance figures are *not* the way to
go about serious optimisation efforts.
What about anecdotal *and*
Meador Inge meadori at gmail.com writes:
1. http://bugs.python.org/issue9041
I raised a question about this patch (in the issue tracker).
2. http://bugs.python.org/issue9651
3. http://bugs.python.org/issue11241
I presume, since Amaury has commit rights, that he could commit these.
I also have some patches sitting on the tracker for some time:
http://bugs.python.org/issue12764
http://bugs.python.org/issue11835
http://bugs.python.org/issue12528 which also fixes
http://bugs.python.org/issue6069 and http://bugs.python.org/issue11920
http://bugs.python.org/issue6068 which also
On Tue, 30 Aug 2011 16:22:14 +0200
eric.araujo python-check...@python.org wrote:
http://hg.python.org/cpython/rev/af0bcccb935b
changeset: 72127:af0bcccb935b
user:Éric Araujo mer...@netwok.org
date:Tue Aug 30 00:55:02 2011 +0200
summary:
Remove display options (--name,
Changing the bytecode width wouldn't make the interpreter more complex.
No, but I think Stefan is proposing to add a *second* byte code format,
in addition to the one that remains there. That would certainly be an
increase in complexity.
Yes, indeed I have a more straightforward instruction
On Tue, Aug 30, 2011 at 07:30:01PM +0400, Oleg Broytman wrote:
PyPI went down
More information: ports 80 and 443 are open, the servers performs SSL
handshake but timeouts on HTTP requests (with or without SSL).
Oleg.
--
Oleg Broytmanhttp://phdru.name/
It is back up. I am very sorry for the fuss.
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
Hi,
Le 30/08/2011 17:20, Antoine Pitrou a écrit :
On Tue, 30 Aug 2011 16:22:14 +0200
eric.araujo python-check...@python.org wrote:
As a side effect, the Distribution class no longer accepts a 'url' key
in its *attrs* argument: it has to be 'home-page' to be recognized as a
valid metadata
Hello!
I released the first package of two and PyPI went down while I was
preparing to release the second. I hope it wasn't me?
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
Stefan, have you shared a pointer to your code yet? Is it open source?
It sounds like people are definitely interested and it would make
sense to let them experiment with your code and review it.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev
I released the first package of two and PyPI went down while I was
preparing to release the second. I hope it wasn't me?
A few minutes ago, it was responding very slowly, and I found out that
Postgres consumes all time. I haven't put energy into investigating what
was causing this -
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 bit about this here:
http://thread.gmane.org/gmane.comp.python.devel/126340/focus=126419
On Tue, Aug 30, 2011 at 18:46, Martin v. Löwis mar...@v.loewis.de wrote:
I released the first package of two and PyPI went down while I was
preparing to release the second. I hope it wasn't me?
A few minutes ago, it was responding very slowly, and I found out that
Postgres consumes all
On Tue, Aug 30, 2011 at 9:49 AM, Martin v. Löwis mar...@v.loewis.de 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 bit about this
Antoine Pitrou writes:
On Mon, 29 Aug 2011 12:43:24 +0900
Stephen J. Turnbull step...@xemacs.org 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
Looks like the issue keeps popping up. It was slow to respond earlier
today, and I keep getting complaints about it (including now.)
Somebody is mirroring the site with wget. I have null-routed them.
Regards,
Martin
___
Python-Dev mailing list
The problem with a narrow build (whether for space efficiency in
CPython or for platform compatibility in Jython and IronPython) is not
that we have no UTF-16 codecs. It's that array ops aren't UTF-16
conformant.
Sorry, what is a conformant UTF-16 array op?
Thanks
Antoine.
On Tue, Aug 30, 2011 at 09:42, Guido van Rossum gu...@python.org wrote:
Stefan, have you shared a pointer to your code yet? Is it open source?
I have no shared code repository, but could create one (is there any
pydev preferred provider?). I have all the copyrights on the code, and
I would like
On Tue, 30 Aug 2011 08:27:13 -0700
stefan brunthaler ste...@brunthaler.net wrote:
Changing the bytecode width wouldn't make the interpreter more complex.
No, but I think Stefan is proposing to add a *second* byte code format,
in addition to the one that remains there. That would certainly
Do you really need it to match a machine word? Or is, say, a 16-bit
format sufficient.
Hm, technically no, but practically it makes more sense, as (at least
for x86 architectures) having opargs and opcodes in half-words can be
efficiently expressed in assembly. On 64bit architectures, I could
On Tue, Aug 30, 2011 at 10:50 AM, stefan brunthaler
ste...@brunthaler.net wrote:
Do you really need it to match a machine word? Or is, say, a 16-bit
format sufficient.
Hm, technically no, but practically it makes more sense, as (at least
for x86 architectures) having opargs and opcodes in
On 8/30/2011 1:05 PM, Guido van Rossum wrote:
I see. So there is potential for error there.
To elaborate, with CPython it looks pretty solid, at least for
functions and constants (does it do structs?). You must manually
declare the name and signature of a function, and Pyrex/Cython emits C
Do I sense that the bytecode format is no longer platform-independent?
That will need a bit of discussion. I bet there are some things around
that depend on that.
Hm, I haven't really thought about that in detail and for longer, I
ran it on PowerPC 970 and Intel Atom i7 without problems (the
On Tue, Aug 30, 2011 at 11:23 AM, stefan brunthaler
ste...@brunthaler.net wrote:
Do I sense that the bytecode format is no longer platform-independent?
That will need a bit of discussion. I bet there are some things around
that depend on that.
Hm, I haven't really thought about that in detail
Um, I'm sorry, but that reply sounds incredibly naive, like you're not
really sure what the on-disk format for .pyc files is or why it would
matter. You're not even answering the question, except indirectly --
it seems that you've never even thought about the possibility of
generating a .pyc
On 8/30/2011 1:23 PM, stefan brunthaler wrote:
(I just wanted to know if there is substantial interest so that
it eventually pays off to find and fix the remaining bugs)
It is the nature of our development process that there usually can be no
guarantee of acceptance of future code. The
On Tue, Aug 30, 2011 at 11:34 AM, stefan brunthaler
ste...@brunthaler.net wrote:
Um, I'm sorry, but that reply sounds incredibly naive, like you're not
really sure what the on-disk format for .pyc files is or why it would
matter. You're not even answering the question, except indirectly --
it
Am 30.08.2011 20:34, schrieb stefan brunthaler:
Um, I'm sorry, but that reply sounds incredibly naive, like you're not
really sure what the on-disk format for .pyc files is or why it would
matter. You're not even answering the question, except indirectly --
it seems that you've never even
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
Re-hi,
2011/8/29 Armin Rigo ar...@tunes.org:
The problem is that many locks are actually acquired implicitely.
For example, `print` to a buffered stream will acquire the fileobject's
mutex.
Indeed.
(...)
I suspect that I need to do a more thorough review of the stdlib (...)
I found a
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
interpreting in the usual Python
2011/8/30 stefan brunthaler ste...@brunthaler.net:
I will remove my development commentaries and create a private
repository at bitbucket for you* to take an early look like Georg (and
more or less Terry, too) suggested. Is that a good way for most of
you? (I would then give access to whomever
On Tue, Aug 30, 2011 at 13:42, Benjamin Peterson benja...@python.org wrote:
2011/8/30 stefan brunthaler ste...@brunthaler.net:
I will remove my development commentaries and create a private
repository at bitbucket for you* to take an early look like Georg (and
more or less Terry, too)
Maybe it'd be better to put 'atomic' in the threading module?
On 2011-08-30, at 4:02 PM, Armin Rigo wrote:
Re-hi,
2011/8/29 Armin Rigo ar...@tunes.org:
The problem is that many locks are actually acquired implicitely.
For example, `print` to a buffered stream will acquire the fileobject's
On Tue, Aug 30, 2011 at 1:54 PM, Benjamin Peterson benja...@python.orgwrote:
2011/8/30 stefan brunthaler ste...@brunthaler.net:
On Tue, Aug 30, 2011 at 13:42, Benjamin Peterson benja...@python.org
wrote:
2011/8/30 stefan brunthaler ste...@brunthaler.net:
I will remove my development
Hi!
I would like to get some opinion on possible os.walk improvement.
For the sake of simplicity let's assume I would like to skip all .svn
and tmp directories.
Current solution looks like this:
for t in os.walk(somedir):
t[1][:]=set(t[1])-{'.svn','tmp'}
... do something
This is a very
On Aug 30, 2011, at 9:05 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Aug 30, 2011 at 9:38 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 30 Aug 2011 13:29:59 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Anecdotal, non-reproducible performance figures are *not* the way to
go
On Wed, Aug 31, 2011 at 3:23 AM, stefan brunthaler
ste...@brunthaler.net wrote:
On Tue, Aug 30, 2011 at 09:42, Guido van Rossum gu...@python.org wrote:
Stefan, have you shared a pointer to your code yet? Is it open source?
I have no shared code repository, but could create one (is there any
On Wed, Aug 31, 2011 at 9:21 AM, Jesse Noller jnol...@gmail.com wrote:
Discussion of speed.python.org should happen on the mailing list for that
project if possible.
Hah, that's how out of the loop I am on that front - I didn't even
know there *was* a mailing list for it :)
Subscribed!
for t in os.walk(somedir):
t[1][:]=set(t[1])-{'.svn','tmp'}
... do something
This is a very clever hack but... it relies on internal implementation
of os.walk
This doesn't appear to be an internal implementation detail; this is
documented behavior.
Antoine Pitrou writes:
Sorry, what is a conformant UTF-16 array op?
For starters, one that doesn't ever return lone surrogates, but rather
interprets surrogate pairs as Unicode code points as in UTF-16. (This
is not a Unicode standard definition, it's intended to be suggestive
of why many app
On 8/30/2011 2:12 PM, Guido van Rossum wrote:
On Tue, Aug 30, 2011 at 10:50 AM, stefan brunthaler
ste...@brunthaler.net wrote:
Do you really need it to match a machine word? Or is, say, a 16-bit
format sufficient.
Hm, technically no, but practically it makes more sense, as (at least
for x86
On Tue, Aug 30, 2011 at 7:55 PM, Stephen J. Turnbull step...@xemacs.org wrote:
Antoine Pitrou writes:
Sorry, what is a conformant UTF-16 array op?
For starters, one that doesn't ever return lone surrogates, but rather
interprets surrogate pairs as Unicode code points as in UTF-16. (This
2011/8/30 Antoine Pitrou solip...@pitrou.net
Changing the bytecode width wouldn't make the interpreter more complex.
It depends on the kind of changes. :)
WPython introduced a very different intermediate code representation that
required a big change on the peepholer optimizer on 1.0 alpha
2011/8/30 Nick Coghlan ncogh...@gmail.com
Yeah, it's definitely a trade-off - the point I was trying to make is
that there *is* a trade-off being made between complexity and speed.
I think the computed-gotos stuff struck a nice balance - the macro-fu
involved means that you can still
2011/8/30 stefan brunthaler ste...@brunthaler.net
Yes, indeed I have a more straightforward instruction format to allow
for more efficient decoding. Just going from bytecode size to
word-code size without changing the instruction format is going to
require 8 (or word-size) times more memory
2011/8/30 stefan brunthaler ste...@brunthaler.net
Do I sense that the bytecode format is no longer platform-independent?
That will need a bit of discussion. I bet there are some things around
that depend on that.
Hm, I haven't really thought about that in detail and for longer, I
ran it
2011/8/31 Terry Reedy tjre...@udel.edu
I find myself more comfortable with the Cesare Di Mauro's idea of expanding
to 16 bits as the code unit. His basic idea was using 2, 4, or 6 bytes
instead of 1, 3, or 6.
It can be expanded to longer than 6 bytes opcodes, if needed. The format is
Guido van Rossum writes:
On Tue, Aug 30, 2011 at 7:55 PM, Stephen J. Turnbull step...@xemacs.org
wrote:
For starters, one that doesn't ever return lone surrogates, but rather
interprets surrogate pairs as Unicode code points as in UTF-16. (This
is not a Unicode standard definition,
63 matches
Mail list logo
