[Python-Dev] repr vs. str and locales again
Fri, 19 May 2000 09:56:50 -0700 (PDT)
On Fri, 19 May 2000, Guido van Rossum wrote:
> The email below suggests a simple solution to a problem that
> e.g. Fran\347ois Pinard brought up long ago; repr() of a string turns
> all non-ASCII chars into \oct escapes. Jyrki's solution: use
> isprint(), which makes it locale-dependent. I can live with this.
Changing the behaviour of repr() (a function that internally
converts data into data) based on a fixed global system parameter
makes me uncomfortable. Wouldn't it make more sense for the
locale business to be a property of the stream that the string
is being printed on?
This was the gist of my proposal for files having a printout
method a while ago. I understand if that proposal is a bit too
much of a change to swallow at once, but i'd like to ensure the
door stays open to let it be possible in the future.
Surely there are other language systems that deal with the
issue of "nicely" printing their own data structures for human
interpretation... anyone have any experience to share? The
printout/printon thing originally comes from Smalltalk, i believe.
(...which reminds me -- i played with Squeak the other day and
thought to myself, it would be cool to browse and edit code in
Python with a system browser like that.)
> This hits for example when Zope with squishdot weblog (squishdot
> 0.3.2-3 with zope 2.1.6-1) creates a text index from posted articles -
> strings with valid Latin1 characters get indexed as backslash-escaped
> octal codes, and thus become unsearchable.
The above comment in particular strikes me as very fishy.
How on earth can the escaping behaviour of repr() affect the
indexing of text? Surely when you do a search, you search for
exactly what you asked for.
And does the above mean that, with Jyrki's proposed fix, the
sorting and searching behaviour of Squishdot will suddenly
change, and magically differ from locale to locale? Is that
something we want? (That last is not a rhetorical question --
my gut says no, but i don't actually have enough experience
working with these issues to know the answer.)
"Simple, yet complex."
-- Lenore Snell