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

Groups > comp.lang.python > #11476 > 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? Chris Angelico <rosuav@gmail.com> - 2011-08-15 23:15 +0100
    Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-16 11:32 +1000
      Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-15 23:23 -0400
        Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-16 15:15 +1000
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 10:13 -0400
            Re: Why no warnings when re-assigning builtin names? rantingrick <rantingrick@gmail.com> - 2011-08-16 08:44 -0700
              Re: Why no warnings when re-assigning builtin names? Andrew Berg <bahamutzero8825@gmail.com> - 2011-08-16 12:23 -0500
          Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-16 16:12 +0100
          Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 08:41 -0700
            Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 17:11 +0000
              Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 10:48 -0700
              Re: Why no warnings when re-assigning builtin names? Tim Chase <python.list@tim.thechases.com> - 2011-08-16 13:34 -0500
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 11:31 -0400
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 11:38 -0400
          Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 09:19 -0700
            Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 17:11 +0000
              Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 10:43 -0700
                Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 18:56 +0000
                  Re: Why no warnings when re-assigning builtin names? Terry Reedy <tjreedy@udel.edu> - 2011-08-16 19:32 -0400
                    Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 23:49 +0000
                      Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 01:02 +0100
                        Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 01:35 +0000
                          Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 08:27 +0100
                            Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 16:33 +0000
                      Re: Why no warnings when re-assigning builtin names? Terry Reedy <tjreedy@udel.edu> - 2011-08-16 22:10 -0400
              Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-16 19:23 +0100
          Re: Why no warnings when re-assigning builtin names? Tim Chase <python.list@tim.thechases.com> - 2011-08-16 11:10 -0500
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 12:32 -0400
            Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-17 11:29 +1000
              Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 22:16 -0400
          Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-16 10:07 -0700
          Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-16 17:11 +0000
            Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-17 10:58 +1000
              Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 03:17 +0000
                Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-17 18:15 +1000
                  Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 16:33 +0000
                    Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-17 10:36 -0700
                      Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 17:36 +0000
                        Re: Why no warnings when re-assigning builtin names? Ethan Furman <ethan@stoneleaf.us> - 2011-08-17 11:13 -0700
                          Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 18:09 +0000
                    Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 18:42 +0100
                      Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-17 17:38 +0000
                        Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 19:02 +0100
                    Re: Why no warnings when re-assigning builtin names? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-18 10:36 +1000
              Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-17 08:34 +0100
          RE: Why no warnings when re-assigning builtin names? "Gerrat Rickert" <grickert@coldstorage.com> - 2011-08-16 13:15 -0400
          Re: Why no warnings when re-assigning builtin names? Terry Reedy <tjreedy@udel.edu> - 2011-08-16 19:29 -0400
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 20:18 -0400
          Re: Why no warnings when re-assigning builtin names? Terry Reedy <tjreedy@udel.edu> - 2011-08-16 22:15 -0400
          Re: Why no warnings when re-assigning builtin names? Philip Semanchuk <philip@semanchuk.com> - 2011-08-16 22:51 -0400
          RE: Why no warnings when re-assigning builtin names? "Gerrat Rickert" <grickert@coldstorage.com> - 2011-08-17 09:30 -0400
      Re: Why no warnings when re-assigning builtin names? Chris Angelico <rosuav@gmail.com> - 2011-08-16 09:16 +0100
    Re: Why no warnings when re-assigning builtin names? Chris Torek <nospam@torek.net> - 2011-08-31 21:30 +0000
      Re: Why no warnings when re-assigning builtin names? Seebs <usenet-nospam@seebs.net> - 2011-08-31 21:57 +0000

Page 1 of 3  [1] 2 3  Next page →

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

On Mon, Aug 15, 2011 at 10:52 PM, Gerrat Rickert
<grickert@coldstorage.com> 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.

It's actually masking, not reassigning. That may make it easier or
harder to resolve the issue.

If you want a future directive that deals with it, I'd do it the other
way - from __future__ import mask_builtin_warning or something - so
the default remains as it currently is. But this may be a better job
for a linting script.

