The way WebOb deals with this is by allowing users to supply a "default_charset"
attribute on requests (or during request construction). It'd probably be enough
to allow people to do the same for Zope requests (maybe as a zope2.ini
parameter); when it's non-None, use that as the charset to decode to unicode
using. If it *is* None, behave as it always has.
Hanno Schlichting wrote:
> Got a brainstorming question for the repoze.zope2 folks.
> Currently repoze.zope2 reuses the Zope2 ZPublisher request object pretty
> much directly. This is nice for full backwards compatibility, which has
> been a primary concern during its initial development.
> At some point in the Zope2 or at least Plone evolution we need to switch
> the request to move from passing on encoded strings to doing the Unicode
> conversion of at least form data.
> I think there is no graceful way of doing this. It's a binary choice of
> either doing it or not. At least for Plone4 which is using repoze.zope2
> we have an increasing number of cases where we use Unicode instead of
> encoded strings, especially when using Zope3 technology like
> zope.formlib or z3c.form.
> Does anyone know of any good reason why we shouldn't switch over the
> request object to something more modern and using Unicode?
> It's a backwards incompatible change, but one that I'd be willing to do
> and support at least on the Plone level. For Zope2 itself some more
> conditional code and optional support in some places might be the more
> appropriate answer.
> Repoze-dev mailing list
Repoze-dev mailing list