On May 16, 11:41 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