ChrisA

[toc] | [next] | [standalone]

#11495

On Tue, 16 Aug 2011 08:15 am Chris Angelico wrote:

> On Mon, Aug 15, 2011 at 10:52 PM, Gerrat Rickert
> <grickert@coldstorage.com> 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.
> 
> It's actually masking, not reassigning. That may make it easier or
> harder to resolve the issue.

The usual term is "shadowing builtins", and it's a feature, not a bug :)


> If you want a future directive that deals with it, I'd do it the other
> way - from __future__ import mask_builtin_warning or something - so
> the default remains as it currently is. But this may be a better job
> for a linting script.

Agreed. It's a style issue, nothing else. There's nothing worse about:

def spam(list):
    pass

compared to

class thingy: pass

def spam(thingy):
    pass

Why should built-ins be treated as more sacred than your own objects?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#11501

On Aug 15, 2011, at 9:32 PM, Steven D'Aprano wrote:

> On Tue, 16 Aug 2011 08:15 am Chris Angelico wrote:
> 
>> If you want a future directive that deals with it, I'd do it the other
>> way - from __future__ import mask_builtin_warning or something - so
>> the default remains as it currently is. But this may be a better job
>> for a linting script.
> 
> Agreed. It's a style issue, nothing else. There's nothing worse about:
> 
> def spam(list):
>    pass
> 
> compared to
> 
> class thingy: pass
> 
> def spam(thingy):
>    pass
> 
> Why should built-ins be treated as more sacred than your own objects?

Because built-ins are described in the official documentation as having a specific behavior, while my objects are not.

Yes, it can be useful to replace some of the builtins with one's own implementation, and yes, doing so fits in with Python's "we're all consenting adults" philosophy. But replacing (shadowing, masking -- call it what you will) builtins is not everyday practice. On the contrary, as the OP Gerrat pointed out, it's most often done unwittingly by newcomers to the language who have no idea that they've done anything out of the ordinary or potentially confusing. 

If a language feature is most often invoked accidentally without knowledge of or regard for its potential negative consequences, then it might be worth making it easier to avoid those accidents. 

bye,
Philip

[toc] | [prev] | [next] | [standalone]

#11507

On Tue, 16 Aug 2011 01:23 pm Philip Semanchuk wrote:

> 
> On Aug 15, 2011, at 9:32 PM, Steven D'Aprano wrote:
> 
>> On Tue, 16 Aug 2011 08:15 am Chris Angelico wrote:
>> 
>>> If you want a future directive that deals with it, I'd do it the other
>>> way - from __future__ import mask_builtin_warning or something - so
>>> the default remains as it currently is. But this may be a better job
>>> for a linting script.
>> 
>> Agreed. It's a style issue, nothing else. There's nothing worse about:
>> 
>> def spam(list):
>>    pass
>> 
>> compared to
>> 
>> class thingy: pass
>> 
>> def spam(thingy):
>>    pass
>> 
>> Why should built-ins be treated as more sacred than your own objects?
> 
> Because built-ins are described in the official documentation as having a
> specific behavior, while my objects are not.

*My* objects certainly are, because I write documentation for my code. My
docs are no less official than Python's docs.

You can shadow anything. Sometimes shadowing is safe, sometimes it isn't. I
don't see why we should necessarily fear safe shadowing of built-ins more
than we fear unsafe shadowing of non-built-ins.

(I'm not even convinced that making None a reserved word was the right
decision.)

A warning that is off by default won't help the people who need it, because
they don't know enough to turn the warning on. A warning that is on by
default will be helpful to the newbie programmer for the first week or so,
and then will be nothing but an annoyance for the rest of their career.

(For some definition of a week -- some people are slower learners than
others.)


