Do you not have/use syntax highlighting? If not, why not? There's a right and wrong tool for everything. In the case of visually differentiating various kinds of code entities, the IDE is the right tool, all caps is not.

On Fri, Jan 4, 2019 at 1:13 PM Ryan Gonzalez <rymg19@gmail.com> wrote:
IMO it's good to have some sort of visual differentiation between constants and normal values. A lot of camelCase-based style guides use a k prefix (e.g. kMyValue), but Python doesn't use it (other than PascalCase for classes). If there were to be an alternative to ALL_CAPS for constants, I guess maybe it'd also be PascalCase?

That being said, Dart 2 has dropped ALL_CAPS constants from its style guide, and although everyone's survived just fine, I do somewhat miss being able to immediately be able to see where something is coming from solely from the case.

Side note: it seems like ALL_CAPS kind of came from macros being using for constants in C and persisted. 

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/

On Fri, Jan 4, 2019, 1:02 PM Abe Dillon <abedillon@gmail.com wrote:
I keep coming back to this great video about coding style, and one point in particular rings true to me: ALL_CAPS_IS_OBNOXIOUS

It destroys the visual flow of code and for what? To signify a global, constant, or Enum? Is that really so important? I don't think so. I think the all caps style has out-lived its usefulness and needs to go the way of the dodo.

The last time I saw all caps used appropriately was in a YouTube comment where some guy was ranting about the communist Jewish banker conspiracy to control the world. In that case, all caps clearly communicated to me that the person was a frothing lunatic (thought find the idea of communist bankers intriguing).

Currently PEP-8 prescribes all caps for constants and uses the all cap variable "FILES" as an example in a different section. It also appears to be the defacto-standard for enums (based on the documentation)

I don't think it's necessary to make any breaking changes. Just pep-8 and (of less importance) spurious documentation examples.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/