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

Thu Jan 31 08:55:49 EST 2019

You cited articles, but all of them in the context of reading prose, not
code.
What I was asking where papers describing controlled experiments with a
good cross section of programmers with different skill levels against a
good cross-section of different project and team sizes.
Reading code has some similarity to reading prose, for sure, but let's not
forget that code is actually symbolic language more akin to math and logic
that "tries" to read like prose.

Also, there is the issue of tradition and log embedded traditions for
naming constants like these that make such change violate the time-honoured
goal of "least-astonishment". Professional programmers usually work/worked
previously in several languages, and most of the usual ones follow this
style

*Ruby:*
Ruby style guide as per rubocop says to use SCREAMING_SNAKE_CASE for
constants.

*Java:*

The names of variables declared class constants and of ANSI constants
should be all uppercase with words separated by underscores ("_"). (ANSI
constants should be avoided, for ease of debugging.)

*C:*
Multiple style guides, mostly derived from K&R, for example, the linux
kernel style guide is clear:
Names of macros defining constants and labels in enums are capitalized.

*Javascript: *
Also multiple competing style guides, but in general the consensus seems to
be that *exported *consts must be capitalized

*Go:*
The exception here (as usual in Go). Constants should be Camel Case, with
lower caps initial for symbols that are not the exported outside the
current package, and initial upper case for exported symbols.

*R:*
The chaos, do whatever the code base you're working with seems to follow as
style

Those are the languages that most most python programmers are likely to
have to work along with python, and as you can see, with the exception of
Go and R, most of them have exactly the same
Let's also not forget the humongous amount of POSIX constants that are
defined as ALL_CAPS, and that we definitely shouldn't be rewriting in
another style.

Best,
Marcos Eliziario

Em qua, 30 de jan de 2019 às 19:22, Abe Dillon <abedillon at gmail.com>
escreveu:

> > Capitalizing constants may be slightly harder to read but constants in
> code are the minority and emphasizing them is precisely the point.
>
> The question I'm trying to get everyone to actually think about:
>
> Is the communication of constancy via ALL CAPS so important that it must
> be in PEP-8 despite the documented harm that all caps does to readability?
>
>
> ttps://www.mity.com.au/blog/writing-readable-content-and-why-all-caps-is-so-hard-to-read
> <https://www.mity.com.au/blog/writing-readable-content-and-why-all-caps-is-so-hard-to-read>
> https://en.wikipedia.org/wiki/All_caps#Readability
> https://uxmovement.com/content/all-caps-hard-for-users-to-read/
> https://practicaltypography.com/all-caps.html
>
> I've gotten many responses that seem like a knee-jerk reaction in favor of
> the status quo. I get the sense people "like" all caps because they've been
> conditioned to believe it conveys important information, but they haven't
> taken the time to really consider how valid that belief is.
>
> Consider that math.pi and math.e are constants that are not all caps,
> have you ever been tempted to re-bind those variables? Do you seriously
> worry that those variables are going to be re-bound by other code?
> Functions and classes are essentially constants that aren't all caps, yet
> nobody gets confused about whether or not to re-bind those, or if other
> code will rebind them.
>
> If socket.AF_INET6 were socket.af_inet6 would you consider re-binding
> that variable? Would you be worried that other code will re-bind it? Can
> you measure the value of the information conveyed by all-caps? Are you so
> sure that it's as important as you think?
>
> I've gotten a lot of responses like, "If you don't like it just ignore
> PEP-8, it's not mandatory".
> A) It is mandatory in many cases.
> B) We could just as easily NOT prescribe all caps in PEP-8 but still allow
> it. In other words: you can use all caps if you want to but it's not
> mandatory or in PEP-8. I would like to discourage its use, but we don't
> have to go so far. That way nobody has to violate PEP-8.
>
>
> On Wed, Jan 30, 2019 at 2:01 PM Bruce Leban <bruce at leban.us> wrote:
>
>> Text in color or against black backgrounds is harder to read than black
>> on white.
>> See for example:
>> https://trevellyan.biz/graphic-design-discussion-how-color-and-contrast-affect-readability-2/
>>
>> Text where different words in the same sentence are in different colors
>> is even harder to read.
>>
>> And I think we should totally ban anyone on the web from putting light
>> gray text on a lighter gray background
>> (see https://www.wired.com/2016/10/how-the-web-became-unreadable/ for a
>> good discussion).
>>
>> Or to say that another way:
>> I think we should totally ban anyone on the web from putting light gray
>> text on a lighter gray background!!
>>
>> But many of us use editors that use color for syntax highlighting and we
>> do that because projecting semantics onto the color axis works for us. So
>> we don't ban colorizing text and we shouldn't.
>>
>> Capitalizing constants may be slightly harder to read but constants in
>> code are the minority and emphasizing them is precisely the point.
>>
>> I'm MINUS_ONE on changing PEP 8. Make your own styleguide if you don't
>> want to follow PEP 8 in your code.
>>
>> --- Bruce
>>
>>
>>
>>
>> On Wed, Jan 30, 2019 at 11:48 AM Abe Dillon <abedillon at gmail.com> wrote:
>>
>>> > Is it that really obnoxious?
>>>
>>> EXTREMELY!
>>>
>>> >  Does using upper case for constants measurably slows down coders? Can
>>> you cite the actual papers describing such experiments that lead to this
>>> conclusion ?
>>>
>>>
>>> https://www.mity.com.au/blog/writing-readable-content-and-why-all-caps-is-so-hard-to-read
>>> https://en.wikipedia.org/wiki/All_caps#Readability
>>> https://uxmovement.com/content/all-caps-hard-for-users-to-read/
>>> https://practicaltypography.com/all-caps.html
>>>
>>> > from my experience having a visual clue that a value is a constant or
>>> an enum is something pretty useful.
>>>
>>> Do you have any proof that it's useful? Have you ever been tempted to
>>> modify math.pi or math.e simply because they're lower case? Have you ever
>>> stopped to wonder if those values change?
>>>
>>> If the socket library used packet_host, packet_broadcast, etc. instead
>>> of PACKET_HOST, PACKET_BROADCAST, ETC. would you be confused about
>>> whether it's a good idea to rebind those variables? Would you be tempted to
>>> write the line of code: socket.packet_host = x?
>>>
>>> It seems to me that nobody is actually considering what I'm actually
>>> talking about very carefully. They just assume that because all caps is
>>> used to convey information that information is actually important. Not just
>>> important, but important enough that it should be in PEP-8. They say I
>>> should just violate PEP-8 because it's not strictly enforced. It is
>>> strictly enforced in workplaces. I don't see why it can't be the other way
>>> around: PEP-8 doesn't say to use all caps, but if you want to it's OK.
>>>
>>> > Surely, I'd hate reading a newspaper article where the editor
>>> generously sprinkled upper case words everywhere
>>>
>>> Exactly. If it's an eye-sore in every other medium, then it seems likely
>>> to me, the only reason programmers don't consider it an eye-sore is they've
>>> become inured to it.
>>>
>>> > but analogies only go so far, reading code have some similarities with
>>> reading prose, but still is not the same activity.
>>>
>>> CAN you articulate what is DIFFERENT about READING code that makes the
>>> ALL CAPS STYLE less offensive?
>>>
>>> On Tue, Jan 29, 2019 at 6:09 PM Marcos Eliziario <
>>> marcos.eliziario at gmail.com> wrote:
>>>
>>>> Is it that really obnoxious? Does using upper case for constants
>>>> measurably slows down coders? Can you cite the actual papers describing
>>>> such experiments that lead to this conclusion ?
>>>> Because, from my experience having a visual clue that a value is a
>>>> constant or an enum is something pretty useful.
>>>> Surely, I'd hate reading a newspaper article where the editor
>>>> generously sprinkled upper case words everywhere, but analogies only go so
>>>> far, reading code have some similarities with reading prose, but still is
>>>> not the same activity.
>>>>
>>>> Best,
>>>> Marcos Eliziario
>>>>
>>>>
>>>>
>>>> Em ter, 29 de jan de 2019 às 20:30, Cameron Simpson <cs at cskk.id.au>
>>>> escreveu:
>>>>
>>>>> On 29Jan2019 15:44, Jamesie Pic <jpic at yourlabs.org> wrote:
>>>>> >On Fri, Jan 4, 2019 at 10:07 PM Bernardo Sulzbach
>>>>> ><bernardo at bernardosulzbach.com> wrote:
>>>>> >> I'd suggest violating PEP-8 instead of trying to change it.
>>>>> >
>>>>> >TBH even my bash global environment variables tend to become more and
>>>>> >more lowercase ...
>>>>>
>>>>> If you mean _exported_ variables, then this is actually a really bad
>>>>> idea.
>>>>>
>>>>> The shell (sh, bash, ksh etc) makes no enforcement about naming for
>>>>> exported vs unexported variables. And the exported namespace ($PATH
>>>>> etc)
>>>>> is totally open ended, because any programme might expect arbitrary
>>>>> optional exported names for easy tuning of defaults.
>>>>>
>>>>> So, you think, since I only use variables I intend and only export
>>>>> variables I plan to, I can do what I like. Example script:
>>>>>
>>>>>   a=1
>>>>>   b=2
>>>>>   export b
>>>>>
>>>>> So $b is now exported to subcommands, but not $a.
>>>>>
>>>>> However: the "exported set" is initially the environment you inherit.
>>>>> Which means:
>>>>>
>>>>> Any variable that _arrives_ in the environment is _already_ in the
>>>>> exported set. So, another script:
>>>>>
>>>>>   a=1
>>>>>   b=2
>>>>>   # not exporting either
>>>>>
>>>>> If that gets called from the environment where you'd exported $b (eg
>>>>> from the first script, which could easily be your ~/.profile or
>>>>> ~/.bashrc), then $b gets _modified_ and _exported_ to subcommands,
>>>>> even
>>>>> though you hadn't asked. Because it came in initially from the
>>>>> environment.
>>>>>
>>>>> This means that you don't directly control what is local to the script
>>>>> and what is exported (and thus can affect other scripts).
>>>>>
>>>>> The _only_ way to maintain sanity is the existing convention: local
>>>>> script variables use lowercase names and exported variables use
>>>>> UPPERCASE names. With that in hand, and cooperation from everyone
>>>>> else,
>>>>> you have predictable and reliable behaviour. And you have a nice
>>>>> visual
>>>>> distinction in your code because you know immediately (by convention)
>>>>> whether a variable is exported or not.
>>>>>
>>>>> By exporting lowercase variables you violate this convention, and make
>>>>> your script environment unsafe for others to use.
>>>>>
>>>>> Do many many example scripts on the web do the reverse: using
>>>>> UPPERCASE
>>>>> names for local script variables? Yes they do, and they do a
>>>>> disservice
>>>>> to everyone.
>>>>>
>>>>> Cheers,
>>>>> Cameron Simpson <cs at cskk.id.au>
>>>>> _______________________________________________
>>>>> 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/
>>>>>
>>>>
>>>>
>>>> --
>>>> Marcos Eliziário Santos
>>>> mobile/whatsapp/telegram: +55(21) 9-8027-0156
>>>> skype: marcos.eliziario at gmail.com
>>>> linked-in : https://www.linkedin.com/in/eliziario/
>>>>
>>>> _______________________________________________
>>>> 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/
>>>>
>>> _______________________________________________
>>> 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/
>>>
>>

-- 
Marcos Eliziário Santos
mobile/whatsapp/telegram: +55(21) 9-8027-0156
skype: marcos.eliziario at gmail.com
linked-in : https://www.linkedin.com/in/eliziario/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190131/70bd9a1c/attachment-0001.html>