> Yes, it can be useful to replace some of the builtins with one's own
> implementation, and yes, doing so fits in with Python's "we're all
> consenting adults" philosophy. But replacing (shadowing, masking -- call
> it what you will) builtins is not everyday practice. On the contrary, as
> the OP Gerrat pointed out, it's most often done unwittingly by newcomers
> to the language who have no idea that they've done anything out of the
> ordinary or potentially confusing.

Protecting n00bs from their own errors is an admirable aim, but have you
considered that warnings for something which may be harmless could do more
harm than good? Beginners often lack the skill to distinguish between
harmless warnings that can safely be ignored, and fatal errors that need to
be fixed. Even "user friendly" warning or error messages tend to unnerve
some beginner coders.

There's not much we can do about outright errors, except to make sure that
the error string is as useful as possible, but we can avoid overloading
beginners with warnings they don't need to care about:


    WARNING WARNING WARNING WILL ROBINSON, DANGER DANGER DANGER:
    YOUR SISTER'S NAME 'PENNY' SHADOWS THE BRITISH CURRENCY, 
    POTENTIAL AMBIGUITY ALERT DANGER DANGER DANGER!


*wink*

Depending on their personality, you may end up teaching them to ignore
warnings, or a superstitious dread of anything that leads to a warning.
Neither is a good outcome.


> If a language feature is most often invoked accidentally without knowledge
> of or regard for its potential negative consequences, then it might be
> worth making it easier to avoid those accidents.

Perhaps. But I'm not so sure it is worth the cost of extra code to detect
shadowing and raise a warning. After all, the average coder probably never
shadows anything, and for those that do, once they get bitten *once* they
either never do it again or learn how to shadow safely. I don't see it as a
problem.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#11553

On Aug 16, 2011, at 1:15 AM, Steven D'Aprano wrote:

> On Tue, 16 Aug 2011 01:23 pm Philip Semanchuk wrote:
> 
>> 
>> On Aug 15, 2011, at 9:32 PM, Steven D'Aprano wrote:
>> 
>>> On Tue, 16 Aug 2011 08:15 am Chris Angelico wrote:
>>> 
>>>> If you want a future directive that deals with it, I'd do it the other
>>>> way - from __future__ import mask_builtin_warning or something - so
>>>> the default remains as it currently is. But this may be a better job
>>>> for a linting script.
>>> 
>>> Agreed. It's a style issue, nothing else. There's nothing worse about:
>>> 
>>> def spam(list):
>>>   pass
>>> 
>>> compared to
>>> 
>>> class thingy: pass
>>> 
>>> def spam(thingy):
>>>   pass
>>> 
>>> Why should built-ins be treated as more sacred than your own objects?
>> 
>> Because built-ins are described in the official documentation as having a
>> specific behavior, while my objects are not.
> 
> *My* objects certainly are, because I write documentation for my code. My
> docs are no less official than Python's docs.

I'm sure they are no less official to you. But you are you, and then there's...everyone else. =) 

I (and I think most people) give far more credibility to the Python docs than to the documentation of an individual. That's not a reflection on you, it reflects the limits of one person's ability versus organizationally produced docs which are heavily used, discussed, and have been iteratively developed over many years. 


> Sometimes shadowing is safe, sometimes it isn't. 

"Sometimes X is safe and sometimes it isn't" can be said of many, many things, from taking a walk down the street to juggling with knives. But it has little to do with whether or not Python should issue a warning in the specific case we're talking about.


> A warning that is off by default won't help the people who need it, because
> they don't know enough to turn the warning on.

I agree that it wouldn't help the people who need it most (absolute raw newcomers). But you're asserting that once one learned the incantation to enable the theoretical warning we're discussing, one would have graduated to a level where it's no longer useful. That's not the case. There's a lot of ground to cover between "newcomer who has learned about a particular warning" and "coder who regularly shadows builtins on purpose". 

I am an example. I know enough to turn the theoretical warning on, and I would if I could. I have never shadowed a builtin deliberately. I've done it accidentally plenty of times. There are 84 builtins in my version of Python and I don't have them all memorized. The fact that my editor colors them differently is the only thing I have to back up my leaky memory. Not all editors are so gracious.


