[Zope3-dev] string agnostic page templates, again

[Fred Drake]

On Wed, 08 Sep 2004 12:12:08 +0200, Martijn Faassen <faassen at infrae.com> wrote:
> Right, there's indeed no good to deal with it so we shouldn't. The
> system should however know it's getting a non-plain-ascii classic string
> if we want to improve the error reporting. non-ascii and unicode don't
> mix. ascii mixes with both.

In an ideal world, yes.

> I hadn't considered that strategy yet. It may of course theoretically
> lead to surprising results, as a later call may actually alter the first
> result retroactively. I think that this is mostly theoretical, however.

I don't think there's any other choice if you want to be
Unicode-agnostic.  I consider the consequent late decision making an
unfortunate necessity, but the fact that decisions can be made (and
used) earlier than what's currently happening is a good thing
regardless.  I expect non-string values coming first will be the
oddball case.

> It'd be nice to get an error as soon as > ord(127) text has been seen
> and then unicode gets added. I don't know whether there's a reasonably
> fast way to check for > ord(127)-ness though.

I suspect the fastest way to tell is to simply attempt conversion with
unicode().  This assumes nobody is messing with the default encoding;
it *should* never be anything but ASCII anyway.  ;-)  I'm not sure how
much specifying "ascii" as the 2nd arg to unicode() affects
performance.

> It'd also be nice to get an error as soon as > ord(127) text gets added
> and we've already seen unicode.

If unicode() can be trusted to handle that case, this comes for free
in my imagined implementation.

> Unless there are strong reasons from the perspective of efficiency I'd
> like to see such immediate errors, see below.

Efficiency is a big concern.  I still hear ZPT vs. DTML performance
comparisons, and don't want to make changing that any harder than it
has to be.  ;-)

> They're behavioral expectations. I'd like to see immediate errors being
> raised in the engine *as soon as* something unsolvable is going on,
> instead of what currently is the case, where you only find out in the
> end of the engine where all the strings get added together. Getting an
> immediate error should make things easier to debug, as you can hopefully
> better see where you went wrong.

I'll keep these in mind when I get the round tuits for the
implementation.  Unless you beat me to that.  ;-)


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation