Prev: How do I add method dynamically to module using C API?
Next: Appending to a file using Python API
From: Martin v. Loewis on 8 Jul 2010 00:50
Am 07.07.2010 23:10, schrieb Brendan Abel:
>>>> One thing that would be very useful is how to maintain something that
>>>> works on 2.x and 3.x, but not limiting yourself to 2.6. Giving up
>>>> versions below 2.6 is out of the question for most projects with a
>>>> significant userbase IMHO. As such, the idea of running the python 3
>>>> warnings is not so useful IMHO - unless it could be made to work
>>>> better for python 2.x < 2.6, but I am not sure the idea even makes
>>>> sense.
>
> The entire fact that 3.x was *designed* to be incompatible should tell
> you that supporting 2.x and 3.x with a single code base is a bad idea,
> except for the very smallest of projects. This is the point where a
> project should fork and provide two different versions.

I completely disagree. My personal experience is that this is well
possible even for large code bases, and I would recommend having a
single code base for 2.x and 3.x *in particular* for large projects,
which probably need to support 2.x users for quite some time, but
simultaneously need to support 3.x users.

Regards,
Martin

From: Martin v. Loewis on 8 Jul 2010 00:52
> Python 3.x will continue to change. The incompatibilities between 3.x
> and 2.x will only become more numerous. If your goal is to support
> 2.x, and 3.x, you'd be best supporting them separately.

I don't think that's a particularly good approach. Having a single code
base for both likely reduced the maintenance burden significantly
compared to a code fork.

Regards,
Martin
From: Martin v. Loewis on 8 Jul 2010 01:58
> I just
> couldn't get through on the python-dev list that I couldn't just
> upgrade my code to 2.6 and then use 2to3 to keep in step across the
> 2-3 chasm, as this would leave behind my faithful pre-2.6 users.

Not sure whom you had been talking to. But I would have tried to explain
that you don't *have* to port to 2.6 to use 2to3 - it will
work just as fine with 2.3 code, and earlier.

> - No use of sets. Instead I defined a very simple set simulation
> using dict keys, which could be interchanged with set for later
> versions.

This I don't understand. IIUC, you want to support 2.3 and later.
Now, 2.3 already has a set module, even though set is not a builtin.
So you could use sets just as well.

> - No generator expressions, only list comprehensions.

Ok. Not sure how this causes problems, though - just don't use them, then.

> - No use of decorators. BUT, pyparsing includes a decorator method,
> traceParseAction, which can be used by users with later Pythons as
> @traceParseAction in their own code.

Of course, users of older Python versions could explicitly wrap
the functions with the decorator if they wanted to.

> - No print statements. As pyparsing is intended to be an internal
> module, it does no I/O as part of its function - it only processes a
> given string, and returns a data structure.

If you don't need them, fine. If you do, I'd just let 2to3 transform them.

> - Python 2-3 compatible exception syntax. This may have been my
> trickiest step. The change of syntax for except from
>
> except ExceptionType, ex:
>
> to:
>
> except ExceptionType as ex:
>
> is completely forward and backward incompatible. The workaround is to
> rewrite as:
>
> except ExceptionType:
> ex = sys.exc_info()[0]

Likewise, and more importantly so: use 2to3. It can be done this way,
but I find the 2to3 solution much cleaner.

> But in
> the meantime, I am still able to support all versions of Python NOW,
> and I plan to continue doing so (albeit "support" for 2.x versions
> will eventually mean "continue to offer a frozen feature set, with
> minimal bug-fixing if any").

The same would have been possible if you had chosen to use 2to3.

Regards,
Martin
 | 
Pages: 1
Prev: How do I add method dynamically to module using C API?
Next: Appending to a file using Python API