[Numpy-discussion] Porting strategy for py3k

[David Cournapeau]

On Fri, Apr 24, 2009 at 4:49 PM, Dag Sverre Seljebotn
<dagss at student.matnat.uio.no> wrote:
> David Cournapeau wrote:
>> Christopher Barker wrote:
>>> Though I'm a bit surprised that that's not how the print function is
>>> written in the first place (maybe it is in py3k -- I'm testing on 2.5)
>>>
>>
>> That's actually how it works as far as I can tell. The thing with
>> removing those print is that we can do it without too much trouble. As
>> long as we cannot actually test any py3k code, warnings from python 2.6
>> is all we can get.
>>
>> I think we should aim at getting "something" which builds and runs (even
>> if does not go further than import stage), so we can gradually port. For
>> now, porting py3k is this huge thing that nobody can work on for say one
>> hour. I would like to make sure we get at that stage, so that many
>> people can take part of it, instead of the currently quite few people
>> who are deeply intimate with numpy.
>
> One thing somebody *could* work on rather independently for some hours
> is proper PEP 3118 support, as that is available in Python 2.6+ as well
> and could be conditionally used on those systems.

Yes, this could be done independently. I am not familiar with PEP
3118; from the python-dev ML, it looks like the current buffer API has
some serious shortcomings, I don't whether this implies to numpy or
not. Do you have more on this ?

Another relatively independent thing is to be able to bootstrap our
build from py3k. At least, distutils and the code for bootstrapping,
so that we can then run 2to3 on the source code from distutils. Not
being able to bootstrap our build process under py3k from distutils
sounds too much of a pain. The only real alternative I could see is to
have two codebases, because 2to3 does not seem able to convert
numpy.distutils 100 % automatically.

David