unicode as valid naming symbols

[Antoon Pardon]

Op 31-03-14 19:40, Ian Kelly schreef:
> 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.

Your argument doesn't has much weight. First of all it can be used
for just restricting names to the ascii range. 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.

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

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

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

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

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

-- 
Antoon Pardon