Re: [Numpy-discussion] Porting strategy for py3k

2009-05-04 Thread Dag Sverre Seljebotn
David Cournapeau wrote: > On Mon, May 4, 2009 at 1:24 AM, Dag Sverre Seljebotn > wrote: > >> David Cournapeau wrote: >> >>> On Fri, Apr 24, 2009 at 4:49 PM, Dag Sverre Seljebotn >>> One thing somebody *could* work on rather independently for some hours is proper PEP 3118 s

Re: [Numpy-discussion] Porting strategy for py3k

2009-05-03 Thread David Cournapeau
On Mon, May 4, 2009 at 1:24 AM, Dag Sverre Seljebotn wrote: > David Cournapeau wrote: >> On Fri, Apr 24, 2009 at 4:49 PM, Dag Sverre Seljebotn >>> 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 >>>

Re: [Numpy-discussion] Porting strategy for py3k

2009-05-03 Thread Dag Sverre Seljebotn
David Cournapeau wrote: > On Fri, Apr 24, 2009 at 4:49 PM, Dag Sverre Seljebotn >> 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 cou

Re: [Numpy-discussion] Porting strategy for py3k

2009-05-02 Thread David Cournapeau
On Fri, Apr 24, 2009 at 4:49 PM, Dag Sverre Seljebotn 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 w

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-24 Thread Dag Sverre Seljebotn
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

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread David Cournapeau
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 mu

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread David Cournapeau
Robert Kern wrote: > > Doesn't the 2to3 tool do this conversion for you? > I have not seen it handling everything. It does not handle reduce, for example: print reduce(lambda x, y: x+y, [1, 2, 3]) is translated to print(reduce(lambda x, y: x + y, [1, 1, 1])) I guess an alternative to a comp

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread ross smith
On Thu, Apr 23, 2009 at 15:39, Robert Kern wrote: > On Thu, Apr 23, 2009 at 09:52, David Cournapeau > wrote: > > On Thu, Apr 23, 2009 at 11:20 PM, Pauli Virtanen wrote: > >> Thu, 23 Apr 2009 22:38:21 +0900, David Cournapeau kirjoitti: > >> [clip] > >>> I looked more in detail on what would

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread Robert Kern
On Thu, Apr 23, 2009 at 09:52, David Cournapeau wrote: > On Thu, Apr 23, 2009 at 11:20 PM, Pauli Virtanen wrote: >> Thu, 23 Apr 2009 22:38:21 +0900, David Cournapeau kirjoitti: >> [clip] >>>     I looked more in detail on what would be needed to port numpy to >>> py3k. In particular, I was intere

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread Ryan May
On Thu, Apr 23, 2009 at 11:23 AM, Christopher Barker wrote: > Ryan May wrote: > > On Thu, Apr 23, 2009 at 9:52 AM, David Cournapeau > But replacing print is not as easy as reduce. Things like print > > "yoyo", a do not work, for example. > > > > I think the point is that you can just chan

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread Christopher Barker
Ryan May wrote: > On Thu, Apr 23, 2009 at 9:52 AM, David Cournapeau But replacing print is not as easy as reduce. Things like print > "yoyo", a do not work, for example. > > I think the point is that you can just change it to print("yoyo") which > will work in both python 2.x and 3.x. I

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread Ryan May
On Thu, Apr 23, 2009 at 9:52 AM, David Cournapeau wrote: > On Thu, Apr 23, 2009 at 11:20 PM, Pauli Virtanen wrote: > > Thu, 23 Apr 2009 22:38:21 +0900, David Cournapeau kirjoitti: > > [clip] > >> I looked more in detail on what would be needed to port numpy to > >> py3k. In particular, I was

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread David Cournapeau
On Thu, Apr 23, 2009 at 11:21 PM, Bruce Southey wrote: > I agree that a single code base should be used if possible however there > are a lot of C code changes required as well as Python code changes: > http://www.scipy.org/Python3k > http://jarrodmillman.blogspot.com/2009/01/when-will-numpy-and-

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread David Cournapeau
On Thu, Apr 23, 2009 at 11:20 PM, Pauli Virtanen wrote: > Thu, 23 Apr 2009 22:38:21 +0900, David Cournapeau kirjoitti: > [clip] >>     I looked more in detail on what would be needed to port numpy to >> py3k. In particular, I was interested at the possible strategies to keep >> one single codebase

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread Bruce Southey
David Cournapeau wrote: > Hi, > > I looked more in detail on what would be needed to port numpy to > py3k. In particular, I was interested at the possible strategies to > keep one single codebase for both python 2.x and python 3.x. The first > step is to remove all py3k warnings reported by pyt

Re: [Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread Pauli Virtanen
Thu, 23 Apr 2009 22:38:21 +0900, David Cournapeau kirjoitti: [clip] > I looked more in detail on what would be needed to port numpy to > py3k. In particular, I was interested at the possible strategies to keep > one single codebase for both python 2.x and python 3.x. The first step > is to remo

[Numpy-discussion] Porting strategy for py3k

2009-04-23 Thread David Cournapeau
Hi, I looked more in detail on what would be needed to port numpy to py3k. In particular, I was interested at the possible strategies to keep one single codebase for both python 2.x and python 3.x. The first step is to remove all py3k warnings reported by python 2.6. A couple of recurrent prob