On Sun, Nov 19, 2017 at 4:18 PM, Mikhail V <mikhailwas@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