PEP 3131: Supporting Non-ASCII Identifiers

[rurpy at yahoo.com]

On May 16, 11:41 am, "sjdevn... at yahoo.com" <sjdevn... at yahoo.com>
wrote:
> Christophe wrote:
....snip...
> > Who displays stack frames? Your code. Whose code includes unicode
> > identifiers? Your code. Whose fault is it to create a stack trace
> > display procedure that cannot handle unicode? You.
>
> Thanks but no--I work with a _lot_ of code I didn't write, and looking
> through stack traces from 3rd party packages is not uncommon.

Are you worried that some 3rd-party package you have
included in your software will have some non-ascii identifiers
buried in it somewhere?  Surely that is easy to check for?
Far easier that checking that it doesn't have some trojan
code it it, it seems to me.

> And I'm often not creating a stack trace procedure, I'm using the
> built-in python procedure.
>
> And I'm often dealing with mailing lists, Usenet, etc where I don't
> know ahead of time what the other end's display capabilities are, how
> to fix them if they don't display what I'm trying to send, whether
> intervening systems will mangle things, etc.

I think we all are in this position.  I always send plain
text mail to mailing lists, people I don't know etc.  But
that doesn't mean that email software should be contrainted
to only 7-bit plain text, no attachements!  I frequently use
such capabilities when they are appropriate.

If your response is, "yes, but look at the problems html
email, virus infected, attachements etc cause", the situation
is not the same.  You have little control over what kind of
email people send you but you do have control over what
code, libraries, patches, you choose to use in your
software.

If you want to use ascii-only, do it!  Nobody is making
you deal with non-ascii code if you don't want to.