Replacement for locals() ???

Discussion in 'Python' started by Harald Armin Massa, Jul 30, 2004.

  1. I use locals() for conveniently "filling out" SQL-Statements:

    [snip]

    def updData(id, surename):
    sql="""update fisch set surename=%(surename)s where id=%(id)s"""
    cs.execute(sql, locals())


    [/snip]

    that works great and is well within the definition of the python
    db-api and is supported by pyPgSQL ... everything seems fine.

    UNTIL

    I read within psysco-FAQ and Jim Hugoninis IronPython paper: a lot of
    words about "locals() being very difficult or impossible to optimize"

    AND UNTIL

    so ... is there any convenient replacement? Of course I could do

    {"id":id, "surename":surename} , but that would be very very
    in-elegant.


    Harald
    Harald Armin Massa, Jul 30, 2004
    #1
    1. Advertising

  2. Harald> I read within psysco-FAQ and Jim Hugoninis IronPython paper: a
    Harald> lot of words about "locals() being very difficult or impossible
    Harald> to optimize"

    Harald> AND UNTIL

    Harald> so ... is there any convenient replacement? Of course I could do

    Harald> {"id":id, "surename":surename} , but that would be very very
    Harald> in-elegant.

    That's the only solution I've found so far. Makes for rather ugly code. If
    you have to choose, what do you want, fast or pretty? <wink>

    Skip
    Skip Montanaro, Jul 30, 2004
    #2
    1. Advertising

  3. Skip Montanaro wrote:

    > Harald> I read within psysco-FAQ and Jim Hugoninis IronPython paper: a
    > Harald> lot of words about "locals() being very difficult or impossible
    > Harald> to optimize"
    >
    > Harald> AND UNTIL
    >
    > Harald> so ... is there any convenient replacement? Of course I could do
    >
    > Harald> {"id":id, "surename":surename} , but that would be very very
    > Harald> in-elegant.
    >
    > That's the only solution I've found so far. Makes for rather ugly code. If
    > you have to choose, what do you want, fast or pretty? <wink>


    You can have both: fast and pretty.
    That's why I got interested in Bytecodehacks:
    I can write locals(), but transform that into
    the explicit from by introspection, and replace
    the function before I use it.
    (Haven't written an un-local()iser yet, but it
    seems straight forward).

    ciao - chris

    --
    Christian Tismer :^) <mailto:>
    Mission Impossible 5oftware : Have a break! Take a ride on Python's
    Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
    14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
    work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
    PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
    whom do you want to sponsor today? http://www.stackless.com/
    Christian Tismer, Jul 30, 2004
    #3
  4. Harald Armin Massa wrote:

    >{"id":id, "surename":surename} , but that would be very very
    >in-elegant.
    >
    >
    >
    >

    Are you experiencing a slow down due to using locals() or a significant
    performance increase by using the above method? If not, why switch away
    from locals?
    Gabriel Cooper, Jul 30, 2004
    #4
  5. Harald Armin Massa

    Harald Massa Guest

    Gabriel ,

    > Are you experiencing a slow down due to using locals() or a significant
    > performance increase by using the above method? If not, why switch away
    > from locals?


    I do not experience a slow down and did not measure any performance
    changes. My question orginates in three observations:

    1.) Jim Hugunin writes in his OSCON Paper
    (http://www.python.org/pycon/dc2004/papers/9/)
    The greatest performance improvement comes from [...] The price of this
    optimization is that it requires disabling the locals() builtin function
    [...]

    2.) Armin Rigo writes in "Known Bugs of Psyco" @
    http://psyco.sourceforge.net/psycoguide/bugs.html:
    No locals dictionary is available. The locals function always return an
    empty dictionary [...}

    3.) My usage of locals() is really peripheral. I just use it to make code
    shorter and to avoid typing misstakes with variables.

    So two of the greatest PythonBrains have problems in optimizing Python
    because of locals(), the most common usage of Python in my practice is
    peripheral; so just by way of precaution I am looking for a replacement.

    Harald
    Harald Massa, Jul 30, 2004
    #5
  6. Harald Armin Massa

    Terry Reedy Guest

    "Harald Massa" <> wrote in message
    news:Xns95375A0BA9Ecpl19ghumspamgourmet@195.20.224.116...
    > So two of the greatest PythonBrains have problems in optimizing Python
    > because of locals(), the most common usage of Python in my practice is
    > peripheral; so just by way of precaution I am looking for a replacement.


    I suspect you are very prematurely optimizing. Since you are filling out
    SQL statements, I would expect that your bottlenecks are and will be the
    execution of the statements, and not the construction of the statements.

    tjr
    Terry Reedy, Jul 31, 2004
    #6
  7. >> So two of the greatest PythonBrains have problems in optimizing
    >> Python because of locals(), the most common usage of Python in my
    >> practice is peripheral; so just by way of precaution I am looking for
    >> a replacement.


    Terry> I suspect you are very prematurely optimizing. Since you are
    Terry> filling out SQL statements, I would expect that your bottlenecks
    Terry> are and will be the execution of the statements, and not the
    Terry> construction of the statements.

    Perhaps he is, however I think the presence of locals() in a function
    prevents one from using Psyco on that program if the function is executed.
    It may even (I don't recall off the top of my head and don't have immediate
    access to Intel hdwe to try it on) crash the program.

    Skip
    Skip Montanaro, Jul 31, 2004
    #7
  8. Harald Armin Massa

    Harald Massa Guest

    Terry,


    >> So two of the greatest PythonBrains have problems in optimizing
    >> Python because of locals(), the most common usage of Python in my
    >> practice is peripheral; so just by way of precaution I am looking for
    >> a
    >>r eplacement.

    >
    > I suspect you are very prematurely optimizing. Since you are filling
    > out SQL statements, I would expect that your bottlenecks are and will
    > be the execution of the statements, and not the construction of the
    > statements.


    you are partially right. I do not have ANY performance problems in that
    Python code. Most of the time the program is either waiting for a
    COM-Server, a database-Server or user-typing.

    As Skip stated: using locals() prevents the EASY use of psyco.
    (import psyco; psyco full
    Forcing me to manually bind psyco to functions ... etc.

    also in standard lib "encodings" locals() is used.

    I know there may be some exotic usages of locals(), but most use is
    really straightforward string substitution & parameterparsing; and
    thatfor I am asking: "How can I make it easy to psyco / ironpython /
    PyPy???/ parrot to optimize my code" ...

    Best wishes,

    Harald
    Harald Massa, Jul 31, 2004
    #8
  9. Harald Massa wrote:
    > Terry,
    >
    >
    >
    >>>So two of the greatest PythonBrains have problems in optimizing
    >>>Python because of locals(), the most common usage of Python in my
    >>>practice is peripheral; so just by way of precaution I am looking for
    >>>a
    >>>r eplacement.

    >>
    >>I suspect you are very prematurely optimizing. Since you are filling
    >>out SQL statements, I would expect that your bottlenecks are and will
    >>be the execution of the statements, and not the construction of the
    >>statements.

    >
    >
    > you are partially right. I do not have ANY performance problems in that
    > Python code. Most of the time the program is either waiting for a
    > COM-Server, a database-Server or user-typing.
    >
    > As Skip stated: using locals() prevents the EASY use of psyco.
    > (import psyco; psyco full


    Ok, I see. Note that the EASY use is almost always much slower
    than a partial, controlled usage of Psyco, for non-trivial
    applications.

    The bad thing about locals() is that it simply goes wrong
    with Psyco. I think it would be nicer if psyco would
    simply refuse optimization in this case and leave things intact.

    There are some constructs which just disable Psyco: If the
    code contains certain opcodes, Psyco will not touch the whole
    function. Examples are:

    - generators: an existing yield disables Psyco for the func
    - usage of nested scopes.

    On the scopes case: If you have a construct like this:

    def outer():
    something = 42
    def inner():
    print something
    inner()

    Then both outer and inner will contain opcodes which disable
    Psyco from touching things at all.
    So if you can manage to inject such a construct, your locals
    will be fine with Psyco.full().

    Anyway, I think we should hint Armin (the other one) to
    change the locals behavior to disable Psyco.

    ciao - chris

    --
    Christian Tismer :^) <mailto:>
    Mission Impossible 5oftware : Have a break! Take a ride on Python's
    Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
    14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
    work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
    PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
    whom do you want to sponsor today? http://www.stackless.com/
    Christian Tismer, Jul 31, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Aaron Ackerman
    Replies:
    5
    Views:
    415
    Chris Dunaway
    Oct 13, 2003
  2. dgk
    Replies:
    2
    Views:
    404
  3. Giles Brown

    Question about "exec in globals, locals"

    Giles Brown, Jul 4, 2003, in forum: Python
    Replies:
    2
    Views:
    356
    Adrien Di Mascio
    Jul 4, 2003
  4. Paul Paterson

    How safe is modifying locals()?

    Paul Paterson, Jul 25, 2003, in forum: Python
    Replies:
    15
    Views:
    492
    Corey Coughlin
    Jul 28, 2003
  5. tedsuzman
    Replies:
    2
    Views:
    7,076
    Michel Claveau, résurectionné d'outre-bombe inform
    Jul 21, 2004
Loading...

Share This Page