This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kxroberto
Recipients
Date 2006-04-24.10:39:57
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=972995

That error line in getpass should probably simply be
commented out?
Whats your sys.stdout.encoding ? (Probably not enough for
spanish chars as well)

The others will probably recommend to create sitecustomize.py

I'd say: Its a general trouble with Python that (console)
output encoding is in 'strict' mode by default. 
That crashes more apps, than it helps for discipline ...
And its hard even to grasp it and switch it for 'replace':
you'd need to replace sys.stdout with a custom formatter etc..

On MS Windows OS the MBCS conversion is kind of 'replace'
for good reason.  Even in Python on Win:
u"abc\u034adef".encode('mbcs') does replacing.

tty's,browser,windows,... and maybe most text mode files
(and even bin ones (latin1/replace?) ?) should not break.
The cases, where encoding should break strictly are
naturally cases where the programmer is aware (and puts the
conversion into strict mode expicitely)

"Python cannot print": Even a harmless 

>>> print u"abc\u034adef" 

throws an exception. That is questionable enough:

http://groups.google.de/group/comp.lang.python/msg/eac9b025b93e0642

Maybe in future Python:
* encoding tuples should be accepted everywhere as
alternative to second argument: .encode((enc,error))
* text file's .encoding/.write_encoding=(xy,'replace') or
(xy,'backslashreplace')
* bin file's .encoding=('latin1','strict')
* site(customize).py's defaultencoding should be/accept a
tuple ('ascii','replace')

-robert
History
Date User Action Args
2008-01-20 09:59:44adminlinkissue1436203 messages
2008-01-20 09:59:44admincreate