On Fri, May 02, 2014 at 10:27:56PM -0400, Terry Reedy wrote:
If the rules for identifiers are expanded, any code the uses newly allowed names cannot be backported or run on previous versions. In contracted, the opposite problem occurs. I do not think they should be changed either way without a strong cause.
That applies to any new feature -- code using that feature cannot be easily backported. In this case, it's actually quite simple to backport code using the new rules for identifiers: just change the identifiers. The algorithm used by the code remains that same.
From 2.3. Identifiers and keywords "The syntax of identifiers in Python is based on the Unicode standard annex UAX-31, with elaboration and changes as defined below; see also PEP 3131 for further details."
In other words, we use the standard with a few intentional modifications.
Playing Devil's Advocate, perhaps we could add a few more intentional modifications.
While there are advantages to following a standard just for the sake of following a standard, once you allow any changes, you're no longer following the standard. So the argument becomes, why should we allow that change but not this change?
Particularly for mathematically-focused code, I think it would be useful to be able to use identifiers like (say) σ² for variance, g₁ for sample skewness, or β₂ for Pearson's skewness, to give a few real-world examples. Regular digits may be ambiguous: compare s₁² for the sample variance with Bessel's correction, versus s12. (s twelve?)
I'm going to give a tentative +1 vote to allowing superscript and subscript letters and digits in identifiers, if it can be done without excessive cost in complexity or performance. Anything else, like (say) ⑤ (CIRCLED DIGIT FIVE), I will give a firm -1.