[issue2630] repr() should not escape non-ASCII characters

Atsuo Ishimoto <[EMAIL PROTECTED]> added the comment: Great, thank you! ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing l

[issue2630] repr() should not escape non-ASCII characters

Georg Brandl <[EMAIL PROTECTED]> added the comment: Patch committed to Py3k branch in r64138. Thanks all! -- resolution: -> accepted status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue2630] repr() should not escape non-ASCII characters

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: You are right, I had forgotton about lower()/islower(). ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2630] repr() should not escape non-ASCII characters

Georg Brandl <[EMAIL PROTECTED]> added the comment: I would expect "abc".isprintable() give me a bool and "abc".printable() to return a printable string, as with "abc".lower() and "abc".islower(). ___ Python tracker <[EMAIL PROTECTED]>

[issue2630] repr() should not escape non-ASCII characters

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Shall the method be called isprintable() or simply printable()? For the record, in the io classes, the writable()/readable() convention was chosen. -- nosy: +pitrou ___ Python tracker <[EMAIL PROTE

[issue2630] repr() should not escape non-ASCII characters

Atsuo Ishimoto <[EMAIL PROTECTED]> added the comment: stringlib can be compiled for Python 2.6 now, but the '!a' converter is disabled by #ifdef for now. Added file: http://bugs.python.org/file10518/diff8.patch ___ Python tracker <[EMAIL PROTECTED]>

[issue2630] repr() should not escape non-ASCII characters

Changes by Eric Smith <[EMAIL PROTECTED]>: -- nosy: +eric.smith ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue2630] repr() should not escape non-ASCII characters

Guido van Rossum <[EMAIL PROTECTED]> added the comment: > Whether the C API stuff and .isprintable() should be backported to 2.6 > is something for Guido to decide. No way -- while all of this makes sense in Py3k, where all strings are Unicode, it would cause no end of problems in 2.6, and it wo

[issue2630] repr() should not escape non-ASCII characters

Atsuo Ishimoto <[EMAIL PROTECTED]> added the comment: I'm sorry, I missed a file to be uploaded. diff7_1.txt is correct file. Added file: http://bugs.python.org/file10512/diff7_1.txt ___ Python tracker <[EMAIL PROTECTED]> __

[issue2630] repr() should not escape non-ASCII characters

Changes by Atsuo Ishimoto <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10511/diff7.txt ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2630] repr() should not escape non-ASCII characters

Atsuo Ishimoto <[EMAIL PROTECTED]> added the comment: I updated the patch as per Georg's advice. Added file: http://bugs.python.org/file10511/diff7.txt ___ Python tracker <[EMAIL PROTECTED]> _

[issue2630] repr() should not escape non-ASCII characters

Georg Brandl <[EMAIL PROTECTED]> added the comment: ascii() should probably be in future_builtins. Whether the C API stuff and .isprintable() should be backported to 2.6 is something for Guido to decide. ___ Python tracker <[EMAIL PROTECTED]>

[issue2630] repr() should not escape non-ASCII characters

Atsuo Ishimoto <[EMAIL PROTECTED]> added the comment: BTW, are new C APIs and functions should be ported to Python 2.6 for compatibility, without modifing repr() itself? If so, I'll prepare a patch for Python 2.6. ___ Python tracker <[EMAIL PROTECTED]>

[issue2630] repr() should not escape non-ASCII characters

Atsuo Ishimoto <[EMAIL PROTECTED]> added the comment: Thank you for your review! I filed a new patch just before I see your comments. On Tue, Jun 3, 2008 at 7:13 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: > > Georg Brandl <[EMAIL PROTECTED]> added the comment: > > Review: > > * Why is an empty

[issue2630] repr() should not escape non-ASCII characters

Atsuo Ishimoto <[EMAIL PROTECTED]> added the comment: This patch contains following changes. - Added the new C API PyObject_ASCII() for consistency. - Added the new string formatting operater for str.format() and PyUnicode_FromFormat. Added file: http://bugs.python.org/file10507/diff6.txt

