Raymond Hettinger wrote:
Based on some ideas from Skip, I had tried transforming the likes of x
in (1,2,3) into x in frozenset([1,2,3]). When applicable, it
substantially simplified the generated code and converted the O(n)
lookup into an O(1) step. There were substantial savings even if
Based on some ideas from Skip, I had tried transforming the likes of
x in (1,2,3) into x in frozenset([1,2,3])
Fredrik savings in what? time or bytecode size? constructed
Fredrik micro-benchmarks, or examples from real-life code?
Fredrik do we have any statistics on
I'm unclear why the list in for x in [1,2,3] or if x not in
[1,2,3]
can't fairly easily be recognized as a constant and just be placed in
the
constants array.
That part got done (at least for the if-statement).
The question is whether the type transformation idea should be carried a
step
At 04:45 PM 2/18/05 +0100, Fredrik Lundh wrote:
Phillip J. Eby wrote:
Only contains expressions are translated:
if x in [1,2,3]
currently turns into:
if x in (1,2,3)
and I'm proposing that it go one step further:
if x in Seachset([1,2,3])
ISTM that whenever I use a constant
Raymond Hettinger wrote:
Based on some ideas from Skip, I had tried transforming the likes of x
in (1,2,3) into x in frozenset([1,2,3]). When applicable, it
substantially simplified the generated code and converted the O(n)
lookup into an O(1) step. There were substantial savings even if the
set
Hello again,
There is a great discussion going on the numpy list regarding a proposed
PEP for multidimensional arrays that is in the works.
During this discussion as resurfaced regarding slicing with objects that
are not IntegerType objects but that
have a tp_as_number-nb_int method to convert
Would it be possible to change
_PyEval_SliceIndex in ceval.c
so that rather than throwing an error if the indexing object is not an
integer, the code first checks to see if the object has a
tp_as_number-nb_int method and calls it instead.
I don't think this is the right solution; since
Travis Oliphant wrote:
Hello again,
There is a great discussion going on the numpy list regarding a proposed
PEP for multidimensional arrays that is in the works.
During this discussion as resurfaced regarding slicing with objects that
are not IntegerType objects but that
have a
(More readable second paragraph)
Hello again,
There is a great discussion going on the numpy list regarding a proposed
PEP for multidimensional arrays that is in the works.
During this discussion a problem has resurfaced regarding slicing with
objects that are not IntegerType objects but that
On Fri, 18 Feb 2005 13:28:34 -0800, Guido van Rossum
[EMAIL PROTECTED] wrote:
Would it be possible to change
_PyEval_SliceIndex in ceval.c
so that rather than throwing an error if the indexing object is not an
integer, the code first checks to see if the object has a
On Feb 18, 2005, at 4:36 PM, David Ascher wrote:
On Fri, 18 Feb 2005 13:28:34 -0800, Guido van Rossum
[EMAIL PROTECTED] wrote:
Would it be possible to change
_PyEval_SliceIndex in ceval.c
so that rather than throwing an error if the indexing object is not
an
integer, the code first checks to see
On Thu, 2005-02-17 at 22:38, Tim Peters wrote:
Then you allocate a small object, marked 's':
bbbsfff
Isn't the whole point of obmalloc is that we don't want to allocate s
on the heap, since it is small? I guess s could be an object that
might potentially
Sorry for taking so long to get back to this thread, it has been one of
those weeks for me.
On Feb 16, 2005, at 2:50, Martin v. Löwis wrote:
Evan then understood the feature, and made it possible.
This is very true: it was a very useful exercise.
I can personally accept breaking the code that
Guido van Rossum wrote:
Would it be possible to change
_PyEval_SliceIndex in ceval.c
so that rather than throwing an error if the indexing object is not an
integer, the code first checks to see if the object has a
tp_as_number-nb_int method and calls it instead.
I don't think this is the
[Tim Peters]
...
Then you allocate a small object, marked 's':
bbbsfff
[Evan Jones]
Isn't the whole point of obmalloc
No, because it doesn't matter what follows that introduction:
obmalloc has several points, including exploiting the GIL, heuristics
On Feb 18, 2005, at 17:51, Tim Peters wrote:
grow the list to its final size once, at the start (overestimating if
you don't know for sure). Then instead of appending, keep an index to
the next free slot, same as you'd do in C. Then the list guts never
move, so if that doesn't yield the same
[Phillip J. Eby]
Still, it's rather interesting that tuple.__contains__ appears slower than a
series of LOAD_CONST and == operations, considering that the tuple
should be doing basically the same thing, only without bytecode fetch-and-
decode overhead. Maybe it's tuple.__contains__ that needs
Wouldn't it help a lot more if the compiler would detect that
(1,2,3) is immutable and convert it into a constant at
compile time ?!
Yes. We've already gotten it to that point:
. . .
Cool. Does that work for all tuples in the program ?
It is limited to just tuples of constants
[Raymond Hettinger]
...
The problem with the transformation was that it didn't handle the case
where x was non-hashable and it would raise a TypeError instead of
returning False as it should.
I'm very glad you introduced the optimization of building small
constant tuples at compile-time.
[Tim Peters]
grow the list to its final size once, at the start (overestimating if
you don't know for sure). Then instead of appending, keep an index to
the next free slot, same as you'd do in C. Then the list guts never
move, so if that doesn't yield the same kind of speedup without using
Gregory P. Smith wrote:
fyi - i've updated the python sha1/md5 openssl patch. it now replaces
the entire sha and md5 modules with a generic hashes module that gives
access to all of the hash algorithms supported by OpenSSL (including
appropriate legacy interface wrappers and falling back to the
I'm very glad you introduced the optimization of building small
constant tuples at compile-time. IMO, that was a pure win.
It's been out in the wild for a while now with no issues. I'm somewhat
happy with it.
the transformation isn't semantically correct on the
face of it.
Well that's
This is something I've typed way too many times:
Py class C():
File stdin, line 1
class C():
^
SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a function with no
arguments still requires parentheses in the definition statement, but
From: Armin Rigo [EMAIL PROTECTED]
Hi Tim,
On Thu, Feb 17, 2005 at 01:44:11PM -0500, Tim Peters wrote:
256 ** struct.calcsize('P')
Now if you'll just sign and fax a Zope contributor agreement, I'll
upgrade ZODB to use this slick trick wink.
I hereby donate this line of code to
From: Martin v. Löwis [EMAIL PROTECTED]
Donovan Baarda wrote:
This patch keeps the current md5c.c, md5module.c files and adds the
following; _hashopenssl.c, hashes.py, md5.py, sha.py.
[...]
If all we wanted to do was fix the md5 module
If we want to fix the licensing issues with the md5
On Fri, Feb 18, 2005 at 10:06:24AM +0100, Martin v. L?wis wrote:
Donovan Baarda wrote:
This patch keeps the current md5c.c, md5module.c files and adds the
following; _hashopenssl.c, hashes.py, md5.py, sha.py.
[...]
If all we wanted to do was fix the md5 module
If we want to fix the
On 2005 Feb 19, at 06:03, Nick Coghlan wrote:
This is something I've typed way too many times:
Py class C():
File stdin, line 1
class C():
^
SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a
function with no arguments still requires
27 matches
Mail list logo
