Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Replacement for locals() ???

Reply
Thread Tools

Replacement for locals() ???

 
 
Harald Armin Massa
Guest
Posts: n/a
 
      07-30-2004
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
 
Reply With Quote
 
 
 
 
Skip Montanaro
Guest
Posts: n/a
 
      07-30-2004

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
 
Reply With Quote
 
 
 
 
Christian Tismer
Guest
Posts: n/a
 
      07-30-2004
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 :^) <(E-Mail Removed)>
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/

 
Reply With Quote
 
Gabriel Cooper
Guest
Posts: n/a
 
      07-30-2004


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?
 
Reply With Quote
 
Harald Massa
Guest
Posts: n/a
 
      07-30-2004
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
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      07-31-2004

"Harald Massa" <(E-Mail Removed)> 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



 
Reply With Quote
 
Skip Montanaro
Guest
Posts: n/a
 
      07-31-2004
>> 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
 
Reply With Quote
 
Harald Massa
Guest
Posts: n/a
 
      07-31-2004
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

 
Reply With Quote
 
Christian Tismer
Guest
Posts: n/a
 
      07-31-2004
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 :^) <(E-Mail Removed)>
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/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Replacement PSU for an ADSL Router Edward W. Thompson Wireless Networking 0 09-06-2005 10:40 AM
Replacement for FF calendar extension Dan Firefox 5 03-23-2005 08:38 PM
Replacement for AOL newsgroup access EJGroth Firefox 0 02-08-2005 02:41 PM
Calendar replacement William W. Plummer Firefox 1 07-02-2004 04:10 PM
Replacement For Access Point KS Wireless Networking 1 06-24-2004 04:40 AM



Advertisments