unicode as valid naming symbols

[Ian Kelly]

On Mon, Mar 31, 2014 at 3:55 AM, Antoon Pardon
<antoon.pardon at rece.vub.ac.be> wrote:
> On 27-03-14 17:22, Ian Kelly wrote:
>> On Thu, Mar 27, 2014 at 9:28 AM, Mark H Harris <harrismh777 at gmail.com> wrote:
>>>> Do you think that the ability to write this would be an improvement?
>>>>
>>>> import ⌺
>>>> ⌚ = ⌺.╩░
>>>> ⑥ = 5*⌺.⋨⋩
>>>> ❹ = ⑥ - 1
>>>> ♅⚕⚛ = [⌺.✱✳**⌺.❇*❹{⠪|⌚.∣} for ⠪ in ⌺.⣚]
>>>> ⌺.˘˜¨´՛՜(♅⚕⚛)
>>>
>>>    Steven, you're killing me here; argument by analogy does not work!
>> [  ------ 8< ---------- ]
>> One of the things that Python is widely known for is its readability.
>> Allowing symbols such as √ to denote identifiers may be quite
>> expressive and appreciable to the person writing the code. However it
>> damages readability considerably, as seen in Steven's example above.
>> Personally I'm not interested in having to maintain another
>> programmer's code that arbitrarily uses ⌚ as a timer function, ╩ as
>> intersection or ░ as a matrix constructor.
>
> I don't find Steven's example convincing. Sure it can be used in a way
> that damages readability considerably however lots of things in python
> can be abused in a way that damages readability considerably.
>
> That you are not interested in having to maintain someone's code who
> would use such symbols is irrelevant. IIRC people have used the exact
> same kind of argument against decorators and the if-else operator.
>
> It seems we are all consenting adults until someone doesn't like the
> idea how it might influence his job. In that case it shouldn't be
> allowed.

That was an exaggeration on my part.  It wouldn't affect my job, as I
wouldn't expect to ever actually have to maintain anything like the
above.  My greater point though is that it damages Python's
readability for no actual gain in my view.  There is nothing useful
you can do with a name that is the U+1F4A9 character that you can't do
just as easily with alphanumeric identifiers like pile_of_poo (or
куча_фекалий if one prefers; that's auto-translated, so don't blame me
if it's a poor translation). The kinds of symbols that we're talking
about here aren't part of any writing systems, and so to incorporate
them in *names* as if they were is an abuse of Unicode.

I don't think the comparisons to decorators and the if-else operator
are apt. First, because while those may degrade readability, they do
so in a constrained way.  A decorator application is just the @ symbol
and an identifier.  The if-else is just three expressions separated by
keywords.  In the case of arbitrary Unicode identifiers, we're talking
about approximately doubling the number of different characters (out
of a continuously growing set) that could be used, many of which are
easily confused with other characters. Of course the potential for
confusion already exists, but that's no justification for aggravating
it.

Second, at least in the case of decorators, while I don't dispute that
they can harm readability, I think that in the majority of cases they
actually help it.  That's because the @ syntax placed before a
function or class clearly denotes that the construct is being
decorated by something.  The alternative to the syntax is to place an
assignment like "f = decorate(f)" *after* the definition, where it is
much less prominent.  That the reader then potentially has to go
figure out what the decorator does is true regardless of whether the @
syntax is used or not.  I'm unable to imagine any case where an
arbitrary Unicode identifier would actually improve readability.

Finally, in my experience the "consenting adults" line is usually used
in the context of program or library design.  I don't believe it's
appropriate when discussing the design of the language itself, which
should be kept as clean as possible.  The logical conclusion of that
would be Lisp-like macros where every user ends up with their own
unique and incompatible version of the language, because we're all
consenting adults here, right?