On Tue, Sep 11, 2012 at 5:40 PM, Victor Stinner
<victor.stin...@gmail.com> wrote:
> 2012/9/11 Guido van Rossum <gu...@python.org>:
>> FWIW, I expect that there are few places where len(<constant string>)
>> is actually used.
>
> I found one revelant example in the stdlib.
>
> if path.endswith('.dylib'):
> yield path[:-len('.dylib')] + suffix + '.dylib'
> else:
> yield path + suffix
>
> Cool, I'm not the only developer too lazy to copy/paste len('suffix')
> in a Python interpreter and then copy/paste the result in my code :-)
>
> "if text.endswith('suffix'): ... text[:-len('suffix')] ..." is a
> common pattern in my code.
Ok, that's a good use case.
>> However I expect it to be quite common for ord(),
>> where the same reasoning applies.
>
> 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 the right u() function? IIRC you said earlier that you're not
even capable of recognizing "len = ord; print(len('a'))" -- if that is
really true, I'm very worried about your optimizer's capacity for
breaking code. I'm not talking about "behind-their-back" changes to
__builtins__ or patching of the module globals. I'm talking about
detecting straightforward definitions that override the identifiers
you are replacing.
> I expect that astoptimizer will be able to remove (or at least
> reduce!) the overhead of the six library and all checks on the Python
> version ("if PYTHON3: ... else: ...").
Hm. Wouldn't it be just as easy to run a source-to-source translator
to remove six artefacts instead of an ast optimizer? Surely some
convention could be adopted that is easy to use, and the tool to do
the translation could be a lot simpler than an ast optimizer.
Sorry for being skeptical, but I'm not excited about advertising this
as a general optimization tool unless you can make it a lot safer.
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
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
