[Python-ideas] Allow additional separator character in variables

Guido van Rossum guido at python.org
Sun Nov 19 23:46:39 EST 2017


Please kill this thread.

On Sun, Nov 19, 2017 at 7:57 PM, Bruce Leban <bruce at leban.us> wrote:

>
> 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
>
>
> _______________________________________________
> 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/
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171119/de57f4b6/attachment.html>


More information about the Python-ideas mailing list