Why no warnings when re-assigning builtin names?

[Chris Angelico]

On Tue, Aug 16, 2011 at 6:43 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
> Seebs wrote:
>>
>> On 2011-08-16, Ethan Furman <ethan at stoneleaf.us> wrote:
>>>
>>> I think warnings should be reserved for language changes and such (like
>>> DeprecationWarning, RuntimeWarning, and FutureWarning), not for possible
>>> programmer mistakes.
>>
>> I disagree, on the basis of the following:
>>
>> The quality of C code I have to deal with has increased dramatically as
>> gcc's aggressive use of warnings has spread.
>
> With gcc you pay the cost once, with Python you would pay it with every run.
>  A linter would be more along the lines of 'pay it once'.

Agreed; in addition, it's spam. Spam at compile time isn't much of an
issue; you type ./configure and make, and a billion messages scroll
past you. Spam at run time? Everyone who USES the program has to deal
with it, and in amongst the program's own output. I don't know how to
have Python emit warnings that wouldn't cause these issues. The only
thing I can think of is to have the interactive interpreter default to
showing more warnings, which is far from perfect itself.

As to 'file' specifically, my 3.2 doesn't seem to have it as a
builtin. The return value from open() is _io.TextIOWrapper, so the
whole issue of file=open(...) may have been completely dodged.

ChrisA