Thanks for the review!  I believe the changes in question are safe, but
it's good to have people looking at them.

Moving away from raising a string literal is unavoidable since Python 3
only allows raising exception objects.  It's unfortunate we have no test
coverage for the front ends (and to declare Python 3 support complete,
people will need to test all the front ends manually with Python 3), but
this is probably one of the safest changes in the untested code.

Regarding not checking for ascii, I think it's fine to treat a non-ascii
key the same as any other key that's ascii but invalid, and thus
simplify the code by having more places use the same encoding/decoding
functions.  (Whether non-ascii property names ought to be supported by
Roundup, presuming they aren't at present, is an interesting question,
but not one we need to address now.)

Removal of FasterStringIO was noted in the description I gave for patch
44 in the comments on this issue.  It's unavoidable in that it depended
on internals of the old Python 2 StringIO module.  My understanding is
that the main thing that matters for Roundup performance in large
instances is keeping down the number of SQL database queries involved in
producing a page or carrying out an action; even if FasterStringIO was
relevant at one point in the original context for which the TAL code was
written, it probably isn't very relevant now in Roundup.

Possible performance cost from iteritems etc. changes (which was noted
in the description of patch 20 I sent to roundup-devel) is hard to avoid
if you want to write the code directly in a modern (Python 3) style as
much as possible (not using a wrapper layer unless strictly necessary),
because the code in question (using items when you want to iterate,
list() when an explicit list is needed) is the modern style, while also
being compatible but less efficient with Python 2.  Again, I think the
area of biggest performance concern in Roundup is keeping down the
number of SQL queries, which should be unaffected by all these changes.