Are unicode identifiers in python bad practice?

Question

I am getting into machine learning, and to document my code, I will write LaTeX math versions of my functions, right next to the code in an Jupyter/IPython notebook. The mathematical definitions include many Greek symbols, so I thought that I might as well use the Greek symbols in function and variable names, since that's possible in python. Would this be bad practice?

Answer 1

It seems a good use case under these assumptions:

• the audience is mathematically versed,
• you make use of a lot of Jupyter Notebook features such as inline plotting and table display (e.g. pandas) so that the use of your code outside a notebook is unlikely,
• it is application code rather than a library that others will use.

Hint: Entering Greek letters in the notebook is simple. Just type the LaTeX math notation and TAB. For example, type:

\pi

and then the TAB key to get a π.

Answer 2

This is what the official style guide has to say:

For Python 3.0 and beyond, the following policy is prescribed for the standard library (see PEP 3131): All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases, abbreviations and technical terms are used which aren't English). In addition, string literals and comments must also be in ASCII. The only exceptions are (a) test cases testing the non-ASCII features, and (b) names of authors. Authors whose names are not based on the latin alphabet MUST provide a latin transliteration of their names.

Open source projects with a global audience are encouraged to adopt a similar policy.

In other words: It would be considered better practice to use ascii-only, if you are targeting a global audience. If the code is only going to be read by your team, it's a matter of preference.

Answer 3

Really, it is a matter of personal opinion. Keep in mind that Unicode character support for variable names is ONLY in Python 3, so make sure that any external libraries support Python 3. Other than that, there isn't a reason to say no.