Why no warnings when re-assigning builtin names?

Ethan Furman ethan at stoneleaf.us
Tue Aug 16 18:19:58 CEST 2011


Philip Semanchuk wrote:
> On Aug 16, 2011, at 11:41 AM, Ethan Furman wrote:
>> Philip Semanchuk wrote:
>>> If we are to eschew warnings in
>>> cases where they might be highlighting something harmless, then we would
>>> have no warnings at all.
 >>
>> Sounds good to me.  ;)  Keep such things in the IDE's, and then those
 >> who desire such behavior can have it there.  Do not clutter Python with
 >> such.
> 
> You wink, yet you sound serious. 

The smiley is an attempt to not sound harsh.

 > What's with the mixed message? Do you honestly advocate removing all
 > warnings from Python, or not? I sincerely would like to know what you 
think.

I think warnings should be reserved for language changes and such (like 
DeprecationWarning, RuntimeWarning, and FutureWarning), not for possible 
programmer mistakes.


>> What makes you think it's unintentional?  file makes a good variable name...
> 
> "Unintentional" as in, "I'm using file as a variable name because it's handy"
 > as opposed to intentional as in "Yes, I am deliberately changing the 
meaning
 > of this builtin".

That's not what 'unintentional' means.  Further, there's no way to tell 
whether it was or was not from the code alone.  Unless it caused a bug, 
in which case I'd be willing to call it unintentional.  ;)

>> I don't see that as a problem that Python needs to solve.
> 
> "need" is a strong word. Python will be fine regardless of whether this changes
 > or not. I believe Python could be improved; that's all I'm arguing.

Python can be improved -- I don't see 'hand-holding' as an improvement. 
  IDEs and lints can do this.


~Ethan~



More information about the Python-list mailing list