A RetroSearch Logo

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

Search Query:

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

[Python-Dev] Making builtins more efficient

[Python-Dev] Making builtins more efficient [Python-Dev] Making builtins more efficientPaul Moore p.f.moore at gmail.com
Thu Mar 9 13:00:57 CET 2006
On 3/9/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Steven Elliott wrote:
> > I'm interested in how builtins could be more efficient.  I've read over
> > some of the PEPs having to do with making global variables more
> > efficient (search for "global"):
> >     http://www.python.org/doc/essays/pepparade.html
> > But I think the problem can be simplified by focusing strictly on
> > builtins.
>
> Unfortunately, builtins can currently be shadowed in the module global
> namespace from outside the module (via constructs like "import mod; mod.str =
> my_str"). Unless/until that becomes illegal, focusing solely on builtins
> doesn't help - the difficulties lie in optimising builtin access while
> preserving the existing name shadowing semantics.

Is there any practical way of detecting and flagging constructs like
the above (remotely shadowing a builtin in another module)? I can't
see a way of doing it (but I know very little about this area...).

If it *is* possible, I'd say it's worth implementing at least a
warning sooner rather than later - the practice seems questionable at
best, and any progress towards outlawing it would help in work on
optimising builtins.

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