[Python-Dev] 'shadowing' builtins

[Thomas Wouters]

On Mon, Jul 17, 2000 at 01:18:44PM -0500, Paul Prescod wrote:
> Thomas Wouters wrote:

> > He decided to go to David Beazly's python introduction, and he was suprised
> > at how you can do 'None = 4'. And when I explained it's harmless (because
> > it's local, not global) he was suprised it didn't generate a warning. And,
> > well, why doesn't it generate a warning ? Only with an, uhm, '-w' option or
> > so, of course, or perhaps add it to the '-t' option. It would be also a
> > compile-time-check. It might require a seperate lookup table (haven't looked
> > at it at all, yet) that duplicates the 'builtin' namespace, but I'd think
> > it's worth it.

>  * None, map and other such long-term, ancient built-ins should not be
> directly overridable. I don't think we need a warning mode. Just outlaw
> it. We can do this with a semantic check in the compiler.

My first reaction was 'Ack, eek, argh, nonono'. So I decided to sleep over
it. And my reaction is still 'Ack. eek, argh, nonono' ;) If it's optional,
like a '-ww' option, sure. But by default ? Please don't. One of python's
great features is that it's so damned consistent. Having some builtins
overridable and others not would not only break a lot of code, it would also
confuse a lot of people.

There is no particular reason to disallow assigning to map() for programs
where map() is not used, for instance. I often find myself doing 'list =
<...>' for small scripts, eventhough I realize while I'm typing that 'list'
is a builtin function. Part of the reasons is that 'list' is an incredibly
descriptive name, and my code often gets read by colleagues who still need
to get infected by the Python virus.

(Though, I have to admit, it *is* slowly spreading ;)

Nevertheless, I wouldn't do that in large projects, and that's where I
invision the '-w' option would be best used. 'This might become a problem'. 

>  * Those with a good reason to shadow them would do it by assignment to
> the module's dict or __builtins__. The "feature" would still be there if
> you need it, but it would be syntactically distinct. Or maybe we need to
> disallow it entirely to allow optimizers to attack this important
> special case.

Perhaps, as an option. With an optimizer. I wouldn't do it for the sake of
it; only do it if the user asks for it.

>  * Python badly needs a warning infrastructure. If I had time, that
> would be my first PEP. I'd rather the former tightening up was not
> hostage to a warning infrastructure that nobody gets around to
> implementing, though. 

I might be tempted to suggest a compile-only command line switch, too. Doing
it through a small script is a tad cumbersome, especially if you just want a
compile-run with (for instance) -w or -t, to see if you have any obvious
problems.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!