A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2006-March/062425.html below:

[Python-Dev] Making builtins more efficient

[Python-Dev] Making builtins more efficient [Python-Dev] Making builtins more efficientRodrigo Dias Arruda Senra rodsenra at gpr.com.br
Wed Mar 15 14:47:32 CET 2006
|  [ Raymond Hettinger ]:
|  > If someone really cared about the double lookup, they could
|  > flatten a level by starting their modules with:
|  > 
|  >    from __builtin__ import *
|  > 
|  > However, we don't see people writing this kind of code.  That
|  > could mean that the double lookup hasn't been a big concern.


[ Steven Elliott <selliott4 at austin.rr.com> ]:
----------------------------------------
|  It could mean that.  I think what you are suggesting is sufficiently
|  cleaver that the average Python coder may not have thought of it.
| 
|  # small cut 
|
| And the "from __builtin__  import *" additionally imposes a startup
| cost and memory cost (at least a word per builtin, I would guess).

I suppose that if someone decided to use "from __builtin__  import *"
to avoid double lookup, this person *knows* what builtins should be
optmized, and therefore could use  import specific builtins
"from __builtin__ import len, max" avoiding a startup/memory penalty.
Otherwise, the startup/memory penalty might be non-issues.

cheers,
Rod Senra
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4