
On Wed, 19 Oct 2011 09:25:14 -0400 Itamar Turner-Trauring <itamar@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.