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

[Guido van Rossum]

> Ok, here's the motivation for those (tiny) changes.

The "(tiny)" suggests you already feel guilty.  Good! :-)

> I'm working on internationalizing several sites, and in both cases I
> absolutely need Unicode working in PT. Currently the framework I use is
> Localizer (but another framework would have the same problems).
> 
> Before that change, if you wanted a Unicode-aware Zope, you had to take
> 2.5.1 and patch it, or take 2.6 and patch it, or take 2.7 and patch it.
> 
> With that change, it's a simple matter for Localizer to provide a better
> StringIO to the parts of TAL and PT that need one to function correctly:
> it monkey-patches the method (dynamically replaces it in the class --
> yes it's somewhat ugly but much better that telling people to use
> "patch", and besides everybody's doing it :-)

More indicators of guilt. :-)

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.

And have you tried to find a solution that allows one to select the
StringIO implementation more selectively, e.g. only for templates used
by such-and-such a product?  I'm not entirely sure of the scope of
your needs, so I have to be vague here; but I wonder if providing a
different StringIO couldn't aversely affect other parts of a site.
The global approach makes this hard to debug: you install product X,
and later you find that page Y, which makes no use of X, breaks (or
becomes 100x slower).  It will be very hard for the poor site
maintainer to track the failure of page Y down to the earlier install
of product X!

> I completely agree that this is not a panacea, and that it would be much
> better to put the correct StringIO in Zope and be done with it, but a
> completely corrected Unicode-aware StringIO is something I don't have
> and which is, from what I gather, not trivial. Guido probably has more
> info on that.

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.

Since you don't have a completely correct StringIO implementation,
what *do* you have?  Are you sure that's not going to break other uses
of page templates?

> In the meantime, I can use a very stupid unicode-StringIO in Localizer
> (it converts everything to the REQUEST charset at .write() time) without
> impacting core Zope. I can point people at Localizer and tell them to
> install Localizer and Zope 2.6 and that's it, no messy patching
> required.
> 
> And when the time is right, we can put an adequate StringIO in Zope and
> forget this little mess (which, I don't consider that messy).

The word monkey-patch is the very definition of messy.

> I'm sorry I haven't discussed these changes before, I should have. This
> is not an architectural change at all, simply a temporary hook for other
> code, I didn't think it would pose problems.
> 
> What do you think about it now. Should I revert them?

Ask the Zope Pope.

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