Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!news.stack.nl!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path: <antoon.pardon@rece.vub.ac.be>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.007
X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'python.': 0.02; 'causing': 0.04; 'received:134': 0.05; 'deny': 0.07; 'parsing': 0.09; 'python': 0.11; 'mostly': 0.14; "wouldn't": 0.14; '(it': 0.16; 'as-is': 0.16; 'belongs': 0.16; 'caveat': 0.16; 'entirely.': 0.16; 'identifiers;': 0.16; 'line)': 0.16; 'operators,': 0.16; 'operators.': 0.16; 'simplest': 0.16; 'subject:unicode': 0.16; 'symbols': 0.16; 'wrote:': 0.18; 'obviously': 0.18; "python's": 0.19; 'header:User-Agent:1': 0.23; 'mathematical': 0.24; 'unicode': 0.24; 'header:In-Reply-To:1': 0.27; 'chris': 0.29; 'character': 0.29; 'thus': 0.29; 'characters': 0.30; '(maybe': 0.31; 'boundary': 0.31; 'indentation': 0.31; 'operators': 0.31; 'symbolic': 0.31; 'this.': 0.32; 'figure': 0.32; 'sense': 0.34; 'maybe': 0.34; 'classes': 0.35; 'one,': 0.35; 'but': 0.35; 'there': 0.35; 'possible': 0.36; 'should': 0.36; 'to:addr:python- list': 0.38; 'to:addr:python.org': 0.39; 'space': 0.40; 'ensure': 0.60; 'letters': 0.60; 'problems.': 0.60; 'new': 0.61; 'entire': 0.61; 'name': 0.63; 'personal': 0.63; 'skip:n 10': 0.64; 'choose': 0.64; 'become': 0.64; 'within': 0.65; 'legal': 0.71; 'future,': 0.83; 'low': 0.83; 'collision': 0.84; 'pardon': 0.84; 'ruled': 0.84
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EAN2sOlOGuA9G/2dsb2JhbABZhyLAP4EzgxkBAQUjVRELGAICBRYPCQMCAQIBRRMIAod1rnObcIcLgSmIHYUxhDgEmFaGOIwBgzI
Date: Tue, 01 Apr 2014 13:59:15 +0200
From: Antoon Pardon <antoon.pardon@rece.vub.ac.be>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.3.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: unicode as valid naming symbols
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>
In-Reply-To: <CAPTjJmqUbOf5VAgS2zYSk9ah=uq-e_n_gdXTS=TZz5VTt5eKkQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.8796.1396354601.18130.python-list@python.org>
Lines: 31
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1396354601 news.xs4all.nl 2923 [2001:888:2000:d::a6]:48817
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:69506

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.

-- 
Antoon Pardon