[Twisted-Python] Twisted for Python 3

[Antoine Pitrou]

On Wed, 19 Oct 2011 09:25:14 -0400
Itamar Turner-Trauring <itamar at itamarst.org> wrote:
> 
> Cool! Any patches you can submit to us that would make the code more
> Python 3 compatible, while not breaking Python 2.5 and later, would make
> your life easier going forward.

Yes, I've started doing that. However, the extent of these patches is
quite limited.
Most changes I have to make have to do with introducing bytes literals,
or fixing specific issues under Python 3. For example, I could post the
following patch for t.p.failure, but would you accept it?

@@ -464,6 +468,14 @@ class Failure:
         # added 2003-06-23. See comment above in __init__
         c['tb'] = None
 
+        try:
+            # Clear other references held by exception objects
+            c['value'].__cause__ = None
+            c['value'].__context__ = None
+            c['value'].__traceback__ = None
+        except AttributeError:
+            pass
+
         if self.stack is not None:
             # XXX: This is a band-aid.  I can't figure out where these
             # (failure.stack is None) instances are coming from.

> I notice you have banana getting extra op code for bytes... I think a
> better solution is to use existing 'string' op code for bytes, and
> rejecting unicode strings. What banana calls 'string' *is* bytes, it
> doesn't support unicode:

Indeed, this is debatable. But generally, marshalling libraries have to
evolve a bit when ported to Python 3. There's no way the semantic gap
between 2.x and 3.x can be ignored.

I think banana in 3.x *has* to support both types. str is a fundamental
type in 3.x (think that class names, function names, filenames, etc.
all are str by default) and not supporting it in a marshalling library
would be pretty much awkward. bytes is fundamental in a networking
library and not supporting it would be similarly awkward :)

Moreover, 3.x has a natural preference for unicode strings while
2.x has a natural preference for 8-bit strings. Where high-level
data is handled, Python 3 users will expect to use str object, not bytes
objects, for text data (if you marshal e.g. a class name, you don't
expect it to come out as bytes... and neither would Perspective
Broker, I guess). Str objects also have more features, which make them
more amenable to parsing and formatting.

That's why I think translating the "string" type to 3.x str objects is
what users would expect in practice. This is also the decision
taken in the standard pickle module: if you unpickle a 2.x pickle
containing str objects, you get 3.x str objects (not bytes).

> In general, anywhere existing Twisted code uses a Python 2 normal
> string, you should have the Python 3 version only accept bytes.

Due to the aforementioned differences, I don't think that's as simple.
For example, filenames are pretty much str (unicode) by default in
Python 3, even though you can also use bytes (but it's discouraged
under Windows). Command-line arguments are also str, as are many other
things. And I'll think you'll agree that it's more natural to ask for
the HTTP "GET" method than for the b"GET" method.

(no, I haven't started on twisted.web yet)

Regards

Antoine.