Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'programmer': 0.03; 'operator': 0.03; 'english.': 0.04; 'value,': 0.04; 'argument': 0.05; 'abuse': 0.07; 'context': 0.07; 'damages': 0.07; 'expressions': 0.07; 'arguments': 0.09; 'ascii': 0.09; 'assuming': 0.09; 'comfortably': 0.09; 'decorator': 0.09; 'identifier': 0.09; 'latter': 0.09; 'meaningful': 0.09; 'noted,': 0.09; 'cc:addr :python-list': 0.11; "wouldn't": 0.14; '>>': 0.16; '(out': 0.16; 'comparison.': 0.16; 'exists,': 0.16; 'identifier,': 0.16; 'identifier.': 0.16; 'identifiers': 0.16; 'identifiers,': 0.16; 'non-ascii': 0.16; 'programmatic': 0.16; 'range.': 0.16; 'readability': 0.16; 'readable': 0.16; 'reedy': 0.16; 'relates': 0.16; 'restricting': 0.16; 'returned,': 0.16; 'scope.': 0.16; 'separated': 0.16; 'subject:unicode': 0.16; 'symbols': 0.16; 'syntactic': 0.16; 'syntax,': 0.16; 'unicode.': 0.16; 'worst': 0.16; '\xc2\xa0i': 0.16; '\xc2\xa0if': 0.16; 'language': 0.16; 'wrote:': 0.18; 'module': 0.19; 'differ': 0.19; "python's": 0.19; 'fit': 0.20; 'written': 0.21; 'programming': 0.22; 'email addr:gmail.com>': 0.22; 'cc:addr:python.org': 0.22; '31,': 0.24; "aren't": 0.24; 'certainly': 0.24; 'comparing': 0.24; 'decorators': 0.24; 'unicode': 0.24; 'mon,': 0.24; '(or': 0.24; 'question': 0.24; 'cc:2**0': 0.24; 'script': 0.25; '>': 0.26; 'first,': 0.26; 'second': 0.26; 'least': 0.26; 'developing': 0.27; 'header:In-Reply-To:1': 0.27; 'point': 0.28; 'function': 0.29; 'rest': 0.29; 'character': 0.29; "doesn't": 0.30; 'characters': 0.30; 'message-id:@mail.gmail.com': 0.30; 'url:mailman': 0.30; 'that.': 0.31; 'url:wiki': 0.31; 'are.': 0.31; 'comparison': 0.31; 'context.': 0.31; 'depth': 0.31; 'noted': 0.31; 'second,': 0.31; 'symbolic': 0.31; 'url:wikipedia': 0.31; 'view.': 0.31; 'this.': 0.32; 'probably': 0.32; "we're": 0.32; 'quite': 0.32; 'url:python': 0.33; 'becomes': 0.33; 'cases': 0.33; 'guess': 0.33; 'totally': 0.33; 'used,': 0.33; 'actual': 0.34; 'could': 0.34; 'problem': 0.35; "can't": 0.35; 'knows': 0.35; 'possible.': 0.35; 'something': 0.35; 'anybody': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; '8bit%:17': 0.36; 'consistent': 0.36; 'explains': 0.36; 'more': 0.64; 'different': 0.65; 'talking': 0.65; 'to:addr:gmail.com': 0.65; 'here': 0.66; 'believe': 0.68; 'mar': 0.68; 'yes': 0.68; 'alphanumeric': 0.68; 'incorporate': 0.68; 'line,': 0.68; 'results': 0.69; '8bit%:96': 0.70; 'internet': 0.71; 'cultural': 0.74; 'overcome': 0.74; 'gain': 0.79; 'differences,': 0.84; 'hardly': 0.84; 'imperative.': 0.84; 'improved.': 0.84; 'mare': 0.84; 'mentality': 0.84; 'nurture': 0.84; 'pardon': 0.84; 'prefers': 0.84; 'results,': 0.84; 'supporters.': 0.84; 'doubling': 0.91; 'mistakes': 0.93; 'outcome': 0.93; 'overcoming': 0.93; '<>*': 0.95 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C8v/NduKi1P4tHqMsmnXNVRG2cE857lc1JFctVVJdtU=; b=Sr5kHFjKZcdAugi1kAgSAveePg0zb7tgnJsCzpoFo7wMjaueggDLIrMTmakBhukhDY n1Ez24JjV935nf2ry/JHbagT1uoFy9D7FjzoAKCQcUYheTRnQfyLlPldiN1NuvXjzGUQ 7+Dyr4H+mpEMcLG/Y+cnoT4hNZZPfGX56cgHlUXa6SMDfTQmFXWxqIKWgT6DHxYWhDF0 iZhIkF4NP+Gf1CNmKB/MfQUpVS9RBjYXRV1s6Ly/0Q3aUUobVB9M/8YezEkufv1+XVbI kgn8g0Gm1zSzplELcCdmHP3L+c6uD6+t4f4mMTr8ZDgDc6VBFWWvATYR8p5dJtBlbD6a 0Aag== MIME-Version: 1.0 X-Received: by 10.224.67.131 with SMTP id r3mr12223062qai.75.1396324720442; Mon, 31 Mar 2014 20:58:40 -0700 (PDT) In-Reply-To: References: <5331D902.3030902@gmail.com> <53321819$0$29994$c3e8da3$5496439d@news.astraweb.com> <53393BA4.2080305@rece.vub.ac.be> <5339C281.7080300@rece.vub.ac.be> Date: Mon, 31 Mar 2014 23:58:40 -0400 Subject: Re: unicode as valid naming symbols From: David Hutto To: Ian Kelly Content-Type: multipart/alternative; boundary=001a11c3cefcf401d904f5f32e57 Cc: Python X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 307 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1396324729 news.xs4all.nl 2895 [2001:888:2000:d::a6]:60216 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:69463 --001a11c3cefcf401d904f5f32e57 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I personally believe that it becomes hard to have even a programming language overcome cultural learning styles, and programmatic differences, because of nurture vs nature. We can all program something which results in a similar return value, but overcoming the nurturing the internet provides, becomes an imperative. I'll just offer a reference to avoid personal mistakes in explaining something that relates to how programmers/computer scientists/electrical engineers approach their end results, and why those end results may still differ in the mentality of the individual, or group, outcome of developing A.I. systems: http://en.wikipedia.org/wiki/Ethnolinguistics http://en.wikipedia.org/wiki/Cognitive_anthropology http://en.wikipedia.org/wiki/Cognitive_science The latter probably explains what I mean in more depth than the two formers. On Mon, Mar 31, 2014 at 8:47 PM, Ian Kelly wrote: > On Mon, Mar 31, 2014 at 1:31 PM, Antoon Pardon > 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= 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. > > 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 th= e > 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. > -- > https://mail.python.org/mailman/listinfo/python-list > --=20 Best Regards, David Hutto *CEO:* *http://www.hitwebdevelopment.com = * --001a11c3cefcf401d904f5f32e57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I personally believe that it becomes hard to have eve= n a programming language overcome cultural learning styles, and programmati= c differences, because of nurture vs nature.

