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

[Florent Guillaume]

> +    def StringIO(self):
> +        # Third-party products wishing to provide a full Unicode-aware
> +        # StringIO can do so by monkey-patching this method.
> +        return StringIO()
> +

> -        self.stream = stream = StringIO()
> +        self.stream = stream = self.StringIO()

On Mon, 2002-09-09 at 14:30, Guido van Rossum wrote:
> > > Um, that's not the same.  The word "overriding" implies "in a
> > > subclass".  You're talking about patching a method in an *existing*
> > > class.  The difference is that the latter affects all users of the
> > > class.  For urgent bugfixes I can understand this technique.  But
> > > Florent's change suggests that this is a *feature* in this case.  I
> > > find that hard to swallow as a general mechanism, and because his
> > > checkin comments gave not additional motivation or a pointer to an
> > > accepted decision, I question the validity of his checkin, *unless* he
> > > meant overriding the method in a subclass (which is goodness).
> > 
> > Right, it is not overriding in the OO sense.  Sorry,  I am still
> > waking up. :-)  But monkey-patching is still generally accepted as
> > how I described it.  Maybe FG means something different by it?
> 
> Let's hear it from FG.  Was this change discussed anywhere?

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

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 :-)

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.

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).


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?


Florent


-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg@nuxeo.com