Sorry Terry, I was short (and ended up being cryptic) because I was on a mobile device. I meant "this is a bad idea and should be rejected", and in addition I also meant to discourage a 3rd party implementation of the idea. I also wanted to object against your claim that this idea has only been left unimplemented because of disinterest or inaction by the core dev team; to the contrary, the general sentiment is pretty clear that it's a bad idea. There are other ideas that are not suitable for adding to the language but where we would encourage folks to help themselves by writing a module or extension and posting it on PyPy, or even ideas where it would eventually be a good idea to include such a package into the stdlib. But this is not one of them.


On Mon, Jun 23, 2014 at 12:11 PM, Terry Reedy <tjreedy@udel.edu> wrote:
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@udel.edu
<mailto:tjreedy@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



_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



--
--Guido van Rossum (python.org/~guido)