Why no warnings when re-assigning builtin names?
rosuav at gmail.com
Wed Aug 17 09:27:44 CEST 2011
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
> 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.
"""Foo's the list provided and returns True on success or False on
"""Counts the number of bars in the list, assuming it to be made
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.
More information about the Python-list