[Python-ideas] Allow additional separator character in variables
rosuav at gmail.com
Sat Nov 18 21:14:44 EST 2017
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.:
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?
More information about the Python-ideas