Re: [Python-Dev] Make test failed issues for phyton 3.2 on centos5.5
> [1/1] test_zipfiles > test test_zipfiles crashed -- : No module named > test_zipfiles It means that you don't have a module named test_zipfiles. Retry with "test_zipfile" :-) You may open an issue (including details) for your failures. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [GSoC] Developing a benchmark suite (for Python 3.x)
On Fri, Apr 8, 2011 at 11:22 AM, Stefan Behnel wrote: > Jesse Noller, 07.04.2011 22:28: >> >> On Thu, Apr 7, 2011 at 3:54 PM, Anthony Scopatz wrote: >>> >>> Hi Daniel, >>> Thanks for putting this together. I am a huge supporter of benchmarking >>> efforts. My brief comment is below. >>> >>> On Wed, Apr 6, 2011 at 11:52 AM, DasIch wrote: 1. Definition of the benchmark suite. This will entail contacting developers of Python implementations (CPython, PyPy, IronPython and Jython), via discussion on the appropriate mailing lists. This might be achievable as part of this proposal. >>> >>> If you are reaching out to other projects at this stage, I think you >>> should >>> also be in touch with the Cython people (even if its 'implementation' >>> sits on top of CPython). >>> As a scientist/engineer what I care about is how Cython benchmarks to >>> CPython. I believe that they have some ideas on benchmarking and have >>> also explored this space. Their inclusion would be helpful to me >>> thinking >>> this GSoC successful at the end of the day (summer). >>> Thanks for your consideration. >>> Be Well >>> Anthony >> >> Right now, we are talking about building "speed.python.org" to test >> the speed of python interpreters, over time, and alongside one another >> - cython *is not* an interpreter. > > Would you also want to exclude Psyco then? It clearly does not qualify as a > Python interpreter. > Just to clarify - the crucial word here is Python and not the interpreter. I don't care myself if it's an interpreter or a compiler, I do care if it can pass the python test suite (modulo things that are known to be implementation details and agreed upon). How far is Cython from passing the full test suite? Are there known incompatibilities that would be considered wontfix? Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [GSoC] Developing a benchmark suite (for Python 3.x)
Maciej Fijalkowski, 11.04.2011 11:39: On Fri, Apr 8, 2011 at 11:22 AM, Stefan Behnel wrote: Jesse Noller, 07.04.2011 22:28: On Thu, Apr 7, 2011 at 3:54 PM, Anthony Scopatz wrote: Hi Daniel, Thanks for putting this together. I am a huge supporter of benchmarking efforts. My brief comment is below. On Wed, Apr 6, 2011 at 11:52 AM, DasIch wrote: 1. Definition of the benchmark suite. This will entail contacting developers of Python implementations (CPython, PyPy, IronPython and Jython), via discussion on the appropriate mailing lists. This might be achievable as part of this proposal. If you are reaching out to other projects at this stage, I think you should also be in touch with the Cython people (even if its 'implementation' sits on top of CPython). As a scientist/engineer what I care about is how Cython benchmarks to CPython. I believe that they have some ideas on benchmarking and have also explored this space. Their inclusion would be helpful to me thinking this GSoC successful at the end of the day (summer). Thanks for your consideration. Be Well Anthony Right now, we are talking about building "speed.python.org" to test the speed of python interpreters, over time, and alongside one another - cython *is not* an interpreter. Would you also want to exclude Psyco then? It clearly does not qualify as a Python interpreter. Just to clarify - the crucial word here is Python and not the interpreter. Psyco is also not a Python implementation. It doesn't work without CPython, just like Cython. But I doubt that anyone would seriously argue for excluding Psyco from a Python speed comparison. That was my point here. I don't care myself if it's an interpreter or a compiler, I do care if it can pass the python test suite (modulo things that are known to be implementation details and agreed upon). How far is Cython from passing the full test suite? According to our CI server, we currently have 255 failing tests out of 7094 in Python 2.7. https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/cython-devel-tests-pyregr-py27-c/ This is not completely accurate as a) it only includes compiling the test module, and e.g. not the stdlib modules that are being tested, and b) the total number of tests we see depends on how many test modules we can compile in order to import and run the contained tests. It also doesn't mean that we have >200 compatibility problems, the majority of failures tends to be because of just a hand full of bugs. Another measure is that Cython can currently compile some 160 modules out of a bit less than 200 in Django (almost all failures due to one bug about incompatibilities between PyCFunction and Python functions) and an (untested!) 1219 out of 1538 modules in the stdlib. We haven't put that together yet in order to actually test the compiled stdlib modules. That'll come. Are there known incompatibilities that would be considered wontfix? There are known incompatibilities that are considered bugs. There are no "wontfix" bugs when it comes to Python compatibility. But there are obviously developer priorities when it comes to fixing bugs. Cython is a lot more than just a Python compiler (such as a programming language that keeps people from writing C code), so there are also bugs and feature requests apart from Python semantics that we consider more important to fix. It's not like all bugs on CPython's bug tracker would get closed within a day or so. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [GSoC] Developing a benchmark suite (for Python 3.x)
On Mon, Apr 11, 2011 at 12:43 PM, Stefan Behnel wrote: > Maciej Fijalkowski, 11.04.2011 11:39: >> >> On Fri, Apr 8, 2011 at 11:22 AM, Stefan Behnel >> wrote: >>> >>> Jesse Noller, 07.04.2011 22:28: On Thu, Apr 7, 2011 at 3:54 PM, Anthony Scopatz wrote: > > Hi Daniel, > Thanks for putting this together. I am a huge supporter of > benchmarking > efforts. My brief comment is below. > > On Wed, Apr 6, 2011 at 11:52 AM, DasIch wrote: >> >> 1. Definition of the benchmark suite. This will entail contacting >> developers of Python implementations (CPython, PyPy, IronPython and >> Jython), via discussion on the appropriate mailing lists. This might >> be achievable as part of this proposal. >> > > If you are reaching out to other projects at this stage, I think you > should > also be in touch with the Cython people (even if its 'implementation' > sits on top of CPython). > As a scientist/engineer what I care about is how Cython benchmarks to > CPython. I believe that they have some ideas on benchmarking and have > also explored this space. Their inclusion would be helpful to me > thinking > this GSoC successful at the end of the day (summer). > Thanks for your consideration. > Be Well > Anthony Right now, we are talking about building "speed.python.org" to test the speed of python interpreters, over time, and alongside one another - cython *is not* an interpreter. >>> >>> Would you also want to exclude Psyco then? It clearly does not qualify as >>> a >>> Python interpreter. >> >> Just to clarify - the crucial word here is Python and not the >> interpreter. > > Psyco is also not a Python implementation. It doesn't work without CPython, > just like Cython. But I doubt that anyone would seriously argue for > excluding Psyco from a Python speed comparison. That was my point here. > > >> I don't care myself if it's an interpreter or a compiler, >> I do care if it can pass the python test suite (modulo things that are >> known to be implementation details and agreed upon). >> >> How far is Cython from passing the full test suite? > > According to our CI server, we currently have 255 failing tests out of 7094 > in Python 2.7. > > https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/cython-devel-tests-pyregr-py27-c/ > > This is not completely accurate as a) it only includes compiling the test > module, and e.g. not the stdlib modules that are being tested, and b) the > total number of tests we see depends on how many test modules we can compile > in order to import and run the contained tests. It also doesn't mean that we > have >200 compatibility problems, the majority of failures tends to be > because of just a hand full of bugs. > > Another measure is that Cython can currently compile some 160 modules out of > a bit less than 200 in Django (almost all failures due to one bug about > incompatibilities between PyCFunction and Python functions) and an > (untested!) 1219 out of 1538 modules in the stdlib. We haven't put that > together yet in order to actually test the compiled stdlib modules. That'll > come. > > >> Are there known incompatibilities that would be considered wontfix? > > There are known incompatibilities that are considered bugs. There are no > "wontfix" bugs when it comes to Python compatibility. But there are > obviously developer priorities when it comes to fixing bugs. Cython is a lot > more than just a Python compiler (such as a programming language that keeps > people from writing C code), so there are also bugs and feature requests > apart from Python semantics that we consider more important to fix. It's not > like all bugs on CPython's bug tracker would get closed within a day or so. Sure, that was more of a question "do you consider cython compatibility an issue?". I'm sure there are bugs. > > Stefan > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make test failed issues for phyton 3.2 on centos5.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2011 08:00 PM, Stephen Yeng wrote: > 11 skips unexpected on linux2: > test_bz2 test_dbm_gnu test_dbm_ndbm test_gzip test_readline > test_ssl test_tcl test_tk test_ttk_guionly test_ttk_textonly > test_zlib Looks like you are missing a bunch of development headers on the system (at the time Python's 'configure' was run). E.g., on a Debian system, $ sudo apt-get install zlib1g-dev libbz-dev libreadline-dev # etc Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2i7OIACgkQ+gerLs4ltQ7M5gCg2gCd73Z1Iz5d3q21RvqqlmAY EisAoLevZfn1euG20tODfUgDFZUkNDrg =gJIN -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make test failed issues for phyton 3.2 on centos5.5
Hello, Thanks for the reply. This the once of the test I fail, hope you can help so I can fix the rest 4 errors. :) -- Ran 90 tests in 9.191s FAILED (errors=1, skipped=25) test test_zipfile failed -- Traceback (most recent call last): File "/tmp/Python-3.2/Lib/test/test_zipfile.py", line 497, in test_unicode_filenames zipfp.open(name).close() File "/tmp/Python-3.2/Lib/zipfile.py", line 978, in open close_fileobj=not self._filePassed) File "/tmp/Python-3.2/Lib/zipfile.py", line 487, in __init__ self._decompressor = zlib.decompressobj(-15) AttributeError: 'NoneType' object has no attribute 'decompressobj' 1 test failed: test_zipfile On Mon, Apr 11, 2011 at 4:14 PM, Victor Stinner wrote: > > [1/1] test_zipfiles > > test test_zipfiles crashed -- : No module named > > test_zipfiles > > It means that you don't have a module named test_zipfiles. Retry with > "test_zipfile" :-) > > You may open an issue (including details) for your failures. > > Victor > -- If you have any other question about your web portal please contact me. At N-Pinokyo we value our customers and will be more than happy to assist you with any other matter related to our service. Regards, Stephen Yeng ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make test failed issues for phyton 3.2 on centos5.5
Hello, On Mon, 11 Apr 2011 22:43:03 +0800 Stephen Yeng wrote: > Hello, > Thanks for the reply. > This the once of the test I fail, hope you can help so I can fix the rest 4 > errors. :) Please open an issue for each of these failures on http://bugs.python.org Bug reports on the mailing-list typically get lost. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make test failed issues for phyton 3.2 on centos5.5
On Mon, 2011-04-11 at 07:58 -0400, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/10/2011 08:00 PM, Stephen Yeng wrote: > > > 11 skips unexpected on linux2: > > test_bz2 test_dbm_gnu test_dbm_ndbm test_gzip test_readline > > test_ssl test_tcl test_tk test_ttk_guionly test_ttk_textonly > > test_zlib > > Looks like you are missing a bunch of development headers on the system > (at the time Python's 'configure' was run). E.g., on a Debian system, > > $ sudo apt-get install zlib1g-dev libbz-dev libreadline-dev # etc On RHEL 5 (and therefore presumably CentOS), the corresponding command looks something like this: sudo yum install \ readline-devel openssl-devel gmp-devel \ ncurses-devel gdbm-devel zlib-devel expat-devel \ libGL-devel tk tix gcc-c++ libX11-devel glibc-devel \ bzip2 tar findutils pkgconfig tcl-devel tk-devel \ tix-devel bzip2-devel sqlite-devel \ db4-devel \ libffi-devel You'll want to rerun "configure" after installing these dependencies. FWIW neither the devguide nor http://docs.python.org/using/unix.html#building-python seems to have a handy guide to how to install all useful build-time deps on various distros. I added something similar for PyPy here: http://codespeak.net/pypy/dist/pypy/doc/getting-started-python.html#translating-the-pypy-python-interpreter at the PyCon sprint. Hope this is helpful Dave ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pass possibly imcompatible options to distutil's ccompiler
Hi, I'm the maintainer of Pyrit (http://pyrit.googlecode.com) and recently checked in some code that uses the AES-NI intrinsics found in GCC 4.4+. I'm looking for a way how to build the python-extension using distutils in a sane way and could not get an answer from the distutils-people about that. The enable the intrinsics, one must pass '-maes' and '-mpclmul' as commandline-arguments to gcc, e.g. through extra_compile_args. This is not always safe to do as previous versions of GCC do not support these options and cause cc to fail with an error. Such platforms are not uncommon, e.g. XCode 3.2 on MacOS is shipped with gcc 4.2. I fail to see how to determine in advance what compiler distutils will use and what version that compiler has. Therefor I see two options: - Try to build a small pseudo-extension with the flags enabled, watch for exceptions and only enable the extra_compile_args on the real extension if the build succeeds - Override the build_ext-command with another class and override build_extension. Try to build the extension and, if a CompilerError is thrown, remove '-maes' and '-mpclmul' from extra_compile_args. Try again and re-raise possible CompilerErrors now. The first option seems rather bogus so I'm currently going with the second option. After all, this leaves me with the best chance of enabling the AES-NI-code on compatible machines (no false-negatives with some kind of auto-detection) and not having people being unable to compile it at all (false-positives, resulting in final compiler errors). The downside is that visible error messages are printed to stderr from the first call to build_ext.build_extension if AES-NI is actually not supported. Any other ideas on how to solve this in a better way? Best regards Lukas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pass possibly imcompatible options to distutil's ccompiler
On Tue, Apr 12, 2011 at 7:41 AM, Lukas Lueg wrote: > Any other ideas on how to solve this in a better way? Have you tried with distutils2? If it can't help you, it should really be looked into before the packaging API is locked for 3.3. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
