Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder5.xlned.com!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <533AAA13.4010309@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> <CALwzidkTRYbpeBCY7gxSXa=ZNimaAe69mGbT0d9sbehHfHgvOw@mail.gmail.com> <533A768F.5080102@rece.vub.ac.be> <CALwzid==eS-QryN8dhoDaREG4QTD1xa-NacH2KMR8Tfe3Sg-Pw@mail.gmail.com> <533A96E9.1030107@rece.vub.ac.be> <CAPTjJmqUbOf5VAgS2zYSk9ah=uq-e_n_gdXTS=TZz5VTt5eKkQ@mail.gmail.com> <533AAA13.4010309@rece.vub.ac.be>
Date: Wed, 2 Apr 2014 00:00:56 +1100
Subject: Re: unicode as valid naming symbols
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8798.1396357260.18130.python-list@python.org>
Lines: 41
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:69509

On Tue, Apr 1, 2014 at 10:59 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> On 01-04-14 12:58, Chris Angelico wrote:
>> But because, in the future, Python may choose to create new operators,
>> the simplest and safest way to ensure safety is to put a boundary on
>> what can be operators and what can be names; Unicode character classes
>> are perfect for this. It's also possible that all Unicode whitespace
>> characters might become legal for indentation and separation (maybe
>> they are already??), so obviously they're ruled out as identifiers;
>> anyway, I honestly do not think people would want to use U+2007 FIGURE
>> SPACE inside a name. So if we deny whitespace, and accept letters and
>> digits, it makes good sense to deny mathematical symbols so as to keep
>> them available for operators. (It also makes reasonable sense to
>> *permit* mathematical symbols, thus allowing you to use them for
>> functions/methods, in the same way that you can use "n", "o", and "t",
>> but not "not"; but with word operators, the entire word has to be used
>> as-is before it's a collision - with a symbolic one, any instance of
>> that symbol inside a name will change parsing entirely. It's a
>> trade-off, and Python's made a decision one way and not the other.)
>
> This mostly makes sense to me. The only caveat I have is that since we
> also allow _ (U+005F LOW LINE) in names which belongs to the category
> <puctuation, connector>, we should allow other symbols within this
> category in a name.
>
> But I confess that is mostly personal taste, since I find names_like_this
> ugly. Names-like-this look better to me but that wouldn't be workable
> in python. But maybe there is some connector that would be aestetically
> pleasing and not causing other problems.

That's reasonable. The Pc category doesn't have much in it:

http://www.fileformat.info/info/unicode/category/Pc/list.htm

If the definition of "characters permitted in identifiers" is derived
exclusively from the Unicode categories, including Pc would make fine
sense. Probably the definition should be: First character is L* or Pc,
subsequent characters are L*, N*, or Pc, and either Mn or M*
(combining characters). Or something like that.

ChrisA