[Zope-Coders] Re: [Zope-Checkins] CVS: Zope27/lib/python/TAL - TALInterpreter.py:1.68.26.2

[Guido van Rossum]

> Monkey-patching really is a funny sport, anyone will tell you that :-)

Like dwarf tossing? :-)

> > Did you consider alternative approaches?  E.g. you could provide an
> > official API (e.g. in the form of a module-global function) that
> > allows one to set the StringIO implementation used.
> 
> Because I didn't want to impact any other uses of StringIO, I changed
> only the two modules that were posing problems for i18n.

Sorry, you misunderstood.  I meant for those two modules.  They could
get their StringIO from a shared private global, and there could be a
function to set that global.

> > Depends on what you want.  Since Python has no standard API for
> > writing Unicode to files, this is indeed nontrivial.  I think the
> > Python StringIO.py might accidentally support Unicode.
> 
> It doesn't (python 2.2):
> from StringIO import StringIO
> s = StringIO()
> s.write('é')
> s.write(u'a')
> s.getvalue()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.2/StringIO.py", line 169, in getvalue
>     self.buf += ''.join(self.buflist)
> UnicodeError: ASCII decoding error: ordinal not in range(128)

Depends on what you call "support".  :-)

> But then it's not clear what should be done in any case. In this
> example the first 'é' is in a "native" coding and shouldn't be
> allowed by the application. But because TALES can get its values
> from python code, it's conceivable that we can receive native
> strings and have to decide what to do with them.
> 
> Localizer's choice is to convert all Unicode strings to standard
> strings in the desired output charset, and leave "native" strings
> alone (supposing the application has generated them in the correct
> way).

OK, but then I don't understand why it needs to solve the problem you
show above.  Either it converts everything to an 8-bit encoding before
it hits the StringIO object, and then you don't need a Unicode-aware
StringIO object, or it *only* writes Unicode to the StringIO object
(in which case StringIO.py is just fine).

> 2.6's choice is to allow building a complete response using Unicode
> strings, and do the conversion only upon publishing to the
> client. But then we have to convert a mix of non-unicode strings and
> unicode strings, which can cause the problems outlined above.

I don't understand how your monkey patch helps you solve this
solution.

(And if you have a patch for StringIO.py, maybe you can make it
available for the Python standard library?  Others might need this.)

> > > What do you think about it now. Should I revert them?
> > 
> > Ask the Zope Pope.
> 
> Jim, do you want those reverted?
> 
> Again, for the record, my argument to leave those in is: they don't
> harm, they'll be removed later, and in the meantime third-party products
> can still function.

At the very best, I propose something like this instead:

from StringIO import StringIO

CustomStringIOClass = StringIO

def setCustomStringIO(C):
    CustomStringIOClass = C

class C: # This is the class you patched

    def StringIO(self):
        return self.CustomStringIOClass()


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