Why no warnings when re-assigning builtin names?
ethan at stoneleaf.us
Tue Aug 16 12:19:58 EDT 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
> 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
I think warnings should be reserved for language changes and such (like
DeprecationWarning, RuntimeWarning, and FutureWarning), not for possible
>> 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
> 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.
More information about the Python-list