How do you propose, instead, for the constantness of something to be indicated?
That's a good question. I honestly don't use constants all that much, I
like to move such things out to config files. For a constant like math.pi,
it's never been caps, yet people know it's not a great idea to change it.
There are a lot of tools to indicate constantness:
1) provide a property to access an otherwise _plz_dont_touch_variable
2) Use an Enum
3) Use documentation to say: treat this as constant
4) Rely upon consenting adults to not change variables outside of scope.
It's weird to manipulate math.pi because it's in a separate module.
I stopped using all caps a long time ago and it just hasn't created a
problem because manipulating global variables without knowing what they are
is such a bad idea to begin with.
On Fri, Jan 4, 2019 at 5:16 PM Chris Angelico
On Sat, Jan 5, 2019 at 10:10 AM Abe Dillon
wrote: So you're saying we should prefer a future where it's an inconsistent
mess?
No. And please don't straw man. It's a very annoying argumentative tactic. I prefer a future where all caps aren't used. I understand that the change I propose won't magically transport us there, but I don't think it justifies encouraging all caps. As it is, the mix of all caps, camel-case, and snake-case IS and inconsistent and visual mess. Discouraging all caps will only result in a diminishing occurrence of all caps.
it's.more important to have a standard than what that standard is. And we do have a strong standard today.
I understand that there's a barrier to change, but there's also a circular logic to resisting change because adhering to a standard is good.
How bad would it really be to remove the line about constants being all caps from PEP-8?
How do you propose, instead, for the constantness of something to be indicated?
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/