Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Thu, 7 Feb 2013 23:23:47 -0800 (PST)
In-Reply-To: <mailman.1484.1360304743.2939.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.196.110.35; posting-account=h3aEwQoAAACiuqX-oR3gvCVFm8lLHoWj
References: <02ced8e2-5967-4ce0-b257-83c3a3fbaf8e@googlegroups.com> <mailman.1484.1360304743.2939.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: PyWart: Namespace asinitiy and the folly of the global statement
From: Rick Johnson <rantingrickjohnson@gmail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Message-ID: <mailman.1490.1360308236.2939.python-list@python.org>
Lines: 43
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:38428

On Friday, February 8, 2013 12:25:34 AM UTC-6, Chris Angelico wrote:
> On Fri, Feb 8, 2013 at 3:30 PM, Rick Johnson wrote:
> > It is my strong opinion that all "unqualified" variables must be local =
to the containing block, func/meth, class, or module. To access any variabl=
e outside of the local scope a programmer MUST qualify that variable with t=
he func, class, or module identifiers. Consider the following examples
>=20
> Okay. Now start actually working with things, instead of just making
> toys. All your builtins now need to be qualified:
   =20
Chris you are very trollish, and a total tool of Deaprano, but you are damn=
 funny sometimes and for that reason i still respond to you. ;-)

> __builtins__.print("There
> are",__builtins__.len(self.some_list),"members in this list,
> namely:",__builtins__.repr(self.some_list))

That's funny, and i laughed whilst reading it, but i do have to admit that =
i did not explain this detail. IMHO, all builtins should not be auto-import=
ed, the programmer should import them either on a case by case basis, or do=
 the global import:

     from builtins import print, len, repr
     from builtins import *  # This is not recommended!

This would serve two purposes (1) the reader would know which builtins wher=
e being used in this module (2) the names would be bound properly to the mo=
dule namespace. But this does not answer your question, merely a side note

So your assertion is wrong. Built-ins /would/ be available at the module le=
vel with no qualification just as they are now. But they would also be avai=
lable in /every/ namespace because how else would we use them Chris?=20

It's very simple, when python encounters a unqualified symbol, it looks fir=
st for a match in the built-in symbols array, and if not match is found it =
then raises a NameError.

> Or are you going to make builtins and imports magically available as
> PHP-style superglobals?

Hmm, what are they now Chris? Python built-ins are known everywhere without=
 qualification and require no import. I think super-global about sums it up=
.