Re: [Numpy-discussion] Python 3 porting
Hi, The test suite passes now on Pythons 2.4 - 3.1. Further testing is very welcome -- also on Python 2.x. Please check that your favourite software still builds and works with SVN trunk Numpy. Currently, Scipy has some known failures because of (i) removed new= keyword in numpy.histogram (ii) Cython supports only native size/alignment PEP 3118 buffers, and Numpy arrays are most naturally expressed in the standardized sizes. Supporting the full struct module alignment stuff appears to be a slight PITA. I'll try to take a look at how to address this. But everything else seems to work on Python 2.6. *** Python version 2.4.6 (#2, Jan 21 2010, 23:27:36) [GCC 4.4.1] Ran 2509 tests in 18.892s OK (KNOWNFAIL=4, SKIP=2) Python version 2.5.4 (r254:67916, Jan 20 2010, 21:44:03) [GCC 4.4.1] Ran 2512 tests in 18.531s OK (KNOWNFAIL=4) Python version 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] Ran 2519 tests in 19.367s OK (KNOWNFAIL=4) Python version 3.1.1+ (r311:74480, Nov 2 2009, 14:49:22) [GCC 4.4.1] Ran 2518 tests in 23.239s OK (KNOWNFAIL=5) Cheers, Pauli
AWESOME :) On Sun, Feb 21, 2010 at 1:43 PM, Pauli Virtanen <pav@iki.fi> wrote:
Hi,
The test suite passes now on Pythons 2.4 - 3.1. Further testing is very welcome -- also on Python 2.x. Please check that your favourite software still builds and works with SVN trunk Numpy.
Currently, Scipy has some known failures because of
(i) removed new= keyword in numpy.histogram (ii) Cython supports only native size/alignment PEP 3118 buffers, and Numpy arrays are most naturally expressed in the standardized sizes. Supporting the full struct module alignment stuff appears to be a slight PITA. I'll try to take a look at how to address this.
But everything else seems to work on Python 2.6.
***
Python version 2.4.6 (#2, Jan 21 2010, 23:27:36) [GCC 4.4.1] Ran 2509 tests in 18.892s OK (KNOWNFAIL=4, SKIP=2)
Python version 2.5.4 (r254:67916, Jan 20 2010, 21:44:03) [GCC 4.4.1] Ran 2512 tests in 18.531s OK (KNOWNFAIL=4)
Python version 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] Ran 2519 tests in 19.367s OK (KNOWNFAIL=4)
Python version 3.1.1+ (r311:74480, Nov 2 2009, 14:49:22) [GCC 4.4.1] Ran 2518 tests in 23.239s OK (KNOWNFAIL=5)
Cheers, Pauli
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
The test suite passes now on Pythons 2.4 - 3.1. Further testing is very welcome -- also on Python 2.x. Please check that your favourite software still builds and works with SVN trunk Numpy.
Currently, Scipy has some known failures because of
(i) removed new= keyword in numpy.histogram (ii) Cython supports only native size/alignment PEP 3118 buffers, and Numpy arrays are most naturally expressed in the standardized sizes. Supporting the full struct module alignment stuff appears to be a slight PITA. I'll try Hmm. How much would it help if Cython dealt with standardized sizes when
Pauli Virtanen wrote: possible? Is Cython the only reason to have NumPy export native size/alignment? Also, wouldn't it be a pain to export align=True dtypes in standard size/alignment? (As a quick hack in SciPy, there's always np.ndarray[int, cast=True] to skip the format string checking (size is still checked).) Dag Sverre
su, 2010-02-21 kello 20:45 +0100, Dag Sverre Seljebotn kirjoitti:
Pauli Virtanen wrote: [clip]
Currently, Scipy has some known failures because of
(i) removed new= keyword in numpy.histogram (ii) Cython supports only native size/alignment PEP 3118 buffers, and Numpy arrays are most naturally expressed in the standardized sizes. Supporting the full struct module alignment stuff appears to be a slight PITA. I'll try
Hmm. How much would it help if Cython dealt with standardized sizes when possible? Is Cython the only reason to have NumPy export native size/alignment?
Possibly. Anyway, I managed to implement this so that the format string is in the native+aligned '@' form when possible, and falls back to the unaligned alternatives when not. Now the question is: should it prefer the standard unaligned types ('=') or the native types ('^')? For non-native byte orders of course there is only the standard alternative. This also means that long doubles or 64-bit long longs in non-native byte order cannot be exported. Btw, do you know if the '@' format should include the padding xxx or not? And if not, does the implicit padding also pad the end of the structure to even alignment? Or is alignment <= itemsize always?
Also, wouldn't it be a pain to export align=True dtypes in standard size/alignment?
Not really, as the padding needed for alignment is computed at the time the dtype is constructed, so the necessary info is readily available. It's actually exporting '@' dtypes properly that's painful, since this requires thinking about what information must be omitted, and checking when it is possible to do. Notes to self: - I think I possibly forgot the possible padding at the end of the dtype in the provider. - '@' format strings should probably not include padding that is included in the alignment. I assumed this in the consumer interface, but forgot about it in the provider. Roundtrips probably work all right, though, since explicit padding causes zero implicit padding. Pauli
Hi, Do you plan to make some noise about that when numpy2.0 will be release? IMHO you should. Do you for instance plan to have a clear announcement on the scipy web site? Xavier
Hi,
The test suite passes now on Pythons 2.4 - 3.1. Further testing is very welcome -- also on Python 2.x. Please check that your favourite software still builds and works with SVN trunk Numpy.
Currently, Scipy has some known failures because of
(i) removed new= keyword in numpy.histogram (ii) Cython supports only native size/alignment PEP 3118 buffers, and Numpy arrays are most naturally expressed in the standardized sizes. Supporting the full struct module alignment stuff appears to be a slight PITA. I'll try to take a look at how to address this.
But everything else seems to work on Python 2.6.
***
Python version 2.4.6 (#2, Jan 21 2010, 23:27:36) [GCC 4.4.1] Ran 2509 tests in 18.892s OK (KNOWNFAIL=4, SKIP=2)
Python version 2.5.4 (r254:67916, Jan 20 2010, 21:44:03) [GCC 4.4.1] Ran 2512 tests in 18.531s OK (KNOWNFAIL=4)
Python version 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] Ran 2519 tests in 19.367s OK (KNOWNFAIL=4)
Python version 3.1.1+ (r311:74480, Nov 2 2009, 14:49:22) [GCC 4.4.1] Ran 2518 tests in 23.239s OK (KNOWNFAIL=5)
Cheers, Pauli
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
participants (4)
-
Dag Sverre Seljebotn -
Pauli Virtanen -
René Dudfield -
Xavier Gnata