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/2003-June/036427.html below:

[Python-Dev] problem with assignment shadows builtin warning

[Python-Dev] problem with assignment shadows builtin warning [Python-Dev] problem with assignment shadows builtin warningSamuele Pedroni pedronis@bluewin.ch
Mon, 16 Jun 2003 22:18:57 +0200
At 15:53 16.06.2003 -0400, Jeremy Hylton wrote:
>On Mon, 2003-06-16 at 15:33, Jeremy Hylton wrote:
> > My initial reaction was that we should not have a deprecation warning
> > for this kind of shadowing, but I'm growing less comfortable about the
> > names.  I'd definitely complain about a top-level "import list"; I don't
> > know why it is any better as a module within a package.
>
>Guido observed that a top-level "import list" does not generate a
>warning.  So regardless of the propriety of naming a module in a package
>"list", it should not generate a warning.  I guess someone needs to
>patch the import code to manipulate the parent namespaces in a way that
>won't generate an exception.

so code like

<pkg/__init__.py>


def reveal():
   print list

</pkg/__init__.py>

if pkg has a list subpackage/module will show that we are cheating, after 
caching is implemented, wrt to the old global->builtins lookup rule, 
because after:

import pkg.list

pkg.__dict__['list'] will be a module

but

pkg.reveal() will print the list builtin.

regards. 




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