Somewhere in this thread, someone mentioned (and something similar for emacs, but I'm a vim user).  I'm not sure if this mention was a joke or not, but I thought it looked cool and started using it.  I can't decide if I actually find it useful or distracting, but in truth it seems to answer the *entire* concern of anyone wanting to see an empty-set symbol (but not to save one bytecode instruction, I admit), and also various other math symbols that name concepts spelled in ASCII in Python.

While some hypothetical .pyu translation tool or import hook could do the same thing, this really *does* seem like something to just do at the editor level since there's nothing *semantic* about the new symbols, just a way for them to look.

On Tue, Jul 1, 2014 at 1:04 PM, Terry Reedy <> wrote:
On 7/1/2014 6:51 AM, Andrew Barnert wrote:

I think Terry Reedy actually had a better answer: just tell people to
implement it,  polish it up, put it on PyPI, and come back to us when
they're ready to show off their tons of users who can't live without
it. Random objected that wasn't possible,

'Random' said something quite different. He only noted that if '∅' were translated to 'set()', then the resulting CPython-specific bytecode would continue to be "LOAD_GLOBAL (set), CALL_FUNCTION 0" rather than the 'optimized' "BUILD_SET 0". He also noted (objected) that there is no python code that CPython currently compiles as "BUILD_SET 0" Well, its unfortunate that {} is not available. If it were, there would be no issue, to me anyway, of using '∅'.  However, optimizing CPython bytecode, and compiler hooks, are completely different issues from translating unisym python to standard python that could run on any implementation of Python. If we thought the bytecode difference was important (which most do not), we could have a peephole optimizer to 'fix' it, completely independently of the existence of '∅' or any idea of using it in python code.

in which case Terry's idea is more of a dismissal than a helpful suggestion,

My post was a dismissal of the idea of changing python itself *and* a suggestion of how to proceed without involving pydev. proves that it is possible, and
even pretty easy.

I consider producing (or at least being able to produce) a standard .py file that can be published outside the specialized group run on and debugged on standard interpreters to be essential to any sensible idea for augmented Python code (whether with unicode symbols or anything else, such as native-language keywords).  However, as I said before, off topic here for unicode symbols, though not on python-list.

Terry Jan Reedy

Python-ideas mailing list
Code of Conduct:

Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.