4 ms·

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

by sireat 5y ago

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.

tusharsadhwani 5y ago
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 :)
nneonneo 5y ago
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!
wpietri 5y ago
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.
int_19h 5y ago
Consider what'd happen whenever a new builtin gets added.
klyrs 5y ago
False = None = True Is probably the most ridiculous thing for a language to support. And yet...
- anttihaapala 5y ago
  ... 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.
  - klyrs 5y ago
    Oops, yep. I've seen somebody overwrite False in the wild, but I thought None was writable too. Glad for that smidgen of sanity...
- wmanley 5y ago
  $ 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

by sireat 5y ago

tusharsadhwani 5y ago

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 :)

nneonneo 5y ago

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!

wpietri 5y ago

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.

int_19h 5y ago

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

klyrs 5y ago

False = None = True Is probably the most ridiculous thing for a language to support. And yet...

anttihaapala 5y ago
... 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.
- klyrs 5y ago
  Oops, yep. I've seen somebody overwrite False in the wild, but I thought None was writable too. Glad for that smidgen of sanity...
wmanley 5y ago
$ 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