We c= an all program something which results in a similar return value, but overc= oming the nurturing the internet provides, becomes an imperative.

I'll just offer=C2=A0a reference to avoid personal = mistakes in explaining something that relates to how programmers/computer s= cientists/electrical engineers approach their end results, and why those en= d results may still differ in the mentality of the individual, or group, ou= tcome of developing A.I. systems:


http://e= n.wikipedia.org/wiki/Cognitive_anthropology


=
The latter probably=C2=A0explains=C2=A0what I mean in more depth than = the two formers.=C2=A0


On Mon,= Mar 31, 2014 at 8:47 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
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. =C2=A0It wouldn't a= ffect my job, as I
>> wouldn't expect to ever actually have to maintain anything lik= e the
>> above. =C2=A0My greater point though is that it damages Python'= ;s
>> readability for no actual gain in my view. =C2=A0There is nothing = useful
>> you can do with a name that is the U+1F4A9 character that you can&= #39;t do
>> just as easily with alphanumeric identifiers like pile_of_poo (or<= br> >> =D0=BA=D1=83=D1=87=D0=B0_=D1=84=D0=B5=D0=BA=D0=B0=D0=BB=D0=B8=D0= =B9 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 incor= porate
>> 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. =C2=A0Non-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. =C2=A0It has its supporters. =C2=A0It&= #39;s not
known for being readable.

>> I don't think the comparisons to decorators and the if-else op= erator
>> are apt.
>
> I didn't make such a comparison. I just noted the arguments agains= t
> 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. =C2=A0A decorator application is just the= @ symbol
>> and an identifier.
>
> And if abused, can totally change the working of your function. There<= br> > is no guarantee that the function returned, has any relation with the<= br> > original function. If that can't be a night mare for readability,<= br> > 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<= br> > expressions hard to understand.

I don't disagree. =C2=A0I hardly ever use it myself, certainly only if = it
can fit comfortably into one line, which is rare. =C2=A0But it's still<= br> quite limited in syntactic scope.

>> In the case of arbitrary Unicode identifiers, we're talking >> about approximately doubling the number of different characters (o= ut
>> of a continuously growing set) that could be used, many of which a= re
>> easily confused with other characters. Of course the potential for=
>> confusion already exists, but that's no justification for aggr= avating
>> it.
>
> So what if we double the number of different characters? I don't c= are
> 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<= br> > about this.

So tell me then, how would you deal with it? =C2=A0In 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. =C2=A0Assuming= the
original author wasn't being intentionally obfuscatory, if the rest of<= br> the identifier is Cyrillic then the character is probably also
Cyrillic. =C2=A0If it's a one-character identifier, then hopefully the = rest
of the module is consistent and you can guess from that. =C2=A0If 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 disp= ute that
>> they can harm readability, I think that in the majority of cases t= hey
>> 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.
--
https://mail.python.org/mailman/listinfo/python-list



--
Best Rega= rds,
David Hutto<= /span>
CEO: http://www.hitwebdevelopment.com
--001a11c3cefcf401d904f5f32e57--