Why no warnings when re-assigning builtin names?
Ethan Furman
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
>> 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