Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
pe, 2010-02-05 kello 11:09 +0900, David Cournapeau kirjoitti: [clip] I think a py3k buildbot would help for this, right ? Another thing is that the py3k changes do not work at all with Visual Studio compilers, but that's mostly cosmetic things (like #warning not being supported and things like that). There's a Py3 buildbot at http://buildbot.scipy.org/builders/Linux_x86_Ubuntu/builds/319/steps/shell_1/logs/stdio It also runs 2.4, 2.5 and 2.6 -- the 3.1 results are at the end. Most C code that works on Py2 works also on Py3. Py3 mainly means not using PyString, but choosing between Unicode + Bytes + UString (=Bytes for Py2 Unicode for Py3). Also, it may be necessary to avoid FILE* pointers in the API (on Py3 those are no longer as easily obtained), and be wary when working with buffers. So once the py3k support is in place, should we deprecate those functions so that people interested in porting to py3k can plan in advance? For Py3 users APIs with FILE* pointers are somewhat awkward since you need to dup and fdopen to get FILE* pointers, and remember to fclose the handles afterward. Getting rid of FILE* pointers and file descriptor would also helps quite a bit on windows. I know that at some point, there were some discussions to make the python C API safe to multiple C runtimes, but I cannot find any recent discussion on that fact. I should just ask on python-dev, I guess. This would be a great relief if we don't have to care about those issues anymore. Python 3 does have some functions for reading/writing data from PyFile objects directly, but these are fairly inadequate, http://docs.python.org/3.1/c-api/file.html so I guess we're stuck with the C runtime in any case. I assume the rewrite will be worked on a separate SVN branch? Also, is there a plan yet on what needs changing to make Numpy's ABI more resistant? There are two issues: - What we currently means by ABI, that is the ABI for a given python version. The main issue is the binary layout of the structures (I think the function ordering is pretty solid now, it is difficult to change it inadvertently). The only way to fix this is to hide the content of those structures, and define the structures in the C code instead (opaque pointer, also known as the pimpl idiom). This means a massive break of the C API, both internally and externally, but that's something that is really needed IMO. - Higher goal: ABI across python versions. This is motivated by PEP 384. It means avoiding calls to API which are not safe. I have no idea whether it is possible, but that's something to keep in mind once we start a major overhaul. Making structures opaque is a bit worrying. As far as I understand, so far the API has been nearly compatible with Numeric. Making the structures opaque is going to break both our and many other people's code. This is a bit worrying... How about a less damaging route: add reserved space to critical points in the structs, and keep appending new members only at the end? The Cython issue will probably be mostly resolved by new Cython releases before the Numpy 2.0 would be out. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
Pauli Virtanen wrote: Making structures opaque is a bit worrying. As far as I understand, so far the API has been nearly compatible with Numeric. I assumed that we would simply give up the Numeric compatibility - does it really matter for a NumPy which is at best out in 2011/2012 ? It is not like NumPy 1.X is going away soon in any case. OTOH, I don't used any code based numeric, so I understand it is easy to say for me :) Also, I would have hoped that some inconsistencies w.r.t. reference counting could be fixed. It is my understanding that those are mostly a consequence of how Numeric used to do things. Making the structures opaque is going to break both our and many other people's code. This is a bit worrying... How about a less damaging route: add reserved space to critical points in the structs, and keep appending new members only at the end? I don't think it would help much. It requires to know where changes are needed, and I don't think it is really possible. The goal would be to keep a compatible ABI throughout the whole 2.x series. Maybe it would be possible to develop some automatic conversion scripts ala 2to3, but for the C code, to make the transition. Anything related to changes from direct access to accessors should be fairly automatic. The Cython issue will probably be mostly resolved by new Cython releases before the Numpy 2.0 would be out. It is already solved - I mentioned earlier that by removing datetime as a dtype (but keeping the metadata structure), and by regenerating the few cython files with Cython 0.12.1, the ABI is kept compatible (at least as far as scipy constitutes a reasonable test). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
Hi, Getting rid of FILE* pointers and file descriptor would also helps quite a bit on windows. I know that at some point, there were some discussions to make the python C API safe to multiple C runtimes, but I cannot find any recent discussion on that fact. I should just ask on python-dev, I guess. This would be a great relief if we don't have to care about those issues anymore. Just to say that when Guido visited Berkeley a while back he was encouraging us strongly to contact the python-dev list for any help we needed to port to Py3k - so I'd imagine you'd get a good reception... See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Audio signal capture and processing
hi, pyaudio is pretty good for recording audio. It is based on portaudio and has binaries available for win/mac - and is included in many linux distros too (so is pygame). You can load, and play audio with pygame. You can use the pygame.sndarray module for converting the pygame.Sound objects into numpy arrays. apt-get install python-pygame import pygame, pygame.sndarray, sys fname = sys.argv[1] pygame.init() sound = pygame.mixer.Sound(fname) an_array = pygame.sndarray.array(sound) Also see the sndarray demo: pygame.examples.sound_array_demos. `python -m pygame.examples.sound_array_demos` Other sndarray using examples can be found on pygame.org with the search function. Also audiolab uses bindings to libsndfile - so you can open a number of formats. However it is pretty new, so isn't packaged by distros(yet), and there are no mac binaries(yet). It's probably the best way to go if you can handle compiling it yourself and the dependency. cheers, ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Audio signal capture and processing
René Dudfield wrote: Also audiolab uses bindings to libsndfile - so you can open a number of formats. However it is pretty new, so isn't packaged by distros(yet), and there are no mac binaries(yet). It's probably the best way to go if you can handle compiling it yourself and the dependency. There are actually Mac binaries, just not for the last version: http://pypi.python.org/pypi/scikits.audiolab/0.10.0 David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] u in [u+1]
I'm having some trouble here. I have a list of numpy arrays. I want to know if an array 'u' is in the list. As an example, u = np.arange(10) : u not in [u+1] --- ValueErrorTraceback (most recent call last) /home/nbecker/raysat/test/ipython console in module() ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() What would be the way to do this? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] u in [u+1]
I'm having some trouble here. I have a list of numpy arrays. I want to know if an array 'u' is in the list. Try: any(numpy.all(u == l) for l in array_list) standard caveats about float comparisons apply; perhaps any(numpy.allclose(u, l) for l in array_list) is more appropriate in certain circumstances. Can of course replace the first 'any' with 'all' or 'sum' to get different kinds of information, but using 'any' is equivalent to the 'in' query that you wanted. Why the 'in' operator below fails is that behind the scenes, 'u not in [u+1]' causes Python to iterate through the list testing each element for equality with u. Except that as the error states, arrays don't support testing for equality because such tests are ambiguous. (cf. many threads about this.) Zach On Feb 5, 2010, at 6:47 AM, Neal Becker wrote: I'm having some trouble here. I have a list of numpy arrays. I want to know if an array 'u' is in the list. As an example, u = np.arange(10) : u not in [u+1] --- ValueErrorTraceback (most recent call last) /home/nbecker/raysat/test/ipython console in module() ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() What would be the way to do this? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] u in [u+1]
On Fri, Feb 5, 2010 at 8:48 AM, Zachary Pincus zachary.pin...@yale.edu wrote: I'm having some trouble here. I have a list of numpy arrays. I want to know if an array 'u' is in the list. Try: any(numpy.all(u == l) for l in array_list) standard caveats about float comparisons apply; perhaps any(numpy.allclose(u, l) for l in array_list) is more appropriate in certain circumstances. Can of course replace the first 'any' with 'all' or 'sum' to get different kinds of information, but using 'any' is equivalent to the 'in' query that you wanted. Why the 'in' operator below fails is that behind the scenes, 'u not in [u+1]' causes Python to iterate through the list testing each element for equality with u. Except that as the error states, arrays don't support testing for equality because such tests are ambiguous. (cf. many threads about this.) Zach On Feb 5, 2010, at 6:47 AM, Neal Becker wrote: I'm having some trouble here. I have a list of numpy arrays. I want to know if an array 'u' is in the list. As an example, u = np.arange(10) : u not in [u+1] --- ValueError Traceback (most recent call last) /home/nbecker/raysat/test/ipython console in module() ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() What would be the way to do this? maybe np.in1d(u, u+1) or np.in1d(u,u+1).all() is what you want help(np.in1d) Help on function in1d in module numpy.lib.arraysetops: in1d(ar1, ar2, assume_unique=False) Test whether each element of a 1D array is also present in a second array. Returns a boolean array the same length as `ar1` that is True where an element of `ar1` is in `ar2` and False otherwise. Josef ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] How long does it take to create an array?
Why is the second method of converting a list of tuples to an array so much faster? x = range(500) x = [(z,) for z in x] # -- e.g. output of a sql database x[:5] [(0,), (1,), (2,), (3,), (4,)] timeit np.array(x).reshape(-1) # -- slow 1000 loops, best of 3: 832 us per loop timeit np.array([z[0] for z in x]) 1 loops, best of 3: 106 us per loop # -- fast Is it a fixed overhead advantage? Doesn't seems so: x = range(5) x = [[z] for z in x] timeit np.array(x).reshape(-1) 10 loops, best of 3: 83 ms per loop timeit np.array([z[0] for z in x]) 100 loops, best of 3: 9.81 ms per loop So it is probably faster to make a 1d array and reshape it: timeit np.array([[1,2], [3,4], [5,6]]) 10 loops, best of 3: 11.8 us per loop timeit np.array([1,2,3,4,5,6]).reshape(-1,2) 10 loops, best of 3: 6.62 us per loop Yep. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Conversion of matlab import containing objects into 3d array
Hi all, I'm trying to import data from a matlab file using scipy.io.loadmat. One of the variables in the file imports as an array of shape (51,) of dtype object, with each element being an array of shape (23,100) of dtype float. How do I convert this array into a single array of dtype float with shape (51,23,100)? objarr.astype(float), which I thought might work (from [1]), gives me the error ValueError: setting an array element with a sequence.. [1] http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2998408 Many thanks for any help, Angus. -- AJC McMorland Post-doctoral research fellow Neurobiology, University of Pittsburgh ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
Hi folks, It sounds like a consensus has been reached to put out a 1.4.1 that is ABI compatible with 1.3.* If that's the case, and particularly if it's going to be a while before 1.4.1 is ready, I suggest that the 1.4.0 release be pulled from current release status on the download sites. We really don't need anyone else getting caught up in this. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How long does it take to create an array?
On Fri, Feb 5, 2010 at 12:26, Keith Goodman kwgood...@gmail.com wrote: Why is the second method of converting a list of tuples to an array so much faster? x = range(500) x = [(z,) for z in x] # -- e.g. output of a sql database x[:5] [(0,), (1,), (2,), (3,), (4,)] timeit np.array(x).reshape(-1) # -- slow 1000 loops, best of 3: 832 us per loop timeit np.array([z[0] for z in x]) 1 loops, best of 3: 106 us per loop # -- fast When array() gets a sequence of sequences, it has to do more work to figure out the appropriate shape. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Fri, Feb 05, 2010 at 12:32:59PM -0800, Christopher Barker wrote: Hi folks, It sounds like a consensus has been reached to put out a 1.4.1 that is ABI compatible with 1.3.* If that's the case, and particularly if it's going to be a while before 1.4.1 is ready, I suggest that the 1.4.0 release be pulled from current release status on the download sites. +1. If the decision is as you say, I agree with you. Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
Hi, If that's the case, and particularly if it's going to be a while before 1.4.1 is ready, I suggest that the 1.4.0 release be pulled from current release status on the download sites. +1. If the decision is as you say, I agree with you. That seems reasonable to me too... Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Conversion of matlab import containing objects into 3d array
HI, I'm trying to import data from a matlab file using scipy.io.loadmat. One of the variables in the file imports as an array of shape (51,) of dtype object, with each element being an array of shape (23,100) of dtype float. How do I convert this array into a single array of dtype float with shape (51,23,100)? objarr.astype(float), which I thought might work (from [1]), gives me the error ValueError: setting an array element with a sequence.. I guess that your array started life as a matlab cell array of shape (51,1). As far as I know you'd have to convert long-hand: np.concatenate(list(a), axis=0).reshape((51,23,100)) sort of thing... Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Fri, Feb 5, 2010 at 12:32 PM, Christopher Barker chris.bar...@noaa.gov wrote: If that's the case, and particularly if it's going to be a while before 1.4.1 is ready, I suggest that the 1.4.0 release be pulled from current release status on the download sites. +1 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] wired error message in scipy.sparse.eigen function: Segmentation fault
This problem keeps bothering me for days. If you need more sample to test it, I got one more. I tested it this morning. And the segmentation fault happened at a specific place. I guess, finally, I have to refer to the original eigenvalue algorithm or Matlab. Thanks. On Fri, Feb 5, 2010 at 1:22 AM, David Cournapeau courn...@gmail.com wrote: On Thu, Jan 28, 2010 at 3:11 PM, David Cournapeau da...@silveregg.co.jp wrote: Jankins wrote: Yes. I am using scipy.sparse.linalg.eigen.arpack. The exact output is: /usr/local/lib/python2.6/dist-packages/scipy/sparse/linalg/eigen/arpack/_arpack.so I need the output of ldd on this file, actually, i.e the output of ldd /usr/local/lib/python2.6/dist-packages/scipy/sparse/linalg/eigen/arpack/_arpack.so. It should output the libraries actually loaded by the OS. In fact, the matrix is from a directed graph with about 18,000 nodes and 41,000 edges. Actually, this matrix is the smallest one I used. Is it available somewhere ? 41000 edges should make the matrix very sparse. I first thought that your problem may be some buggy ATLAS, but the current arpack interface (the one used by sparse.linalg.eigen) is also quite buggy in my experience, though I could not reproduce it. Having a matrix which consistently reproduce the bug would be very useful. Ok, I took a look at it, and unfortunately, it is indeed most likely an ATLAS problem. I get crashes when scipy is linked against Atlas (v3.8.3), but if I link against plain BLAS/LAPACK, I don't get any crash anymore (and valgrind does not complain). I will try with a recent development from atlas, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Feb 4, 2010, at 1:51 PM, Gael Varoquaux wrote: I'd like to say that I am +1 with everything that has been said against breakage. This isn't the question at hand anymore. The only question at hand is what to label the no ABI breaking release. I actually feel pretty strongly that the version should be 1.3.9 and we should just admit that 1.4 series broke the ABI. We didn't mean for it to happen, but it did. Then, people can stay with 1.3.9 if they want and those that are comfortable with ABI breakage can use 1.4.1 and beyond. My timetable is: * We release 1.3.9 within days * We release 1.4.1 within a few weeks that keeps the datetime ABI change and adds additional pent-up ABI changes. Bringing in the Py3K transition discussion at this point is not necessary, but I think the 1.5 release in May provides improvements to the Py3K layer and sets up people who want to work on it over the summer. I have not heard any good arguments, yet, against calling the the ABI compatible release 1.3.9And what Chris said is important to repeat: I have never supported nor endorsed breaking the ABI at every possible chance. In fact, my behavior has been the opposite. As far as I am aware (and I'm sure Robert will point out any hole in my awareness), the history of NumPy has been zero ABI breakage since 1.0 (that is over 3 years ago). I do hear the majority saying we need an ABI-compatible release and I agree that it should happen ASAP. What to call it is less clear, so I want to be very clear that I feel pretty strongly that it should be called 1.3.9. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Installed NumPy and MatPlotLib in the Wrong Order. How uninstall MPL?
See Subject. I'm working in IDLE in Win7. It seems to me MPL gets stuck in site-packages under C:\Python25. Maybe this is as simple as deleting the entry? Well, yes there's a MPL folder under site-packages and an info MPL file of 540 bytes. There are also pylab.py, pyc,and py0 files under site. What to do next? -- My life in two words. Interrupted Projects. -- WTW (quote originator) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Fri, Feb 5, 2010 at 10:25 PM, Travis Oliphant oliph...@enthought.com wrote: On Feb 5, 2010, at 2:32 PM, Christopher Barker wrote: Hi folks, It sounds like a consensus has been reached to put out a 1.4.1 that is ABI compatible with 1.3.* This is not true. Consensus has not been reached. How many have registered opposition to the above proposal? I think 1.3.9 should be released and 1.4.1 should be ABI incompatible. And then another planned break in numpy ABI compatibility in the foreseeable future, for the other items that have been discussed in this thread? I am still inclined to agree with David and Chuck in this instance. Regards, Darren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Installed NumPy and MatPlotLib in the Wrong Order. How uninstall MPL?
On Fri, Feb 5, 2010 at 10:37 PM, Wayne Watson sierra_mtnv...@sbcglobal.net wrote: See Subject. I'm working in IDLE in Win7. It seems to me MPL gets stuck in site-packages under C:\Python25. Maybe this is as simple as deleting the entry? What does it mean that MPL gets stuck? what kind of stuck? (My experience is only windowsXP not Win7) Often I just delete all directories and files for a package. However, if the package has been installed with an installer and not with easy_install or setup.py, there might be a removexxx, (removematplotlib) under/in the Python25 directory (I have Removematplotlib.exe for python24 but not for 25) and it might also be in the windows registry, try Add/Remove Programs or whatever the Win7 equivalent is. I just checked my Add/Remove Programs and I have several entries under python 2.5 that are orphans because I deleted the directories but didn't uninstall through an uninstaller, but again I see an entry for matplotlib only for python 2.4, so maybe matplotlib doesn't pollute the windows registry anymore. If you don't find any matplotlib uninstall (as in my case for Py2.5), you can just delete all files and directories in site-packages. Josef Well, yes there's a MPL folder under site-packages and an info MPL file of 540 bytes. There are also pylab.py, pyc,and py0 files under site. What to do next? -- My life in two words. Interrupted Projects. -- WTW (quote originator) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Removing datetime support for 1.4.x series ?
On Feb 5, 2010, at 9:59 PM, Darren Dale wrote: On Fri, Feb 5, 2010 at 10:25 PM, Travis Oliphant oliph...@enthought.com wrote: On Feb 5, 2010, at 2:32 PM, Christopher Barker wrote: Hi folks, It sounds like a consensus has been reached to put out a 1.4.1 that is ABI compatible with 1.3.* This is not true. Consensus has not been reached. How many have registered opposition to the above proposal? Even one opposing view is not a consensus. I think 1.3.9 should be released and 1.4.1 should be ABI incompatible. And then another planned break in numpy ABI compatibility in the foreseeable future, for the other items that have been discussed in this thread? Not, not at all. I don't see a need for any ABI incompatibility in the foreseeable future. Especially, if we insert a few place holders like Pauli proposed.I'm proposing to get the ABI breakage over and done with right now.This gives plenty of people time to adjust before the Py3K conversion. I don't see a reason to have another ABI discussion in May while we are also trying to have a Py3K discussion. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Conversion of matlab import containing objects into 3d array
On Feb 5, 2010, at 2:12 PM, Angus McMorland wrote: Hi all, I'm trying to import data from a matlab file using scipy.io.loadmat. One of the variables in the file imports as an array of shape (51,) of dtype object, with each element being an array of shape (23,100) of dtype float. How do I convert this array into a single array of dtype float with shape (51,23,100)? objarr.astype(float), which I thought might work (from [1]), gives me the error ValueError: setting an array element with a sequence.. [1] http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2998408 Something like this (assuming your array is named 'a') np.array(list(a), dtype=float) -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Porting numpy to python 3.x, status update
Hi all, This says that planning for migration to python 3 has begun. http://blog.jarrodmillman.com/2009/11/numpy-14-coming-soon.html It has been a month since 1.4 was released. Is there a status page somewhere where one can checkup on progress for the same? Is Python 3.x support planned for 1.5? This year, next year? Regards, -- Rohit Garg http://rpg-314.blogspot.com/ Senior Undergraduate Department of Physics Indian Institute of Technology Bombay ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Porting numpy to python 3.x, status update
On Feb 6, 2010, at 1:08 AM, Rohit Garg wrote: Hi all, This says that planning for migration to python 3 has begun. More than planning. Actually Pauli (and Chuck I believe) have made quite a bit of progress. Pauli just posted his roadmap of what needs to be finished. It is difficult to predict when the work needed will be done. I think Pauli expects to have something close to finished by the end of the summer this year. Probably version 1.5 or 1.6 (depending on the out-come of some of the current discussion) sometime before the end of this year or early next is my guess for Python 3k support. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
