From: Philip Semanchuk on

On Jul 5, 2010, at 4:30 PM, D'Arcy J.M. Cain wrote:

> On Mon, 05 Jul 2010 14:42:13 -0400
> Terry Reedy <tjreedy(a)udel.edu> wrote:
>> Good start. Now what is blocking those four?
>> Lack of developer interest/time/ability?
>> or something else that they need?
>
> How about a basic how-to document? I maintain PyGreSQL and would like
> to move it to 3.x right now but I don't even know what the issues are.
> I can see on the site the 2.x documents and the 3.x documents for
> extending with C modules and I can read both from end to end but that
> hits the time issue above. If there was a relatively simple document
> that showed what needed to be changed in the C code we could get
> started on the transition sooner.
>
> Or is there no change at the C level? That would make things easy.

There are definitely changes at the C level.

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?) I would have found such a
document very helpful before I started porting.

Cheers
Philip

From: Philip Semanchuk on

On Jul 5, 2010, at 6:41 PM, Chris Rebert wrote:

> On Mon, Jul 5, 2010 at 3:38 PM, Philip Semanchuk
> <philip(a)semanchuk.com> wrote:
>> On Jul 5, 2010, at 4:30 PM, D'Arcy J.M. Cain wrote:
>>> On Mon, 05 Jul 2010 14:42:13 -0400
>>> Terry Reedy <tjreedy(a)udel.edu> wrote:
>>>> Good start. Now what is blocking those four?
>>>> Lack of developer interest/time/ability?
>>>> or something else that they need?
>>>
>>> How about a basic how-to document? I maintain PyGreSQL and would
>>> like
>>> to move it to 3.x right now but I don't even know what the issues
>>> are.
>>> I can see on the site the 2.x documents and the 3.x documents for
>>> extending with C modules and I can read both from end to end but
>>> that
>>> hits the time issue above. If there was a relatively simple
>>> document
>>> that showed what needed to be changed in the C code we could get
>>> started on the transition sooner.
>>>
>>> Or is there no change at the C level? That would make things easy.
>>
>> There are definitely changes at the C level.
>>
>> 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...






From: Terry Reedy on
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 Semanchuk

>>> 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 page

In his post on this thread, Martin Loewis volunteered to list what he
knows from psycopg2 if someone else will edit.

--
Terry Jan Reedy

From: Stefan Behnel on
Steven D'Aprano, 05.07.2010 08:31:
> On Sun, 04 Jul 2010 17:34:04 -0700, sturlamolden wrote:
>
>> Using Python 2.x for new
>> projects is not advisable (at least many will think so), and using 3.x
>> is not possible. What to do? It's not a helpful situation for Python.
>
> That's pure FUD.
>
> Python 2.7 will be supported longer than the normal support period for
> versions 2.6, 2.5, 2.4, ... so if you have a new project that requires
> libraries that aren't available for 3.1, then go right ahead and use 2.7.
> By the time 2.7 is no longer supported (probably around the time 3.4
> comes out?), the library situation will be fixed.
>
> Those 3.1 features that can be backported to 2.x have been, specifically
> to reduce the pain in porting 2.7-based applications to 3.x. Feature-
> wise, 2.7 is designed to ease the transition from the 2.x series to the
> 3.x series. Claiming that it's not advisable to use 2.7 is simply
> nonsense.

Not to forget about the 2to3 tool. If you write code for 2.6 or 2.7 now,
you can actually port it automatically and continuously, and do the final
switch when you think it's time. So both choices (2 or 3) are real and
available.

Stefan

From: Terry Reedy on
On 7/6/2010 11:19 AM, Giampaolo RodolĂ  wrote:
> 2010/7/6 David Cournapeau<cournape(a)gmail.com>:
>>> Or is there no change at the C level? That would make things easy.
>>
>> There are quite a few, but outside of the big pain point of
>> strings/byte/unicode which is present at python level as well, a lot
>> of the issues are not so big (and even simpler to deal with). For
>> example, although numpy took time to port (and is still experimental
>> in nature), it took me a couple of hours to get a basic scipy working
>> (numpy uses a lot of C api dark corners, whereas scipy is much more
>> straightforward in its usage of the C API).

>
> As for this aspect, I made a port as such (C extension) for psutil,
> and it hasn't been too difficult, I must admit.
>
> For those interested here is a detailed explanation of all the steps I
> faced, along with revision changes:
> http://code.google.com/p/psutil/issues/detail?id=75&can=1&q=python%203&colspec=ID%20Summary%20Type%20Opsys%20Status%20Milestone%20Opened%20Owner%20Progress#c9

That post refers to
docs.python.org / dev/3.0/howto/cporting.html
[without added space] but that is currently 404 missing.

--
Terry Jan Reedy