Replacement for locals() ???

H

Harald Armin Massa

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
 
S

Skip Montanaro

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
 
C

Christian Tismer

Skip said:
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:[email protected]>
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/
 
G

Gabriel Cooper

Harald said:
{"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?
 
H

Harald Massa

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
 
T

Terry Reedy

Harald Massa said:
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
 
S

Skip Montanaro

So two of the greatest PythonBrains have problems in optimizing
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
 
H

Harald Massa

Terry,

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
 
C

Christian Tismer

Harald said:
Terry,





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:[email protected]>
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/
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top