[issue2630] repr() should not escape non-ASCII characters

Georg Brandl <[EMAIL PROTECTED]> added the comment: One more thing: with r63891 the encoding and errors arguments for the creation of sys.stderr were made configurable; you'll have to adapt the patch so that it defaults to backslashescape but can be overridden by PYTHONIOENCODING. __

[issue2630] repr() should not escape non-ASCII characters

Georg Brandl <[EMAIL PROTECTED]> added the comment: Review: * Why is an empty string not printable? In any case, the empty string should be among the test cases for isprintable(). * Why not use PyUnicode_DecodeASCII instead of PyUnicode_FromEncodedObject? It should be a bit faster. * If old-st

[issue2630] repr() should not escape non-ASCII characters

Atsuo Ishimoto <[EMAIL PROTECTED]> added the comment: diff5.txt contains both code and documentation patch for PEP 3138. - In this patch, default error-handler of sys.stdout is always 'strict'. Added file: http://bugs.python.org/file10491/diff5.txt ___ Pytho

[issue2630] repr() should not escape non-ASCII characters

Atsuo Ishimoto <[EMAIL PROTECTED]> added the comment: docdiff1.txt contains a documentation for functions I added. Added file: http://bugs.python.org/file10456/docdiff1.txt ___ Python tracker <[EMAIL PROTECTED]>

[issue2630] repr() should not escape non-ASCII characters

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I'd be happy to have a separate more relaxed API for stackable codecs, however, the API should not be overloaded on the .encode() and .decode() methods on str and bytes objects. __ Tracker <[EMAIL PROTECTED]>

[issue2630] repr() should not escape non-ASCII characters

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: On 2008-05-06 19:10, Guido van Rossum wrote: > Guido van Rossum <[EMAIL PROTECTED]> added the comment: > > On Tue, May 6, 2008 at 1:26 AM, Marc-Andre Lemburg wrote: >> So you've limited the codec design to just doing Unicode<->bytes >>

[issue2630] repr() should not escape non-ASCII characters

Guido van Rossum <[EMAIL PROTECTED]> added the comment: On Tue, May 6, 2008 at 1:26 AM, Marc-Andre Lemburg wrote: > So you've limited the codec design to just doing Unicode<->bytes > conversions ? Yes. This was quite a conscious decision that was not taken lightly, with lots of community input

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: > No need to change anything, the diff is just too big for the code > review tool (Rietveld), but since it consists only of numbers we don't > need to review it anyway. :) I wonder why unicodename_db.h have not updated after makeunicodeda

[issue2630] repr() should not escape non-ASCII characters

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: On 2008-05-06 00:07, Guido van Rossum wrote: > Guido van Rossum <[EMAIL PROTECTED]> added the comment: > > On Fri, Apr 18, 2008 at 1:46 AM, Marc-Andre Lemburg > <[EMAIL PROTECTED]> wrote: >> On 2008-04-18 05:35, atsuo ishimoto wrote: >>

[issue2630] repr() should not escape non-ASCII characters

Guido van Rossum <[EMAIL PROTECTED]> added the comment: No need to change anything, the diff is just too big for the code review tool (Rietveld), but since it consists only of numbers we don't need to review it anyway. :) __ Tracker <[EMAIL PROTECTED]>

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: I forgot to mention to Modules/unicodename_db.h. The current unicodename_db.h looks it was generated by old Tools/unicode/makeunicodedata.py. This patch includes newly generated unicodename_db.h, but we can exclude the change if not necessa

[issue2630] repr() should not escape non-ASCII characters

Guido van Rossum <[EMAIL PROTECTED]> added the comment: FWIW, I've uploaded diff3.txt to Rietveld: http://codereview.appspot.com/767 Code review comments should be reflected here. I had to skip the change to Modules/unicodename_db.h which were too large for Rietveld to handle.

[issue2630] repr() should not escape non-ASCII characters