>> Yes, it can be useful to replace some of the builtins with one's own
>> implementation, and yes, doing so fits in with Python's "we're all
>> consenting adults" philosophy. But replacing (shadowing, masking -- call
>> it what you will) builtins is not everyday practice. On the contrary, as
>> the OP Gerrat pointed out, it's most often done unwittingly by newcomers
>> to the language who have no idea that they've done anything out of the
>> ordinary or potentially confusing.
> 
> Protecting n00bs from their own errors is an admirable aim, but have you
> considered that warnings for something which may be harmless could do more
> harm than good?

Isn't the whole point of a warning to highlight behavior that's not strictly wrong but looks iffy? Sort of, "I can't be sure, but this looks like trouble to me. I hope you know what you're doing". If we are to eschew warnings in cases where they might be highlighting something harmless, then we would have no warnings at all. 

Again, shadowing builtins is not everyday practice. I have been trying to remember if I've ever seen it done deliberately, and I can't remember a case. Now, a comment like that is an invitation for people come out of the woodwork with cases where they found it useful, and I would welcome some examples as I'm sure they'd be interesting. But I think it's safe to say that if you look at random samples of code, builtins are shadowed unintentionally hundreds of times for every time they're shadowed deliberately and usefully. 


>> If a language feature is most often invoked accidentally without knowledge
>> of or regard for its potential negative consequences, then it might be
>> worth making it easier to avoid those accidents.
> 
> Perhaps. But I'm not so sure it is worth the cost of extra code to detect
> shadowing and raise a warning. After all, the average coder probably never
> shadows anything,

One need look no further than the standard library to see a strong counterexample. grep through the Python source for " file =". I see dozens of examples of this builtin being used as a common variable name. I would call contributors to the standard library above-average coders, and we can see them unintentionally shadowing builtins many times.


> and for those that do, once they get bitten *once* they
> either never do it again or learn how to shadow safely.

I have done it plenty of times, never been bitten (thankfully) and still do it by accident now and again. 

You can coerce any example to apply to an argument for or against such a warning, but I think the general case is that Python could reduce unintended consequences by warning when vars erase builtins.  (<=== How many builtins did I use in that sentence?)

Cheers
Philip

[toc] | [prev] | [next] | [standalone]

#11578

On Aug 16, 9:13 am, Philip Semanchuk <phi...@semanchuk.com> wrote:

> "Sometimes X is safe and sometimes it isn't" can be said
> of many, many things, from taking a walk down the street
> to juggling with knives. But it has little to do with
> whether or not Python should issue a warning in the
> specific case we're talking about.

I think any Python n00b should be writing code in n editor that is
"safe for beginners" AND is also teaching tool. IDLE is probably the
best thing a new Python programmer could use. It has syntax hilight,
smart indention, call tips, code completion, a class browser, greping
tools, and more! I do admit the tool is lacking in many areas
(including code base) that would be atrocious to an experienced
Pythonista, however, the tool is perfect for n00bs (and myself and
other pythoinistas use it all the time!)

> There's a lot of ground to cover between "newcomer who has
> learned about a particular warning" and "coder who
> regularly shadows builtins on purpose".

One word: SYNTAX HILIGHT

> I have never shadowed a builtin deliberately. I've done it
> accidentally plenty of times. There are 84 builtins in my
> version of Python and I don't have them all memorized. The
> fact that my editor colors them differently is the only
> thing I have to back up my leaky memory. Not all editors
> are so gracious.

So you have syntax hilight however you still shadow builtins?  Oh
dear, this problem is worse than i initially suspected!

> You can coerce any example to apply to an argument for or
> against such a warning, but I think the general case is
> that Python could reduce unintended consequences by
> warning when vars erase builtins.  (<=== How many builtins
> did I use in that sentence?)

Well let's see:

