Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <5339C281.7080300@rece.vub.ac.be>
References: <lgsi07$k1p$1@speranza.aioe.org> <mailman.8531.1395775491.18130.python-list@python.org> <5331D902.3030902@gmail.com> <53321819$0$29994$c3e8da3$5496439d@news.astraweb.com> <lh1g3h$meg$1@speranza.aioe.org> <CALwzidk+4diadosJ0bDFTj-OjU9ib712iPMBVxvqZfxAsY2cJg@mail.gmail.com> <53393BA4.2080305@rece.vub.ac.be> <CALwzidkWc+jQtyN7-nFd4wZCryqLNfNc2okVL_kSbCBkE6nuQQ@mail.gmail.com> <5339C281.7080300@rece.vub.ac.be>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Mon, 31 Mar 2014 18:47:48 -0600
Subject: Re: unicode as valid naming symbols
To: Python <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8762.1396313312.18130.python-list@python.org>
Lines: 95
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:69456

On Mon, Mar 31, 2014 at 1:31 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Op 31-03-14 19:40, Ian Kelly schreef:
>> 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
>> =D0=BA=D1=83=D1=87=D0=B0_=D1=84=D0=B5=D0=BA=D0=B0=D0=BB=D0=B8=D0=B9 if o=
ne 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.
>
> Your argument doesn't has much weight. First of all it can be used
> for just restricting names to the ascii range.

I disagree.  Non-ASCII written names are useful to anybody who prefers
not to do all their programming in English.

> Second of all I
> think a good chosen symbolic name can be more readable than a
> name in a character set you are not familiar with. A good chosen
> symbol will evoke a meaning with a lot of people. A name in a
> character set you are not familiar with is just gibberish to
> you.

Well, this is the path taken by APL.  It has its supporters.  It's not
known for being readable.

>> I don't think the comparisons to decorators and the if-else operator
>> are apt.
>
> I didn't make such a comparison. I just noted the arguments against
> were similar.

That's the comparison to which I was referring.

>> First, because while those may degrade readability, they do
>> so in a constrained way.  A decorator application is just the @ symbol
>> and an identifier.
>
> And if abused, can totally change the working of your function. There
> is no guarantee that the function returned, has any relation with the
> original function. If that can't be a night mare for readability,
> I don't know what is.

As Terry Reedy noted, this has nothing to do with the decorator
syntax, so it isn't much of an argument against having such syntax.

>> The if-else is just three expressions separated by
>> keywords.
>
> Yes but if used unrestrained in arbitrary expressions will make those
> expressions hard to understand.

I don't disagree.  I hardly ever use it myself, certainly only if it
can fit comfortably into one line, which is rare.  But it's still
quite limited in syntactic scope.

>> 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.
>
> So what if we double the number of different characters? I don't care
> about the number of them, I care about how meaningful they are. And
> as you say confusion is already possible. A good programmer knows
> how to deal with such a possible confusion, that the number of
> cases increases, doesn't need to be a problem for those that care
> about this.

So tell me then, how would you deal with it?  In the case of script
identifiers, it's often not hard to discern from context whether a
particular character is e.g. a Latin h or a Cyrillic =D2=BB.  Assuming the
original author wasn't being intentionally obfuscatory, if the rest of
the identifier is Cyrillic then the character is probably also
Cyrillic.  If it's a one-character identifier, then hopefully the rest
of the module is consistent and you can guess from that.  If the
identifier in question is just one symbol though, then you have a lot
less context.

>
>> 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.
>
> But that is not a fair comparison now, is it. What you are doing here
> is comparing actual use, to a worst case doom scenario.

I contend that there is no scenario with arbitrary Unicode identifiers
where readability is improved.