[Python-ideas] Allow additional separator character in variables

[Bruce Leban]

On Sun, Nov 19, 2017 at 4:18 PM, Mikhail V <mikhailwas at gmail.com> wrote:

> Bruce Leban wrote:
>
> > It is not a misfortune or even true that Python uses hyphen for minus.
> > The name of the character used in Python is HYPHEN-MINUS.
>
> This is pure demagogy, name it HYPHEN-MINUS-TINYDASH if you like,
> but what aspect of reality does it change apart of its name?
>

You've gone from making a bad suggestion to trolling.

While you may *think* this character is a hyphen, you're simply wrong. When
ASCII was created it was a 7-bit character set limited to 94 printable
characters plus space and 33 control characters. The designers explicitly
added a single double-duty character for both hyphen and minus, just as
they added a single character for single and double quotes rather than left
and right quotes. Were they mimicking the typewriter? Maybe they were
following the example of Hollerith code which only had uppercase. It
doesn't matter. It's not that they were unaware of the different uses or
the existence of typographic quotes. Just as monospace fonts were not
created because people didn't know about variable width fonts. It is what
it is. And pretending other people are idiots is inappropriate.

You can use accent grave as a left quote and apostrophe as a right quote if
you want to, but if you insist that Python is living in the dark ages
because it doesn't do things *your way* then you're just being rude.

... render
> hyphen as *hyphen*, which is well established for centuries in typography,
> and defined as a dash of 50% width of the letter "o" and is aligned to
> lowercase.
> As well as the Minus glyph which is defined as ca. 110% of "o" width
> and is aligned


False. There is no standard going back centuries defining the widths of the
different kinds of dashes. For that matter, there is no standard *today*
for what letters and symbols look like. See Doug Hofstadter's great paper
on this https://web.stanford.edu/group/SHR/4-2/text/hofstadter.html or the
Unicode consortium list of emoji
https://unicode.org/emoji/charts/full-emoji-list.html for great examples of
the non-standard nature of typography. Heck almost all vendors put cheese
on the *hamburger* emoji when obviously it only belongs on the cheeseburger
emoji. And Google puts the cheese below the meat which is clearly wrong as
the international standard for cheeseburgers puts the cheese on the top.

Just take some Python sources and count the amount of underscores
> and minus operators. This will give you an image of how important
> separators are compared to minus operator.
>

A non sequitur. Count the number of instances of the letter Z in English
vs. the letter E which tells you that Z is unimportant. So let's get rid of
it. Of course that may piss off the Polish people since it's the 9th most
frequent letter (4.9%) in Polish. While this makes a great story -- see
"Meihem In Ce Klasrum" http://www.tau.ac.il/~pauzner/funs/simpler.html --
but not a great reality.

That said, no one has argued that a word separator in names is a bad idea
and we have two choices: capitalizingEachWord and
underscores_between_words. These work well enough that the idea of breaking
every single Python program that uses subtraction just because one person
believes we are being antediluvian -- without any evidence -- is just not
going to happen. (Ooh. See what I did there. I typed two hyphen-minus
characters to get an "em dash" and you probably didn't even notice that I
was breaking centuries of tradition that the only proper way to write an em
dash is with a single piece of metal type.)

If you want to make serious contributions to Python or any other project
you need to understand why this is a bad idea.


>
> > I am extremely skeptical that a legitimate usability study would
> > find that record-count is better than record_count.
>
> Oh come on, probably you also want study for emoticons as a separators?
>

Yes, if someone insisted that emoticons were superior to underscores as
separators and implied I was an idiot for not agreeing with that.

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171119/68e83301/attachment-0001.html>