[Python-ideas] AMEND PEP-8 TO DISCOURAGE ALL CAPS

[Abe Dillon]

>
> Just to be clear here: you're trying to say that the ALL_CAPS_NAME
> convention is unnecessary, but you don't use constants. That kinda
> weakens your argument a bit :)
>

Just to be clear, I'm currently working in a Java shop where the
code-styles are to use all caps for constants, enums, and class-level
variables. Most classes in our code base declare a class-level "LOG" or
"LOGGER" object. I've found that completely unnecessary. A simple "log"
works just fine. I've never been tempted to write over it. It would be
impossible in Java anyway since the guidelines are to declare everything
"final" (yes... shoot me) anyway. I helped one of the higher-ups in the
company write a Python script and he found the lack of straight-jacket
harnesses extremely distressing. How could you write code without "final"?
or "private"? or type checking?! You have to use consistent white space?!?!

It's all Stockholm syndrome.

The whole point of the all-caps globals is to tell you a lot about what
> they are.

 A lot? The only thing it canonically tells you is to not modify it which
is my default assumption with any variable I didn't declare myself and also
impossible to do in the case of enums.

I will often use a module-level constant
> for a file or path name; within the module, it is deliberately treated
> as a constant, but if you import the module somewhere else, you could
> reassign it before calling any functions in the module, and they'll
> all use the changed path.

Do you communicate that API through the variable name alone? How so? I
would assume any module-level variables are not to be modified unless there
was documentation stating otherwise. You really don't need a obnoxious
shouty convention to tell people not to change things.

It's up to you whether you actually use the all-caps convention in
> your own code or not, but IMO it is an extremely useful convention to
> have in the toolbox, and should be kept.

My boss would say:

>  It's up to you whether you actually use final in
> your own code or not, but IMO it is an extremely useful tool to
> have in the toolbox, and should be kept. (and also you have to use it
> because it's in the style guide)


On Fri, Jan 4, 2019 at 5:41 PM Chris Angelico <rosuav at gmail.com> wrote:

> On Sat, Jan 5, 2019 at 10:29 AM Abe Dillon <abedillon at gmail.com> wrote:
> >>
> >> 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...
>
> Just to be clear here: you're trying to say that the ALL_CAPS_NAME
> convention is unnecessary, but you don't use constants. That kinda
> weakens your argument a bit :)
>
> > 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.
>
> The whole point of the all-caps globals is to tell you a lot about
> what they are. For instance, I will often use a module-level constant
> for a file or path name; within the module, it is deliberately treated
> as a constant, but if you import the module somewhere else, you could
> reassign it before calling any functions in the module, and they'll
> all use the changed path.
>
> We use well-chosen variable names to avoid needing special properties
> or documentation to explain how something is to be used. It's far
> better to distinguish between "thing" and "things" than to have to say
> "thing" and "array_of_thing". The whole "consenting adults" policy has
> to be built on clear indications, and the name of something is a vital
> part of that.
>
> It's up to you whether you actually use the all-caps convention in
> your own code or not, but IMO it is an extremely useful convention to
> have in the toolbox, and should be kept.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190104/60fcc31f/attachment-0001.html>