Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #11475 > unrolled thread

Re: Why no warnings when re-assigning builtin names?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-15 18:13 -0400
    Re: Why no warnings when re-assigning builtin names? rantingrick <rantingrick@gmail.com> - 2011-08-15 18:12 -0700

#11475 — Re: Why no warnings when re-assigning builtin names?

On Aug 15, 2011, at 5:52 PM, Gerrat Rickert wrote:

> With surprising regularity, I see program postings (eg. on
> StackOverflow) from inexperienced Python users  accidentally
> re-assigning built-in names.
> 
> 
> 
> For example, they'll innocently call some variable, "list", and assign a
> list of items to it.
> 
> ...and if they're _unlucky_ enough, their program may actually work
> (encouraging them to re-use this name in other programs).

Or they'll assign a class instance to 'object', only to cause weird errors later when they use it as a base class.

I agree that this is a problem. The folks on my project who are new-ish to Python overwrite builtins fairly often. Since there's never been any consequence other than my my vague warnings that something bad might happen as a result, it's difficult for them to develop good habits in this regard. It doesn't help that Eclipse (their editor of choice) doesn't seem to provide a way of coloring builtins differently. (That's what I'm told, anyway. I don't use it.)

> If they try to use an actual keyword, both the interpreter and compiler
> are helpful enough to give them a syntax error, but I think the builtins
> should be "pseudo-reserved", and a user should explicitly have to do
> something *extra* to not receive a warning.

Unfortunately you're suggesting a change to the language which could break existing code. I could see a use for "from __future__ import squawk_if_i_reassign_a_builtin" or something like that, but the current default behavior has to remain as it is.

JMO,
Philip

[toc] | [next] | [standalone]

#11493

On Aug 15, 5:13 pm, Philip Semanchuk <phi...@semanchuk.com> wrote:
> On Aug 15, 2011, at 5:52 PM, Gerrat Rickert wrote:
>
> > With surprising regularity, I see program postings (eg. on
> > StackOverflow) from inexperienced Python users  accidentally
> > re-assigning built-in names.
>
> > For example, they'll innocently call some variable, "list", and assign a
> > list of items to it.
>
> > ...and if they're _unlucky_ enough, their program may actually work
> > (encouraging them to re-use this name in other programs).
>
> Or they'll assign a class instance to 'object', only to cause weird errors later when they use it as a base class.
>
> I agree that this is a problem. The folks on my project who are new-ish to Python overwrite builtins fairly often.

Simple syntax hilighting can head off these issues with great ease.
Heck, python even has a keyword module, and you get a list of built-
ins from the dir() function!

import keyword
import __builtin__
PY_BUILTINS = [str(name) for name in dir(__builtin__) if not
name.startswith('_')]
PY_KEYWORDS = keyword.kwlist

Also Python ships with IDLE (which is a simplistic IDE) and although i
find it needs a bit of work to be what GvR initially dreamed, it works
good enough to get you by. I always say, you must use the correct tool
for the job, and syntax hilight is a "must have" to avoid these
accidents.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web