Prev: CFP for Surge Scalability Conference 2010
Next: IMAP Problems
From: Thomas Jollans on 6 Jul 2010 13:34
On 07/06/2010 07:17 PM, Terry Reedy wrote:
> docs.python.org / dev/3.0/howto/cporting.html

http://docs.python.org/py3k/howto/cporting.html
From: MRAB on 7 Jul 2010 18:00
Brendan Abel wrote:
>>>> 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 wouldn't say that 3.x was designed to be incompatible. It was designed
to tidy the language, and the incompatibilities are an unfortunate
result.
From: MRAB on 7 Jul 2010 21:22
geremy condra wrote:
> On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007brendan(a)gmail.com> wrote:
>> On Jul 7, 3:00 pm, MRAB <pyt...(a)mrabarnett.plus.com> wrote:
>>> Brendan Abel wrote:
>>>>>>> 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 wouldn't say that 3.x was designed to be incompatible. It was designed
>>> to tidy the language, and the incompatibilities are an unfortunate
>>> result.
>> You're missing the point, and arguing semantics. It's a good thing I
>> didn't misspell anything.
>>
>> 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 maintain two projects that have to work from 2.5 to 3.1. On one of
> them (~5kloc) we took the separate support route, and on the other
> (~30kloc) I decided to keep a single codebase. IME the maintenance
> burden on the former is substantially higher than the latter. Is the
> difference in difficulty perhaps domain-related, or a result of a
> certain style of coding? Could you give us some more details about
> what you were working on that caused you to conclude this?
>
In my work on the regex module I use a single codebase and generate the
sources for Python 2.5-2.7 and for Python 3.1 from it. It works easily
enough for me.
From: Terry Reedy on 7 Jul 2010 23:26
On 7/7/2010 5:29 AM, geremy condra wrote:
> On Tue, Jul 6, 2010 at 1:37 AM, Terry Reedy<tjreedy(a)udel.edu> wrote:
>> On 7/5/2010 9:00 PM, Philip Semanchuk wrote:
>>> On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:
>>>> On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchu

>>>>> I ported two pure C extensions from 2 to 3 and was even able to keep a
>>>>> single C codebase. I'd be willing to contribute my experiences to a
>>>>> document
>>>>> somewhere. (Is there a Wiki?)

>>>> Indeed there is: http://wiki.python.org/moin/

>>> Thanks. I don't want to appear ungrateful, but I was hoping for
>>> something specific to the 2-to-3 conversion. I guess someone has to
>>> start somewhere...

>> There is an existing 2to3 and other pages for Python code conversion. I do
>> not know of any for CAPI conversion. The need for such has been acknowledged
>> among the devs but if there is nothing yet, we need someone with specialized
>> experience and a bit of time to make a first draft. If you start one, give
>> it an easy to remember name C2to3? 2to3Capi? You choose. And link to it from
>> the 2to3 pag
>> In his post on this thread, Martin Loewis volunteered to list what he knows
>> from psycopg2 if someone else will edit.

> I'm not sure why I don't have this post, but I'm happy to help edit
> etc if Martin
> wants to put together a rough draft.

Since I wrote that, someone pointed out the the Python How-to collection
includes Porting Extension Modules to 3.0
by Benjamim Peterson. So all Pyilip or Martin need to do is read that
and suggest additions.

Since it is part of the doc set, I presume an issue could be opened on
the tracker.

--
Terry Jan Reedy

From: Terry Reedy on 7 Jul 2010 23:44
On 7/7/2010 4:31 AM, Paul McGuire wrote:

[snip interesting report on how Paul suppost pyparsing for 2.3 to 3.1]

Thank you for this.

Do you think such cross-version support would have been easier or harder
if the major changes and deletions in 3.0 has been spread over several
versions, such as 2.5 - 2.7. In other words, suppose the Python 3 idea
never occurred to anyone and

2.5 dropped the old int division and finished the unification of int and
long.

2.6 dropped classic classes and switched range, filter, and map to their
iterator versions.

2.7 made unicode the text type

This is not purely a hypothetical question since the issue of spreading
or bunching changes may arise again in the future.

--
Terry Jan Reedy

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: CFP for Surge Scalability Conference 2010
Next: IMAP Problems