unicode as valid naming symbols

[Antoon Pardon]

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