py> import keyword
py> import __builtin__
py> PY_KWS = keyword.kwlist
py> PY_BLT = dir(globals()['__builtins__'])
py> s = """\
You can coerce any example to apply to an argument for or against such
a warning, but I think the general case is that Python could reduce
unintended consequences by warning when vars erase builtins. """
py> fmtstr = '{0} -> {1}'
py> for word in s.split(' '):
...     if word in PY_BLT:
...         print fmtstr.format('builtin', word)
...     elif word in PY_KWS:
...         print fmtstr.format('KeyWord', word)
...
builtin -> coerce
builtin -> any
builtin -> apply
KeyWord -> for
KeyWord -> or
KeyWord -> is
builtin -> reduce
builtin -> vars

[toc] | [prev] | [next] | [standalone]

#11587

On 2011.08.16 10:44 AM, rantingrick wrote:
> One word: SYNTAX HILIGHT
And I had thought your troll skills had disappeared. Good one.

-- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB

[toc] | [prev] | [next] | [standalone]

#11562

On Tue, Aug 16, 2011 at 3:13 PM, Philip Semanchuk <philip@semanchuk.com> wrote:
> I am an example. I know enough to turn the theoretical warning on, and I would if I could. I have never shadowed a builtin deliberately. I've done it accidentally plenty of times. There are 84 builtins in my version of Python and I don't have them all memorized. The fact that my editor colors them differently is the only thing I have to back up my leaky memory. Not all editors are so gracious.
>

Rather than "turn a warning on" you can "run your code through a
linting script". There are several excellent ones. Add it to your
makefile or test suite; then you get the testing done over _all_ of
your code, instead of waiting until the moment when you actually
execute it.

> One need look no further than the standard library to see a strong counterexample. grep through the Python source for " file =". I see dozens of examples of this builtin being used as a common variable name. I would call contributors to the standard library above-average coders, and we can see them unintentionally shadowing builtins many times.
>

There are several types of shadowing:

1) Deliberate shadowing because you want to change the behavior of the
name. Extremely rare.
2) Shadowing simply by using the name of an unusual builtin (like
'file') in a context where you never use it. Very common.
3) Unintentional shadowing where you create a variable, but then
intend to use the builtin. This is the only one that's a problem.

list = [...]
is not a problem unless you later on use
foo = list(map(...))
which is more common in Python 3 than Python 2, but fortunately, it'll
throw a nice quick error - nobody's going to use list operations on
the normal 'list' type, nor is anybody going to call an instance of
list.

Definitely a job for linting.

ChrisA

[toc] | [prev] | [next] | [standalone]

#11564

Philip Semanchuk wrote:
> On Aug 16, 2011, at 1:15 AM, Steven D'Aprano wrote:
>> Protecting n00bs from their own errors is an admirable aim, but have you
>> considered that warnings for something which may be harmless could do more
>> harm than good?
> 
> Isn't the whole point of a warning to highlight behavior that's not strictly
 > wrong but looks iffy? Sort of, "I can't be sure, but this looks like 
trouble
 > to me. I hope you know what you're doing". 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.

>> Perhaps. But I'm not so sure it is worth the cost of extra code to detect
>> shadowing and raise a warning. After all, the average coder probably never
>> shadows anything,
> 
> One need look no further than the standard library to see a strong
 > counterexample. grep through the Python source for " file =". I see 
dozens
> of examples of this builtin being used as a common variable name. I would
 > call contributors to the standard library above-average coders, and 
we can
 > see them unintentionally shadowing builtins many times.

What makes you think it's unintentional?  file makes a good variable 
name, and if you don't need it to actually open a file there's nothing 
wrong with using it yourself.


>> and for those that do, once they get bitten *once* they
>> either never do it again or learn how to shadow safely.
> 
> I have done it plenty of times, never been bitten (thankfully) and still
 > do it by accident now and again.

Seems to me the real issue is somebody using a builtin, such as str or 
int, and that they somehow manage to do this without realizing, "wait a 
sec', that's one of my variables!"  I don't see that as a problem that 
Python needs to solve.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#11584

