[Python-ideas] Allow additional separator character in variables

Mikhail V mikhailwas at gmail.com
Sun Nov 19 19:18:24 EST 2017

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?
"Hyphen-minus" would make sense for mechanical type-writers.
So it is a hyphen, a character used for centuries before typewriters even
appeared, and used as such now in 99 percent of medium.
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.
Don't forget also to include cases where variables are written without
any separator, but should do so.

> 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?

On Sun, Nov 19, 2017 at 5:16 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 19 November 2017 at 13:22, Mikhail V <mikhailwas at gmail.com> wrote:
>> For me, one "cheap" solution against underscores is to use
>> syntax highlighting which grays them out, but if those become like
>> spaces, then it becomes a bit confusing, e.g. in function with many arguments.
>> Also, unfortunately, not many editors allow easy (if any) highlighting
>> customisation on that level.
> Changing the way editors display underscore-using variable names still
> seems like a more productive direction to explore than changing the
> text encoding read by the compiler. The current source code structure
> is well-defined and unambiguous, so there's no clear benefit to change
> things at that level, and significant downsides in terms of
> complexity, forwards and backwards compatibility concerns, and high
> barriers to pervasive adoption.
> By contrast, if the argument for using a different Unicode character
> is "Editors will reliably display Unicode hyphen characters
> differently from the way they display minus signs (or vice-versa)",
> then we can just as easily say "If users are finding the way that text
> editors display snake_cased_names to be consistently hard to read,
> then text editors should change the way that they display
> snake_cased_names (or at least make it easy for users to opt-in to
> displaying them differently)".
> For example, they could decide to replace underscores in variable
> names for display purposes with hyphens plus the underscore combining
> diacritic, or the combining macron below:
> - https://en.wikipedia.org/wiki/Underline#Unicode
> - https://en.wikipedia.org/wiki/Macron_below
> Then when the cursor was placed inside the variable name, they could
> revert to displaying those characters as regular underscores.
> This kind of editor level modification would also extend itself well
> to underscores in numeric literals, as there the appropriate
> pseudo-separator shown when the literal wasn't being edited would be
> locale dependent.
> Cheers,
> Nick.
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-ideas mailing list