[Python-Dev] i18n identifiers

M.-A. Lemburg mal at egenix.com
Mon Oct 31 19:51:43 CET 2005

Martin v. Löwis wrote:
> Steve Holden wrote:
>>Therefore, if such steps are really going to be considered, I would 
>>really like to see them introduced in such a way that no breakage occurs 
>>for existing users, even the parochial ones who feel they (and their 
>>programs) don't need to understand anything but ASCII.
> It is straight-forward to make this feature completely backwards
> compatible. Syntactically, it is a pure extension: existing code
> will continue to work unmodified, and will continue to have the
> same meaning. With the feature, you will be able to write code
> that previously produced SyntaxErrors.
> Semantically, the only potential incompatibility is that you
> might find Unicode strings in __dict__. If purely-ASCII identifiers
> are going to be represented by byte strings (as they are now),
> no change in meaning for existing code is anticipated.
> So it is not necessary to make the feature conditional to preserve
> compatibility.

If people are really all enthusiastic about such a feature,
then it should happen in Python3k when the parser is rewritten
to work on Unicode natively.

Note that if you start with this now, a single module in
your application using Unicode identifiers could potentially
break the application: simply by the fact that stack frames,
tracebacks and module globals would now contain Unicode.

Any processing done on the identifiers, like e.g. error formatting
would then have to deal with Unicode objects (due to the automatic

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Oct 31 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the Python-Dev mailing list