A (minor) change to the bytecode format: for "extended" attributes
(handled by TALInterpreter.attrAction()), the instruction contains the
integer previously retrieved from the actionIndex table; the bytecode
generator now takes care of the lookup.  This allows attrAction() to
no longer need to lookup the table that it used to lookup the
integers.

Many handlers are now separated into TAL and non-TAL versions -- the
TALInterpreter constructor determines which dispatch table to use when
it initializes self.tal (which is not changed later).  This allows
each of the handlers to do only what is needed without having to
decide based on the self.tal attribute.

TALInterpreter.do_startTag() no longer contains a special case for an
empty attribute list; that case is already optimized away by the
bytecode generator.  What remains would actually work in that case,
but it simply doesn't occur.  This removes one test of the attrList
parameter.

Each bytecode now carries exactly one argument, but the arg is only an
extra layer of tuple if the handler method needs more than one
parameter.

The handlers are also modified so that they require exactly one
argument, which is a tuple only if they need more than one argument
from the instruction.  This simplifies the dispatch code in
TALInterpreter.interpret() just slightly.

Changed the version number of the bytecode again, since Guido tells me
Evan calls this version 1.3.2.

Micro-optimization to avoid function calls.

Update the one instance of affected bytecode to reflect the pre-rendering
of "normal" attributes.

Two speedups in TALInterpreter.do_startTag():

The bytecode has changed to use a pre-rendered form for "normal"
attributes; this allows some logic and string formatting to be skipped
for these attributes.

The self.col value is now maintained in local variables inside do_startTag(),
reducing the number of instance attribute lookups and assignments
substantially.  Saving the new value is ensured by a try/finally block
since the attrAction() method can raise an exception.

Added a few ultra-micro speedups as well to avoid instance attribute
lookups.

Changing the bytecode slightly once again:

For startTag and startEndTag instructions that cannot be optimized away,
"normal" attributes are now represented by their rendered form, allowing
TALInterpreter.do_startTag() to do less work when it can be done ahead of
time.

Use string concatenation where that's simpler and faster than
sprintf-style formatting.

Made meta-type in the management interface of ZClass instances into a link to the ZClass definition.

revealed it.  "print" with output to a stream and a trailing comma needs to
end with a POP_TOP instruction.

Update the expected bytecodes to reflect the merger of the beginScope and
rawAttrs bytecodes.

Merge the rawAttrs bytecode into the beginScope bytecode.  These were only
emitted as a pair, so there is no need to separate them.

(This only gives a very minor performance boost, but it comes for free.)

Collector #2290: better handling of subject header in Mailhost.py

not behave as expected.  Permissions granted to Anonymous didn't
necessarily get granted to other roles, for one thing.  This is an
issue especially for the CMF.  User.allowed()
is practically the same thing with the parameters reversed, so I changed
checkPermission() to call User.allowed() instead.  We should be able to
deprecate User.has_role() now.  I also implemented a minor (micro?)
optimization by calling the aq_base module function instead of using getattr().

while replacing an import * by a more selective import)

so that ExtensionClass can find the correct <name>__roles__ attribute
of the method's class.  However it was discovered that this protocol
has a flaw: if a DTMLMethod is bound to multiple names, there is no
way for default__class_init__ to tell which name is the right one.

This change adds code that detects the condition and makes the name
explicit in all places where it occurs in the Zope core.  There are
likely products out there that have the same condition so they will
need a small correction.  For now this is a warning but it might be
appropriate to later make the condition an error.

Update all the expected bytecode to conform to the new format.

different now!

Use saved type objects when calling isinstance() instead of calling
type() each time.

getProgramMode(), getProgramVersion():
    Update to the new byte-code format.

quote():
    Change the way cgi.escape() is referenced to avoid runtime
    lookups.

    Re-write generated instructions:  (op, arg1, arg2, ...) becomes
    (op, (arg1, arg2, ...)) to reflect the change in the dispatch
    mechanism in TALInterpreter -- this avoids a tuple concatenation
    at dispatch time.

techniques of reducing the number of lookups and avoiding method
calls.

More interestingly, the dispatch machinery has changed, especially
TALInterpreter.iterpret().  Each instruction is now composed of a
2-tuple of the form (opcode, (arg1, arg2, ...)).  This is important as
it allows more efficient unpacking and construction of the argument
list for the call to the handlers for individual bytecodes.

The bytecode handlers are also located differently.  Instead of using
the opcode string to construct a method name, retrieve a bound method,
and then calling it via apply(), a dictionary of handler functions is
created as part of the class definition.  Handlers are retrieved from
this dictionary by opcode string (avoiding string concatenation and
bound method creation in the inner dispatch loop).  The handlers (now
functions rather than methods) are then called using apply(), creating
the arguments to the handler by tuple concatenation, which is faster
than creating the bound method and then using the slower
method-calling machinery.  Temporary variables are avoided whenever
possible.

The test for "debug mode" in TALInterpreter.interpret() was moved out
of the dispatch loop; it is used to select one of the two versions of
the loop.

Support has been added for two new bytecodes:
  rawtextColumn -- used when the TALGenerator can determine the
                   resulting column number ahead of time (the text
                   includes a newline)

  rawtextOffset -- used when the TALGenerator cannot determine the
                   final column of the text (there is no newline).

These new bytecodes allow the interpreter to avoid having to search
for a newline for all rawtext instructions -- the compiler is able to
determine which of these two cases is appropriate for each rawtext
chunk -- the old 'rawtext' instruction is no longer generated.

Re-phrased some conditions in if statements to allow more
short-circuiting.

    Very aggressively cache anything that involves a global lookup.

restrictedTraverse():
    Only cache things once it's possible we might use them.  Use the
    cached getattr() in one plase where the global was being looked up
    again.  Cache hasattr() as well.  Only construct the marker (M)
    once, not once for each call.

    The _push() and _pop() methods aren't really any different from
    the push() and pop() methods from the base MultiMap, so we can use
    them directly to avoid a lot of looks and method invocation
    overhead, and it's easier to tell from the code that they are just
    a renaming.

Context.beginScope(), .endScope():
    Move an attribute access out of the loop since the attribute isn't
    re-bound inside the loop.

Context.evaluateText():
    Re-phrase the condition in the if statement to allow the runtime
    to perform fewer global name lookups when possible, and avoid the
    tuple construction completely.

non XML compliant documents to be sent to a webdav client

Do not test for sys.exc_info(); it was already present in Python 2.1.
This simplifies code and improves performance (very slightly).

In two places, object type was tested by calling type() on each of two
values and comparing the results (4 dict lookups, 2 Python->C function
calls).  Replace each with an isinstance() call comparing to a saved
type object (3 dict lookups, 1 Python->C function call, more future-proof).

Moved ISO8601 into DateTime class.
DateTime constructor now also accepts ISO8601 dates.