New opcode:  rawtextBeginScope.  This is equivalent to:

[endScope] rawtextColumn setPosition beginScope

These two sequences are very common in some of the slowest test documents
I've been using.

Lots more micro-optimization of the same sorts as we've been doing.

Updated to reflect the re-ordering of scope boundaries and text chunks.

New optimization of the instruction stream:  beginScope/endScope
instructions are always pushed in front of text chunks; the affect of
this is that many text chunks previously separated by scope boundaries
are now joined together, causing fewer instructions to be generated.

Do not call sys.exc_info() to initialize some locals we don't use.

SafeMapping.has_get():
    Simplify in order to reduce the number of Python bytecodes.  There
    is no longer a branch, which isn't strictly necessary.

Context.evaluateStructure(), .evaluateMacro():
    Since these methods are essentially synonyms for evaluate(), avoid
    the extra method lookup & call by simply making them aliases.

Context.evaluate():
    Re-arrange the try/except/except to avoid some of the exception
    catching by moving part of the try clause into an else clause.

When operating on raw strings which had DOS-style linefeeds (e.g. "\r\n"), StructuredText would neglect to strip the trailing garbage off the end of a paragraph.  Thus, the test for "examples" and other features that depended on the last characters in a paragraph to not be whitespace for proper operation were failing, causing problems mainly for people who use Windows to author STX content.  This is now fixed.

Use Ken's wording for the upload paragraph, and look for the body in REQUEST.other before REQUEST.form, so that errors will show up.

Small optimizations to get this a little more out of the way when profiling.

Delay expectation of being able to access the DummyEngine class, allowing
circular import by the DummyEngine module.

This makes FreeBSD people happy because they will never complain again
that their Zope system claims to be a Linux system.

have to try to figure out how to call _makeFunction().  In Zope 2.3.x
_makeFunction() had a parameter.

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.