[Python-ideas] Allow additional separator character in variables

[Chris Angelico]

On Sun, Nov 19, 2017 at 1:01 PM, Mikhail V <mikhailwas at gmail.com> wrote:
> Python allows underscore character as a separator in variables.
> This is better than nothing, still it does not make the look much better.
>
> **Proposal**: allow additional separator, namely hyphen character.
>
> **Benefits**: this should provide significant readability improvement.
> Compared to most syntax change proposals that I remember till now,
> this seems to have really tangible benefits. So all in all I see it as
> a significant
> language improvement.
> Besides its direct benefit as a good looking separator, it also gives
> an opprtunity
> to reduce "camelCase" or similar ugly inclusions in code.

Since you can already avoid camelCase by using snake_case, I'm not
sure how much you really gain by adding the hyphen.

> So one can easily compose human-readable variable names e.g.:
> my-variable
> figure-shape---width
> etc.

While I agree with "my-variable", I don't like the triple hyphen.
What's the benefit?

> **Problem**: currently hyphen character is used as a minus operator!
> The problem is as old as the history of most programming languages,
> and inherited from initial poorness of character sets.
> Therefore I don't see a single optimal solution to this.
>
> Possible solutions:
>
> Solution 1:
> Use another similar looking character from unicode,
> for example: U+02D7  (modifier letter minus sign).
> At the same time IMO it is needed to allow the minus character
> for the minus operator, namely U+2212 Minus sign. This will
> allow proper typography of source code.
> Main benefit of such approach: no breakage of current code base,
> since new chars are additional to existing ones.
>
> Solution 2: (radical)
> Disallow hyphen as minus operator, and use only U+2212 Minus sign.
> I.e. "a-b" would be a variable and "a − b" a minus operation.
> Advantage: opportunity to correct the improper character usage once and for all.
> Disadvantage: breakage of current code base + force UTF-8 storage use (consider
> e.g. editors without unicode support).
> Thus most probably such solution will cause howl reaching to the sky among
> users, despite many modern editors allow unicode and custom operator styling,
> for example to distinguish dash from hyphen in a monospaced editor.

Both of these create extremely confusing situations, where two
nearly-identical symbols have completely different meanings. Solution
2 is a massive backward-compatibility break. You're not just
disallowing something that's been legal since the language was
introduced - you're giving it a completely different meaning. That's
basically a non-starter right there.

Solution 1 is at least reasonably plausible, in that you're taking
something that's currently a SyntaxError and giving it a valid
meaning. There is no code that could be broken by that (AFAIK).
However, there's still the problem that you're introducing a marginal
benefit and a significant confusion potential; plus, you'd be adding a
special case to the Unicode identifier rules, which is not something
to be done lightly.

How much benefit do you REALLY get from using hyphens rather than underscores?

ChrisA