Hacker News Reader

Hacker News

Comment by sireat | Hacker News Reader

Full thread

sireat

I am a pretty average Python programmer(5 years teaching, 15 years writing).

I still wonder what was the reasoning for allowing creation of local objects with the same name as builtins.

Okay it can be nice to redefine pprint as print I suppose.

Still how many sum, list, min, max, dict(!) have been erroneously redefined in beginner tutorials and beginner code.

From my experience sum and list suffer the most.

Sure there are linters that will warn you but there should be a setting for the interpreter (as in -Werror in GCC) to disallow this silliness.

View on HN

No idea what their actual reasoning is, but here's how I think about it:

This is better for novices, because otherwise you create a whole bunch of land mines for people who are desperately trying to get something done. If they aren't aware of the built-in then they aren't trying to use it. Insisting that they become aware of something they don't want right then will be frustrating.

It's also better for experts, in that they're generally aware they're overriding a built-in and are doing it on purpose, and if not they'll have an IDE or linter reminding them.

To me, I see tooling as a spectrum from supportive to controlling. Python is very much on the supportive end. It feels controlling when I get interrupted because some programmer who has never met me programmed a tool to insist I do things their way. That would very much include insisting I respect a bunch of names they decided long ago to put in the global namespace.

Python itself doesn’t disallow this because there are quite a lot of builtins with useful names - for example, `file`, `id`, and `hash` to name a few. Disallowing setting these would be tantamount to adding a bunch of new keywords to the language, which they’ve been quite loathe to do in general.

A good linter will catch these, so in production environments you usually don’t run into issues. I agree that it can be a beginner trap though!

Consider what'd happen whenever a new builtin gets added.

I think linters are really effective to figure out such issues in professional code.

For students for example, I'll have to agree. Maybe having a flag or environment variable that teachers can set up for it would be a nice idea. You should start a thread on the python-ideas mailing list about this, and it might get somewhere :)

   False = None = True

Is probably the most ridiculous thing for a language to support. And yet...

... and yet, it is a SyntaxError. False = True = None works in Python 2, and it is just because the separate Boolean type was a late addition.

Oops, yep. I've seen somebody overwrite False in the wild, but I thought None was writable too. Glad for that smidgen of sanity...

    $ python2 -c 'False = None = True'
      File "<string>", line 1
    SyntaxError: cannot assign to None

    $ python3 -c 'False = None = True'
      File "<string>", line 1
    SyntaxError: cannot assign to False

Reply on news.ycombinator.com