Why no warnings when re-assigning builtin names?

[Chris Angelico]

On Wed, Aug 17, 2011 at 2:35 AM, Seebs <usenet-nospam at seebs.net> wrote:
> On 2011-08-17, Chris Angelico <rosuav at gmail.com> wrote:
>> It mightn't be very significant, but there'd still be some cost.
>> However, IMHO the greatest cost is the spamminess; forcing the user to
>> deal with lines and lines of warnings is not a useful way to design a
>> language.
>
> Lines and lines?
>
> I'd say if it's to be allowed to shadow built-ins (and I'm not sure that's
> a good thing at all), you'd still be looking at one warning per shadowing,
> which shouldn't be too many.

One warning per shadowing. Okay.

def foo(list):
   """Foo's the list provided and returns True on success or False on
failure."""

def bar(list):
    """Counts the number of bars in the list, assuming it to be made
of music."""
    if not foo(list): return

You call foo() once and bar() twice. How many shadowings have there
been? How many warnings do you get?

A simple implementation would give five warnings for this case - once
for each invocation that shadows a builtin. Another simple
implementation would give two warnings, at the time that the def
statements are executed; this is preferred, but it's still two
warnings, and if you have a huge set of functions that do this, that
can easily be "lines and lines" of warnings. Or should it set a flag
and say "I've already warned this session about shadowing 'list', so
suppress all others"? That seems confusing.

ChrisA