On 2011-08-16, Ethan Furman <ethan@stoneleaf.us> wrote:
> What makes you think it's unintentional?

Programming experience.

People *often* do things unintentionally.

> Seems to me the real issue is somebody using a builtin, such as str or 
> int, and that they somehow manage to do this without realizing, "wait a 
> sec', that's one of my variables!"  I don't see that as a problem that 
> Python needs to solve.

I think the word "my" prejudices the case.

Imagine stepping into a large project that uses multiple frameworks and
class libraries and so on.  You know Python but you're new to the project.

Under which circumstance will you have more problems?

1.  There is not a single shadowed built-in in the entire project.
2.  There are dozens of shadowed built-ins based on when the original
programmer felt there wasn't going to be a need for a given built-in
feature, or possibly just didn't know about it.

Also, how easy or hard do you think it will be to debug those problems?
What's your first response going to be if, on a screen which doesn't
contain the word file at all, you try to use the file built-in and you
get some cryptic error?  Are you going to know to go looking for the
shadow right away?

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#11589

Seebs wrote:
> On 2011-08-16, Ethan Furman <ethan@stoneleaf.us> wrote:
>> What makes you think it's unintentional?
> 
> Programming experience.
> 
> People *often* do things unintentionally.
> 
>> Seems to me the real issue is somebody using a builtin, such as str or 
>> int, and that they somehow manage to do this without realizing, "wait a 
>> sec', that's one of my variables!"  I don't see that as a problem that 
>> Python needs to solve.
> 
> I think the word "my" prejudices the case.

But fits in well with the OP.


> Imagine stepping into a large project that uses multiple frameworks and
> class libraries and so on.  You know Python but you're new to the project.
> 
> Under which circumstance will you have more problems?
> 
> 1.  There is not a single shadowed built-in in the entire project.
> 2.  There are dozens of shadowed built-ins based on when the original
> programmer felt there wasn't going to be a need for a given built-in
> feature, or possibly just didn't know about it.

My first course of action would be to learn what I'm patching before I 
patch it.  Scope helps in the case of shadowing; lint helps to give 
warnings about that and other things as well.


> Also, how easy or hard do you think it will be to debug those problems?
> What's your first response going to be if, on a screen which doesn't
> contain the word file at all, you try to use the file built-in and you
> get some cryptic error?  Are you going to know to go looking for the
> shadow right away?

I should have a pretty good clue from the traceback, and a couple prints 
or logs around the offending lines should give me the rest.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#11595

On 08/16/2011 12:11 PM, Seebs wrote:
> Under which circumstance will you have more problems?
>
> 1.  There is not a single shadowed built-in in the entire project.
> 2.  There are dozens of shadowed built-ins based on when the original
> programmer felt there wasn't going to be a need for a given built-in
> feature, or possibly just didn't know about it.

In practice, I've never hit such a snag.  For #2, the only way it 
would impact me is if I did the ill-advised

   from shadowy import *

which might tromp on things I care about.  Otherwise, I'd just do 
something like

   from shadowy import list as shadowy_list, id as shadowy_id

If I'm altering another person's ill-created module, I might 
consider doing a search for builtins and then just simply 
patching the module so that it renamed all the shadowing usages. 
  Unless the author was being particularly obscure (using scope 
to impact where a builtin meant the builtin, and other scopes to 
shadow the builtins), most authors are pretty consistent in their 
shadowing (usually ignorant of the fact they're shadowing the 
builtin) which makes the search-n-replace an easy tweak.

-tkc

[toc] | [prev] | [next] | [standalone]

#11566

On Aug 16, 2011, at 11:12 AM, Chris Angelico wrote:

