On 9/12/2012 3:36 AM, Serhiy Storchaka wrote:
I personally would prefer a 2to3-like "modernizer" (as a separate
utility and as plugins for the IDEs), which would have found some
templates and offered replacing by a more modern, readable (and possibly
effective) variant. The decision on the appli
On Tue, Sep 11, 2012 at 2:57 PM, Nick Coghlan wrote:
> On Tue, Sep 11, 2012 at 8:41 PM, Victor Stinner
> wrote:
>> * Call builtin functions if arguments are constants. Examples:
>>
>> - len("abc") => 3
>> - ord("A") => 65
>
> This is fine in an external project, but should never be added to t
>> Projects using the same code base for Python 2 and Python 3 contain a
>> lot of inefficient code. For example, using the six library, a simple
>> Unicode literal strings becomes a function code: u('unicode').
>
> But are you able to do enough static analysis to feel comfortable that
> this is th
2012/9/12 Serhiy Storchaka :
>>> set([x for ...]) => {x for ...}
>>> dict([(k, v) for ...]) => {k: v for ...}
>>> dict((k, v) for ...) => {k: v for ...}
>>> ''.join([s for ...]) => ''.join(s for ...)
>>> a.extend([s for ...]) => a.extend(s for ...)
>>
>> These optimizations look correct.
>
> Actual
On 12.09.12 00:47, Victor Stinner wrote:
x = x + [y] => x.append(y)
x = x + [y, z] => x.extend([y, z])
It behaves differently if x is not a list, but str for example.
Actually even worse. Transformations applicable only if x has not
aliases. Pseudocode:
if type(x) is list and refcount(x)
On 12.09.12 00:47, Victor Stinner wrote:
set([x for ...]) => {x for ...}
dict([(k, v) for ...]) => {k: v for ...}
dict((k, v) for ...) => {k: v for ...}
''.join([s for ...]) => ''.join(s for ...)
a.extend([s for ...]) => a.extend(s for ...)
These optimizations look correct.
Actually generator
On Tue, Sep 11, 2012 at 5:40 PM, Victor Stinner
wrote:
> 2012/9/11 Guido van Rossum :
>> FWIW, I expect that there are few places where len()
>> is actually used.
>
> I found one revelant example in the stdlib.
>
> if path.endswith('.dylib'):
> yield path[:-len('.dylib'
2012/9/11 Guido van Rossum :
> FWIW, I expect that there are few places where len()
> is actually used.
I found one revelant example in the stdlib.
if path.endswith('.dylib'):
yield path[:-len('.dylib')] + suffix + '.dylib'
else:
yield path
> i am a longtime Reader of this list and this is the first time i a dare to
> speak up.
> Apology in advance for any noise, silly comments and not posting to
> python-ideas ;).
Welcome!
> Well how about implementing guards like in pypy?
Guards would allow to generate specialized functions witho
Hello,
i am a longtime Reader of this list and this is the first time i a dare to
speak up.
Apology in advance for any noise, silly comments and not posting to
python-ideas ;).
Am 11.09.2012 12:41, schrieb Victor Stinner:
I plan to implement other optimizations like unrolling loop or convert
On 11/09/2012 22:46, Victor Stinner wrote:
2012/9/11 Nick Coghlan :
This is fine in an external project, but should never be added to the
standard library. The barrier to semantic changes that break
monkeypatching should be high.
The version 0.3 has a known bug: "len=chr; print(len('A'))" is
o
>>> - frozenset("ab") | frozenset("bc") => frozenset("abc")
>
> That's a name lookup, too.
Yes, and it is only optimized if the "builtin_funcs" feature is
enabled explictly.
> Except that evaluating something like '"abc" * constant' can eat up all
> memory, imagine this code:
>
> KILL_MEMOR
>> * Call builtin functions if arguments are constants. Examples:
>>
>>- len("abc") => 3
>>- ord("A") => 65
>
> Does this mean transformation print("A") => None and output at compile time?
Only a subset of builtin functions are called at compile time, and not
with any constant value. See a
2012/9/11 Nick Coghlan :
> This is fine in an external project, but should never be added to the
> standard library. The barrier to semantic changes that break
> monkeypatching should be high.
The version 0.3 has a known bug: "len=chr; print(len('A'))" is
optimized, whereas it should not. It is no
Serhiy Storchaka, 11.09.2012 20:48:
> set([1, 2, 3]) => {1, 2, 3}
> set([x for ...]) => {x for ...}
> dict([(k, v) for ...]) => {k: v for ...}
> dict((k, v) for ...) => {k: v for ...}
> ''.join([s for ...]) => ''.join(s for ...)
> a.extend([s for ...]) => a.extend(s for ...)
> (f(x) for x in a) =>
Nick Coghlan, 11.09.2012 14:57:
> On Tue, Sep 11, 2012 at 8:41 PM, Victor Stinner wrote:
>> * Loop: replace range() with xrange() on Python 2, and list with
>> tuple. Examples:
>>
>> - for x in range(n): ... => for x in xrange(n): ...
>> - for x in [1, 2, 3]: ... => for x in (1, 2, 3): ...
>
On 11.09.12 13:41, Victor Stinner wrote:
Here are some progress on my astoptimizer project. If you are interested by
the optimizer, run it on your own project or help me to implement more
optimizations.
http://pypi.python.org/pypi/astoptimizer
https://bitbucket.org/haypo/astoptimizer
It's a ve
On Tue, Sep 11, 2012 at 10:06 AM, MRAB wrote:
> On 11/09/2012 13:06, Victor Stinner wrote:
* Call builtin functions if arguments are constants. Examples:
- len("abc") => 3
- ord("A") => 65
>>>
>>>
>>> Does it preserve python semantics? What if you change the len builti
On 11/09/2012 13:06, Victor Stinner wrote:
* Call builtin functions if arguments are constants. Examples:
- len("abc") => 3
- ord("A") => 65
Does it preserve python semantics? What if you change the len builtin?
This optimization is disabled by default (in the version 0.3), because
built
On Tue, Sep 11, 2012 at 8:41 PM, Victor Stinner
wrote:
> * Call builtin functions if arguments are constants. Examples:
>
> - len("abc") => 3
> - ord("A") => 65
This is fine in an external project, but should never be added to the
standard library. The barrier to semantic changes that break
m
>> * Call builtin functions if arguments are constants. Examples:
>>
>> - len("abc") => 3
>> - ord("A") => 65
>
> Does it preserve python semantics? What if you change the len builtin?
This optimization is disabled by default (in the version 0.3), because
builtin functions may be shadowed. Exa
On Tue, Sep 11, 2012 at 12:41 PM, Victor Stinner
wrote:
> Hi,
>
> Here are some progress on my astoptimizer project. If you are interested by
> the optimizer, run it on your own project or help me to implement more
> optimizations.
>
> http://pypi.python.org/pypi/astoptimizer
> https://bitbucket.o
Am 11.09.2012 12:41, schrieb Victor Stinner:
> Hi,
>
> Here are some progress on my astoptimizer project. If you are interested by
> the optimizer, run it on your own project or help me to implement more
> optimizations.
Wow, that's an amazing list of optimizations. Keep up the good work!
Christ
23 matches
Mail list logo
