Replacement for locals() ???

[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

[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

[Christian Tismer]

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:ti****@stackless.com>
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 [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Terry Reedy]

"Harald Massa" <cp*********@spamgourmet.com> wrote in message
news:Xn********************************@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

[Skip Montanaro]

>> 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

[Harald Massa]

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

[Christian Tismer]

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:ti****@stackless.com>
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 [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/