[Python-ideas] .pyu nicode syntax symbols (was Re: Empty set, Empty dict)

Terry Reedy tjreedy at udel.edu
Mon Jun 23 21:11:25 CEST 2014


On 6/22/2014 8:30 PM, Guido van Rossum wrote:
> Hm. What's wrong with rejecting bad ideas?

[I am not sure whether you are asking seriously or rhetorically, but I 
think this question is worth a serious response.]

Aside from the fact that different people have different ideas of what 
is an absolutely bad idea, nothing. I personally reject almost all new 
syntax ideas because I think most of them are local small-audience 
optimizations that would overall make Python worse.

However, the purpose of python-ideas is "Discussions of speculative 
Python language ideas". 'Discussion' means not routinely trying to stop 
discussion. Indeed, some good can come from discussion of ideas I (or 
you) think are bad.

Rejection has multiple forms, not mutually exclusive:

Inaction: by default, an idea is effectively rejected until a patch is 
committed.

Education: explaining how one can already accomplish the desired task.

Deflection: suggest implementing the idea somewhere other than in core 
Python.

Explanation: explain why something is bad.

Downvote or BDFL rejection: (self-explanatory)

> On Jun 22, 2014 1:19 PM, "Terry Reedy"
> <tjreedy at udel.edu
> <mailto:tjreedy at udel.edu>> wrote:
>
>     Problem: For years, various people have suggested that they would
>     like to use syntactically significant unicode symbols in Python
>     code. A prime example is using U+2205, EMPTY SET, ∅, instead of
>     'set()'.

Specifically, I believe people have asked that Python parsers accept and 
translate unicode symbols *in .py files*. This would have the immediate 
effect of making some .py files invisibly and unnecessarily incompatible 
with all existing Python interpreters, even if the translated code would 
run just fine. I, too, do not want the meaning of '.py' fragmented 
further than it already is.

>     On the other hand, the conservative, overwhelmed core
>     development group is not much interested and would rather do other
>     things.

In other words, the idea of changing Python itself has been and will be 
rejected by inaction for at least the next few years, and until 
circumstances change after that.  (Hence, no need for *me* to 'reject' it.)

>     Solution: Act instead of ask.

'Stop asking' is not only rejection of the idea of changing Python, but 
also of continuing the discussion that has gone on for years. People who 
do not want to give up the idea should do something else. In the course 
of suggesting an implementation, I also suggested some aspects of an 
implementation that I consider important.

>     One or more of the people who really want this could get themselves
>     together and produce a working system. (If multiple people, ask for
>     a new sig and mailing list).

Discuss it elsewhere because python-ideas is not 3rd-party-package-dev.

>     1. Ask core development to reserve '.pyu' for python with unicode
>     symbols. (If refused, chose something else.)

In other words,
1. do not use .py for unisym_python.
2. while .pyu seems like an obvious alternative (to me), recognize 
python-devs moral rights to .pyx, regardless of legalities.

>     2. Write pyu.py. It should first translate x.pyu to the equivalent
>     x.py. ...  run x.py.

To be clear, I meant write x.py to disk, where it would be available for 
humans to read. This is specifically aimed at the issue of 'fragmenting 
the community'.

 >     [snip implementation idea]
>     A mathematician that used most of those symbols, for a math
>     audience, could still use the ascii tranlation for other audiences.

Again, I would want the standard .py file available.

In my first post to clp/python list over 17 years ago, I dubbed Python 
'executable pseudocode' and opined that it should be used to communicate 
algorithms in preference to non-executable notation. I would rather a 
mathematician use symbols embedded in Python, with a link to a .py file, 
than the same symbols in a non-executable *and non-testable* notation.

-- 
Terry Jan Reedy





More information about the Python-ideas mailing list