<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Looking at the arguments regarding rendering existing code non-PEP-8-compliant, I think if we were to make this change it should be made in Python 4.0, or whatever the next backwards-incompatible version will be.<div><br></div><div>However, personally I disagree with the fundamental assertion that ALL_CAPS is always ugly. In my humble opinion, when used sparingly (as it is according to PEP 8), they make for a good distinguisher from regular_variables or ClassNames.</div><div><br></div><div>Since python doesn’t have a “const” or “final” keyword like many strongly typed languages, IDEs would otherwise have a hard time distinguishing between constants and variables. (Although it’s up for debate whether it’s important to developers if this disambiguation is present.)</div><div><br><div id="AppleMailSignature" dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On Jan 4, 2019, at 7:58 PM, Abe Dillon <<a href="mailto:abedillon@gmail.com">abedillon@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">>> I will often use a module-level constant<br></span><span class="gmail-im" style="color:rgb(80,0,80)">>> for a file or path name; within the module, it is deliberately treated<br></span><span class="gmail-im" style="color:rgb(80,0,80)">>> as a constant, but if you import the module somewhere else, you could<br></span><span class="gmail-im" style="color:rgb(80,0,80)">>> reassign it before calling any functions in the module, and they'll<br></span><span class="gmail-im" style="color:rgb(80,0,80)">>> all use the changed path.<br></span><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> 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.<br></span><span class="gmail-im" style="color:rgb(80,0,80)">></span><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>Yeah. By naming it in all caps. That's exactly how that's communicated. Example:<br><a href="https://github.com/Rosuav/shed/blob/master/emotify.py#L6" rel="noreferrer" target="_blank">https://github.com/Rosuav/shed/blob/master/emotify.py#L6</a><br>By default, it's calculated from __file__, but if an external caller<br>wants to change this, it's most welcome to. Since it's in all-caps,<br>you don't have to worry about it being changed or mutated during the<br>normal course of operation.</blockquote><div><br></div><div>You made EMOTE_PATH all caps signifying it's a constant, then added a comment saying that it "Can be overwritten prior to calling get_emote_list".<br><br>So not only was your naming convention, on its own, insufficient to explain the API of your code, but you're completely violating PEP-8 because your using the constancy convention on something that's <b>not</b> constant. That's 100% counterintuitive. You subvert the <b>one thing</b> that all-caps is supposed to communicate.<br><br>My whole point is that the thing that all-caps communicates: "you shouldn't change this", is the default assumption for pretty-much every variable you encounter, so it's really not that helpful. If you snooped around and found that the pandas module had a variable called "cucumber" that doesn't appear in the docs at all, would you assume that it's kosher to assign a value to pandas.cucumber?<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Well, then, no, that's not "it's up to you". Something mandated by a<br>style guide is not a tool in your toolbox</blockquote><div>Yes, and PEP-8 being the de-facto style guide for Python is the starting place for many mandatory Python style guides, which is why I'm arguing to remove the all caps BS from it.</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But if you leave that part out, then yes, 'final' becomes a<br>tool that you may use if you wish, or ignore if you wish.</blockquote>Do you think we should add "final", "private", etc. to Python? The point was that such things are clearly not necessary, yet if you suggest removing them, you'll get the exact same "might as well keep it in the toolbox" reaction or worse.<br><br>The code style guides at my work aren't unique, they've been recycled for decades. It's like day-light savings time. People have some vague notion that it might have been a good idea in the past and now we just keep going through the motions even though it makes no sense. You just can't shake the notion that somehow, typing in all caps is a great way to convey information in code, when it's an extremely obnoxious means of conveying information in any other written form.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 4, 2019 at 6:23 PM Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jan 5, 2019 at 11:09 AM Abe Dillon <<a href="mailto:abedillon@gmail.com" target="_blank">abedillon@gmail.com</a>> wrote:<br>
>><br>
>> Just to be clear here: you're trying to say that the ALL_CAPS_NAME<br>
>> convention is unnecessary, but you don't use constants. That kinda<br>
>> weakens your argument a bit :)<br>
><br>
><br>
> 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?!?!<br>
><br>
> It's all Stockholm syndrome.<br>
<br>
The fact that the all-caps convention is used differently (even<br>
wrongly) in your current Java employment doesn't really impact this.<br>
<br>
>> The whole point of the all-caps globals is to tell you a lot about what they are.<br>
><br>
> 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.<br>
><br>
>> I will often use a module-level constant<br>
>> for a file or path name; within the module, it is deliberately treated<br>
>> as a constant, but if you import the module somewhere else, you could<br>
>> reassign it before calling any functions in the module, and they'll<br>
>> all use the changed path.<br>
><br>
> 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.<br>
><br>
<br>
Yeah. By naming it in all caps. That's exactly how that's communicated. Example:<br>
<br>
<a href="https://github.com/Rosuav/shed/blob/master/emotify.py#L6" rel="noreferrer" target="_blank">https://github.com/Rosuav/shed/blob/master/emotify.py#L6</a><br>
<br>
By default, it's calculated from __file__, but if an external caller<br>
wants to change this, it's most welcome to. Since it's in all-caps,<br>
you don't have to worry about it being changed or mutated during the<br>
normal course of operation.<br>
<br>
>> It's up to you whether you actually use the all-caps convention in<br>
>> your own code or not, but IMO it is an extremely useful convention to<br>
>> have in the toolbox, and should be kept.<br>
><br>
> My boss would say:<br>
>><br>
>> It's up to you whether you actually use final in<br>
>> your own code or not, but IMO it is an extremely useful tool to<br>
>> have in the toolbox, and should be kept. (and also you have to use it because it's in the style guide)<br>
><br>
<br>
Well, then, no, that's not "it's up to you". Something mandated by a<br>
style guide is not a tool in your toolbox, it's a requirement of the<br>
project. But if you leave that part out, then yes, 'final' becomes a<br>
tool that you may use if you wish, or ignore if you wish. (Personally,<br>
I would ignore that one, with the exception of "public static final"<br>
as an incantation for "class-level constant".)<br>
<br>
ChrisA<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>Python-ideas mailing list</span><br><span><a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a></span><br><span><a href="https://mail.python.org/mailman/listinfo/python-ideas">https://mail.python.org/mailman/listinfo/python-ideas</a></span><br><span>Code of Conduct: <a href="http://python.org/psf/codeofconduct/">http://python.org/psf/codeofconduct/</a></span><br></div></blockquote></div></body></html>