<div dir="ltr"><div dir="ltr"><div dir="ltr">Text in color or against black backgrounds is harder to read than black on white.</div><div dir="ltr">See for example: <a href="https://trevellyan.biz/graphic-design-discussion-how-color-and-contrast-affect-readability-2/">https://trevellyan.biz/graphic-design-discussion-how-color-and-contrast-affect-readability-2/</a></div><div dir="ltr"><br></div><div dir="ltr">Text where different words in the same sentence are in different colors is even harder to read.</div><div dir="ltr"><br></div><div dir="ltr">And I think we should totally ban anyone on the web from putting light gray text on a lighter gray background</div><div dir="ltr">(see <a href="https://www.wired.com/2016/10/how-the-web-became-unreadable/">https://www.wired.com/2016/10/how-the-web-became-unreadable/</a> for a good discussion).</div><div dir="ltr"><br></div><div dir="ltr">Or to say that another way: <br><div><font style="background-color:rgb(238,238,238)" color="#999999">I think we should totally ban anyone on the web from putting light gray text on a lighter gray background!!</font></div><div><br></div><div>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.</div><div><br></div><div>Capitalizing constants may be slightly harder to read but constants in code are the minority and emphasizing them is precisely the point.</div><div><br></div><div>I'm MINUS_ONE on changing PEP 8. Make your own styleguide if you don't want to follow PEP 8 in your code.</div><div> <br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="arial, helvetica, sans-serif">--- Bruce<br></font><div><div><br></div></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 30, 2019 at 11:48 AM Abe Dillon <<a href="mailto:abedillon@gmail.com">abedillon@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"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">> Is it that really obnoxious?<br><br>EXTREMELY!<br><br>>  Does using upper case for constants measurably slows down coders? Can you cite the actual papers describing such experiments that lead to this conclusion ? <br><br><a href="https://www.mity.com.au/blog/writing-readable-content-and-why-all-caps-is-so-hard-to-read" target="_blank">https://www.mity.com.au/blog/writing-readable-content-and-why-all-caps-is-so-hard-to-read</a></div><div dir="ltr"><a href="https://en.wikipedia.org/wiki/All_caps#Readability" target="_blank">https://en.wikipedia.org/wiki/All_caps#Readability</a><br><a href="https://uxmovement.com/content/all-caps-hard-for-users-to-read/" target="_blank">https://uxmovement.com/content/all-caps-hard-for-users-to-read/</a><br><a href="https://practicaltypography.com/all-caps.html" target="_blank">https://practicaltypography.com/all-caps.html</a><br><br>> from my experience having a visual clue that a value is a constant or an enum is something pretty useful.<br><br>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?<br><br>If the <font face="monospace, monospace">socket</font> library used <font face="monospace, monospace">packet_host</font>, <font face="monospace, monospace">packet_broadcast</font>, etc. instead of <font face="monospace, monospace">PACKET_HOST</font>, <font face="monospace, monospace">PACKET_BROADCAST</font>, <font face="monospace, monospace">ETC</font>. 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: <font face="monospace, monospace">socket.packet_host = x</font>?<br><br>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.<br><br>> Surely, I'd hate reading a newspaper article where the editor generously sprinkled upper case words everywhere<br><br>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.<br><br>> but analogies only go so far, reading code have some similarities with reading prose, but still is not the same activity. <br><br>CAN you articulate what is DIFFERENT about READING code that makes the ALL CAPS STYLE less offensive?<br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 29, 2019 at 6:09 PM Marcos Eliziario <<a href="mailto:marcos.eliziario@gmail.com" target="_blank">marcos.eliziario@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"><div dir="ltr">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 ? <br>Because, from my experience having a visual clue that a value is a constant or an enum is something pretty useful. <br>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. <br><br>Best,<br>Marcos Eliziario<br><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter, 29 de jan de 2019 às 20:30, Cameron Simpson <<a href="mailto:cs@cskk.id.au" target="_blank">cs@cskk.id.au</a>> escreveu:<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 29Jan2019 15:44, Jamesie Pic <<a href="mailto:jpic@yourlabs.org" target="_blank">jpic@yourlabs.org</a>> wrote:<br>
>On Fri, Jan 4, 2019 at 10:07 PM Bernardo Sulzbach<br>
><<a href="mailto:bernardo@bernardosulzbach.com" target="_blank">bernardo@bernardosulzbach.com</a>> wrote:<br>
>> I'd suggest violating PEP-8 instead of trying to change it.<br>
><br>
>TBH even my bash global environment variables tend to become more and<br>
>more lowercase ...<br>
<br>
If you mean _exported_ variables, then this is actually a really bad <br>
idea.<br>
<br>
The shell (sh, bash, ksh etc) makes no enforcement about naming for <br>
exported vs unexported variables. And the exported namespace ($PATH etc) <br>
is totally open ended, because any programme might expect arbitrary <br>
optional exported names for easy tuning of defaults.<br>
<br>
So, you think, since I only use variables I intend and only export <br>
variables I plan to, I can do what I like. Example script:<br>
<br>
  a=1<br>
  b=2<br>
  export b<br>
<br>
So $b is now exported to subcommands, but not $a.<br>
<br>
However: the "exported set" is initially the environment you inherit.  <br>
Which means:<br>
<br>
Any variable that _arrives_ in the environment is _already_ in the <br>
exported set. So, another script:<br>
<br>
  a=1<br>
  b=2<br>
  # not exporting either<br>
<br>
If that gets called from the environment where you'd exported $b (eg <br>
from the first script, which could easily be your ~/.profile or <br>
~/.bashrc), then $b gets _modified_ and _exported_ to subcommands, even <br>
though you hadn't asked. Because it came in initially from the <br>
environment.<br>
<br>
This means that you don't directly control what is local to the script <br>
and what is exported (and thus can affect other scripts).<br>
<br>
The _only_ way to maintain sanity is the existing convention: local <br>
script variables use lowercase names and exported variables use <br>
UPPERCASE names. With that in hand, and cooperation from everyone else, <br>
you have predictable and reliable behaviour. And you have a nice visual <br>
distinction in your code because you know immediately (by convention) <br>
whether a variable is exported or not.<br>
<br>
By exporting lowercase variables you violate this convention, and make <br>
your script environment unsafe for others to use.<br>
<br>
Do many many example scripts on the web do the reverse: using UPPERCASE <br>
names for local script variables? Yes they do, and they do a disservice <br>
to everyone.<br>
<br>
Cheers,<br>
Cameron Simpson <<a href="mailto:cs@cskk.id.au" target="_blank">cs@cskk.id.au</a>><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><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_8806305434412243632gmail-m_5838787630306024734gmail_signature"><div dir="ltr"><div>Marcos Eliziário Santos<br>mobile/whatsapp/telegram: +55(21) 9-8027-0156</div><div>skype: <a href="mailto:marcos.eliziario@gmail.com" target="_blank">marcos.eliziario@gmail.com</a></div><div>linked-in : <a href="https://www.linkedin.com/in/eliziario/" target="_blank">https://www.linkedin.com/in/eliziario/</a></div><div><br></div></div></div>
_______________________________________________<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>
_______________________________________________<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>