Guido van Rossum <[EMAIL PROTECTED]> added the comment: On Fri, Apr 18, 2008 at 1:46 AM, Marc-Andre Lemburg <[EMAIL PROTECTED]> wrote: > On 2008-04-18 05:35, atsuo ishimoto wrote: > > atsuo ishimoto <[EMAIL PROTECTED]> added the comment: > > > > Is a codec which encode() returns an Unicode all

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: New patch agaist current py3k branch. All the regr tests faild by my patch is now fixed as far as I can run. I also modified a doctest module a bit, so should be reviewed by module owners. Added file: http://bugs.python.org/file10193/diff3.

[issue2630] repr() should not escape non-ASCII characters

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: On 2008-04-18 05:35, atsuo ishimoto wrote: > atsuo ishimoto <[EMAIL PROTECTED]> added the comment: > > Is a codec which encode() returns an Unicode allowed in Python3? Sure, why not ? I think you have to ask another question: Is repr()

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: Is a codec which encode() returns an Unicode allowed in Python3? I started to think codec is not nessesary, but python function is enough. __ Tracker <[EMAIL PROTECTED]> _

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: > If you do want to have this more flexible, then make the encoding used > by unicode_repr() adjustable, turn the existing code into a codec (e.g. > "unicode-repr") and leave it setup as default. Turning code in unicode_repr() into a codec

[issue2630] repr() should not escape non-ASCII characters

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment: While it may be desirable to to have repr(unicode) return a non-ASCII string, the suggested approach is not suitable to solve the problem. repr() is usually used in logging and applications/users/tools don't expect to suddenly find non-AS

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: Sorry, I missed to write "for interactive session". I agree for sys.stdout and other files should not have default backslashescape, but for iteractive session, I think sys.stdout can have backslasespape handler to avoid exceptions.

[issue2630] repr() should not escape non-ASCII characters

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I don't think this is a good idea; I've explained why earlier on this issue. __ Tracker <[EMAIL PROTECTED]> __ __

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: I think sys.stdout need to have backslashreplace error handler. Without backslashreplace, print(listOfJapaneseString) prints nothing, but raises an exception. This is worse than Python2. __ Tracker <[EMAIL PR

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: I revised a patch against Python 3.0a4. - As-per suggestion from Michael Urman, unicode_repr() refers unicode database to determine characters to be hex-encoded. - sys.stdout doesn't use 'backslashreplace'. Added file: http://bugs.p

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: Okay, I'll revise a patch later today. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list maili

[issue2630] repr() should not escape non-ASCII characters

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Atsuo: I missed Michael Urman's comment. Can you copy it here, or (better :-) write a patch that uses it? Amaury: I think it would be okay to use backslashreplace as the default error handler for sys.stderr. Probably not for sys.stdout or

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: > What if we turn on the backslashreplace trick for some operations only? > For example: sys_displayhook and sys_excepthook. It would be difficult, since *_repr() API don't know who is the caller. __ Tracker

[issue2630] repr() should not escape non-ASCII characters

atsuo ishimoto <[EMAIL PROTECTED]> added the comment: > I think this has potential, but it is too liberal. There are many more > characters that cannot be assumed printable, e.g. many of the Latin-1 > characters in the range 0x80 through 0x9F. Isn't there some Unicode > data table that shows

[issue2630] repr() should not escape non-ASCII characters

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: What if we turn on the backslashreplace trick for some operations only? For example: sys_displayhook and sys_excepthook. -- nosy: +amaury.forgeotdarc __ Tracker <[EMAIL PROTECTED]>

[issue2630] repr() should not escape non-ASCII characters

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I think this has potential, but it is too liberal. There are many more characters that cannot be assumed printable, e.g. many of the Latin-1 characters in the range 0x80 through 0x9F. Isn't there some Unicode data table that shows code poin

[issue2630] repr() should not escape non-ASCII characters

New submission from atsuo ishimoto <[EMAIL PROTECTED]>: In py3k, repr() escapes non-ASCII characters in Unicode to \u as Python 2. This is unpleasant feature if you are working with non-latin characters. This issue was once discussed by Hye-Shik Chang[1], but was rejected. Here's a new challe