Adrien -  please take note that since you already wrote about
"everybody could update their environment and editors" to support unicode,
things like what you want (emojis in identifiers) can be supported
at programming editor (and plug-ins and extensions for those) level -
without impairing anyone else from working on your codebase.

You can just work on an extension for your favorite editor that
would transform certain escaped sequences into proper emojis.
If these escapes are themselves valid identifiers, there is no
stopping you and whatever enthusiast comunity you can raise
from having fun with the looks of "pyemojicode", and that wold
still allow people outside that community to interoperate with your code,
and all of the tools that use the static source would still work.

So, all you need is an extension to replace, at display time things liks
EMO_fire_ -> 🔥
EMO_heart -> 🖤

And so on. With a browser extension, or a site that acts as a proxy
to code hosting like github/bitbucket, enthusiasts could even see these
characters in internet listings. (The escaping sequence could be less
intrusive as well,
your call - and it also would help getting those symbols input into the
code to start with)



On Mon, 15 Jul 2019 at 10:47, Paul Moore <p.f.mo...@gmail.com> wrote:

> On Mon, 15 Jul 2019 at 14:33, Dan Sommers
> <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 7/15/19 8:54 AM, Steven D'Aprano wrote:
> > >  = .(, )
> >
> > I call foul.  At least tentatively.  For the moment.
>
> That was a demo (he used private area characters to ensure getting the
> square box substitute character). The point is that someone with the
> wrong font installed, or a limited terminal app, can get this sort of
> output with entirely legal characters - and anyway the comment was
> made to explain why *extending* the list of allowed characters was bad
> (so what's legal right now is not relevant).
>
> On Mon, 15 Jul 2019 at 14:13, Adrien Ricocotam <ricoco...@gmail.com>
> wrote:
> >
> > We can already do this is already (
> https://github.com/satwikkansal/wtfpython#-skipping-lines) so it's not a
> problem to me. It is a problem but not related to unicode.
>
> That's *exactly* the issue of confusable characters, which is a
> Unicode issue. So I don't see how you can say it's "not related to
> Unicode". It's not directly related to *changing* which Unicode
> characters are allowed in identifiers - that much is true (at least
> partially, it's quite possible that changing the list would result in
> having more confusables, so increasing the risk) - but that's not what
> you claimed.
>
> Paul
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VQ2R5PO3VZTBU2U7JC4XF6PZSZO7HRDH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IYOAMGKYVCLXGLZKKVTZKNG7FECFIRIV/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to