Tim Peters wrote:
[Fredrik Lundh]
wouldn't be the first time...
How soon we forget wink.
oh, that was in the dark ages of Python 1.4. I've rebooted myself many times
since
then...
Fredrik introduced a pile of optimizations special-casing the snot out
of small integers into ceval.c a
On Sat, Feb 19, 2005, Martin v. L?wis wrote:
Fredrik Lundh wrote:
I'd say that this explains why it would still make sense to let the code
generator change
x in (a, b, c) to x == a or x == b or x == c, as long as a, b, and c
are all integers.
How often does that happen in real code?
Dunno
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
