Marcos Eliziario marcos.eliziario at gmail.com
Tue Jan 29 19:08:21 EST 2019

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.

Marcos Eliziario

Em ter, 29 de jan de 2019 às 20:30, Cameron Simpson <cs at cskk.id.au>

> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190129/715c983a/attachment-0001.html>

More information about the Python-ideas mailing list