> On Tue, Aug 16, 2011 at 3:13 PM, Philip Semanchuk <philip@semanchuk.com> wrote:
> 
>> One need look no further than the standard library to see a strong counterexample. grep through the Python source for " file =". I see dozens of examples of this builtin being used as a common variable name. I would call contributors to the standard library above-average coders, and we can see them unintentionally shadowing builtins many times.
>> 
> 
> There are several types of shadowing:
> 
> 1) Deliberate shadowing because you want to change the behavior of the
> name. Extremely rare.
> 2) Shadowing simply by using the name of an unusual builtin (like
> 'file') in a context where you never use it. Very common.
> 3) Unintentional shadowing where you create a variable, but then
> intend to use the builtin. This is the only one that's a problem.

Yes, but before you get to #3 you have to go through #2. The way I see it, #2 is setting a trap, #3 is actually stepping in it. I don't want to do either. Neither do I like working with code that has set trap #2 for me.


Cheers
Philip

[toc] | [prev] | [next] | [standalone]

#11567

On Aug 16, 2011, at 11:41 AM, Ethan Furman wrote:

> Philip Semanchuk wrote:
>> On Aug 16, 2011, at 1:15 AM, Steven D'Aprano wrote:
>>> Protecting n00bs from their own errors is an admirable aim, but have you
>>> considered that warnings for something which may be harmless could do more
>>> harm than good?
>> Isn't the whole point of a warning to highlight behavior that's not strictly
> > wrong but looks iffy? Sort of, "I can't be sure, but this looks like trouble
> > to me. I hope you know what you're doing". 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. 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.


>>> Perhaps. But I'm not so sure it is worth the cost of extra code to detect
>>> shadowing and raise a warning. After all, the average coder probably never
>>> shadows anything,
>> One need look no further than the standard library to see a strong
> > counterexample. grep through the Python source for " file =". I see dozens
>> of examples of this builtin being used as a common variable name. I would
> > call contributors to the standard library above-average coders, and we can
> > see them unintentionally shadowing builtins many times.
> 
> What makes you think it's unintentional?  file makes a good variable name, and if you don't need it to actually open a file there's nothing wrong with using it yourself.

"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". 


>>> and for those that do, once they get bitten *once* they
>>> either never do it again or learn how to shadow safely.
>> I have done it plenty of times, never been bitten (thankfully) and still
> > do it by accident now and again.
> 
> Seems to me the real issue is somebody using a builtin, such as str or int, and that they somehow manage to do this without realizing, "wait a sec', that's one of my variables!"  

Yes


> 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.

Cheers
Philip

[toc] | [prev] | [next] | [standalone]

#11572

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~

[toc] | [prev] | [next] | [standalone]

#11585

On 2011-08-16, Ethan Furman <ethan@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.

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

-W ignore

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#11588

Seebs wrote:
> On 2011-08-16, Ethan Furman <ethan@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'.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#11601

On 2011-08-16, Ethan Furman <ethan@stoneleaf.us> wrote:
> Seebs wrote:
>> 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'.

Huh!

That is a really good point, which I had not considered.  I still prefer
to get warnings, but... Hmm.

I wonder whether there's a way to mitigate the cost of these things by
messing with -W settings, such that runtime that wants to be fast can
omit the checks, but the default could still be to, well, prevent likely
errors.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#11622

On 8/16/2011 2:56 PM, Seebs wrote:

> I wonder whether there's a way to mitigate the cost of these things by
> messing with -W settings, such that runtime that wants to be fast can
> omit the checks, but the default could still be to, well, prevent likely
> errors.

Warning messages have a cost even if suppressed.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#11625

On 2011-08-16, Terry Reedy <tjreedy@udel.edu> wrote:
> On 8/16/2011 2:56 PM, Seebs wrote:
>> I wonder whether there's a way to mitigate the cost of these things by
>> messing with -W settings, such that runtime that wants to be fast can
>> omit the checks, but the default could still be to, well, prevent likely
>> errors.

> Warning messages have a cost even if suppressed.

Yes, but is it a *significant* cost?  My assumption is that the suppression
would be of checking, not just of displaying messages.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web