[Python-Dev] Multibyte repr()

[Guido van Rossum]

> > revision 2.190
> > date: 2002/10/07 13:55:50;  author: loewis;  state: Exp;  lines: +68 -15
> > Patch #479898: Use multibyte C library for printing strings if available.
> > ----------------------------
> > 
> > Was this really a good idea???
> 
> I think the submitter wanted to get "proper" output in interactive
> mode for strings. For most cases, it might be sufficient to active the
> code for tp_print only, not for tp_repr.
> 
> Would that be better?

Not really, because then it would break the equivalence between repr()
and entering a value at the command line.  It would also cause
surprises because sometimes repr() is invoked anyway (when there's a
container that doesn't have a tp_print function).

I wouldn't mind this so much if GNU readline didn't do an evil thing
by calling setlocale().  Maybe the readline C extension  should
restore the locale?

This patch seems to take care of it, except I'm not sure if we can
assume that <locale.h> and setlocale() are always available.  This
doesn't seem to have any ill effects on the operation of GNU readline:

//////////////////////////////////////////////////////////////////////
*** readline.c	2 Aug 2002 02:27:13 -0000	2.52
--- readline.c	9 Oct 2002 20:10:33 -0000
***************
*** 11,16 ****
--- 11,17 ----
  #include <setjmp.h>
  #include <signal.h>
  #include <errno.h>
+ #include <locale.h>
  
  /* GNU readline definitions */
  #undef HAVE_CONFIG_H /* Else readline/chardefs.h includes strings.h */
***************
*** 538,543 ****
--- 539,545 ----
  static void
  setup_readline(void)
  {
+ 	char *saved_locale = NULL;
  	using_history();
  
  	rl_readline_name = "python";
***************
*** 570,576 ****
--- 572,580 ----
  	 * XXX: A bug in the readline-2.2 library causes a memory leak
  	 * inside this function.  Nothing we can do about it.
  	 */
+ 	saved_locale = setlocale(LC_CTYPE, NULL);
  	rl_initialize();
+ 	setlocale(LC_CTYPE, saved_locale); /* Restore locale */
  }
  
  
//////////////////////////////////////////////////////////////////////

--Guido van Rossum (home page: http://www.python.org/~guido/)