Building Python with icc on 64-bit Linux
I am trying to install Python 2.6.2 on a 64-bit Linux machine (RedHat Enterprise) using the Intel compiler (version 11). Even without optimizations (-O0), I get a compilation error in the ctypes module icc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -O0 -I. -I/home/shr/ khinsen/tm\ p/Python-2.6.2/./Include -Ibuild/temp.linux-x86_64-2.6/libffi/include -Ibuild/t\ emp.linux-x86_64-2.6/libffi -I/home/shr/khinsen/tmp/Python-2.6.2/ Modules/_ctype\ s/libffi/src -I. -IInclude -I./Include -I/usr/local/include -I/home/ shr/khinsen\ /tmp/Python-2.6.2/Include -I/home/shr/khinsen/tmp/Python-2.6.2 -c / home/shr/khi\ nsen/tmp/Python-2.6.2/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/ temp.linu\ x-x86_64-2.6/home/shr/khinsen/tmp/Python-2.6.2/Modules/_ctypes/libffi/ src/x86/f\ fi64.o /home/shr/khinsen/tmp/Python-2.6.2/Modules/_ctypes/libffi/src/x86/ ffi64.c(43): \ error: identifier __int128_t is undefined __int128_t sse[MAX_SSE_REGS]; ^ compilation aborted for /home/shr/khinsen/tmp/Python-2.6.2/Modules/ _ctypes/libf\ fi/src/x86/ffi64.c (code 2) and failed test: test test_cmath failed -- Traceback (most recent call last): File /home/shr/khinsen/tmp/Python-2.6.2/Lib/test/test_cmath.py, line 366, i\ n test_specific_values self.fail(error_message) AssertionError: acos: acos(complex(0.0, 0.0)) Expected: complex(1.5707963267948966, -0.0) Received: complex(1.5707963267948966, 0.0) Received value insufficiently close to expected value. Adding optimization yields even more failed tests. My configuration options are: configure --prefix=$HOME CC=icc CXX=icc OPT=-O0 Did anyone encounter these problems before? Any solutions? Thanks, Konrad. -- http://mail.python.org/mailman/listinfo/python-list
[issue3646] MacOS X framework install to non-standard directory fails
New submission from Konrad Hinsen [EMAIL PROTECTED]: The file Mac/README in Python 2.6b3 says: Installing in another place, for instance $HOME/Library/Frameworks if you have no admin privileges on your machine, has only been tested very lightly. This can be done by configuring with --enable- framework=$HOME/Library/Frameworks. The other two directories, /Applications/MacPython-2.6 and /usr/local/bin, will then also be deposited in $HOME. This is sub-optimal for the unix tools, which you would want in $HOME/bin, but there is no easy way to fix this right now. In reality, the framework is installed in the directory given on the command line, but the installer then wants to write the app to /Applications/MacPython-2.6 and crashes due to lack of write permission: DYLD_FRAMEWORK_PATH=/shared_scratch/Python-2.6b3: ../python.exe ./scripts/Buil\ dApplet.py \ --destroot \ -- python=/shared_scratch/Library/Frameworks/Python.framework/Versions/2\ .6/Resources/Python.app/Contents/MacOS/Python`test -f /shared_scratch/Library/\ Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/M acOS/Py\ thon-32 echo -32` \ --output /Applications/Python 2.6/Build Applet.app \ ./scripts/BuildApplet.py kCGErrorRangeCheck : Window Server communications from outside of session allow\ ed for root and console user only ./scripts/BuildApplet.py:34: DeprecationWarning: catching of string exceptions \ is deprecated except buildtools.BuildError, detail: Traceback (most recent call last): File ./scripts/BuildApplet.py, line 149, in module main() File ./scripts/BuildApplet.py, line 33, in main buildapplet() File ./scripts/BuildApplet.py, line 116, in buildapplet progress=verbose, destroot=destroot) File /Volumes/User data/Scratch/Python-2.6b3/Lib/plat- mac/buildtools.py, li\ ne 115, in process copy_codefragment, raw, others, filename, destroot) File /Volumes/User data/Scratch/Python-2.6b3/Lib/plat- mac/buildtools.py, li\ ne 140, in process_common is_update, raw, others, filename, destroot) File /Volumes/User data/Scratch/Python-2.6b3/Lib/plat- mac/buildtools.py, li\ ne 327, in process_common_macho builder.build() File /Volumes/User data/Scratch/Python-2.6b3/Lib/plat- mac/bundlebuilder.py,\ line 147, in build os.mkdir(builddir) OSError: [Errno 13] Permission denied: '/Applications/Python 2.6' make[1]: *** [install_BuildApplet] Error 1 make: *** [frameworkinstallapps] Error 2 -- components: Build messages: 71728 nosy: khinsen severity: normal status: open title: MacOS X framework install to non-standard directory fails versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3646 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3588] sysconfig variable LINKFORSHARED has wrong value for MacOS X framework build
New submission from Konrad Hinsen [EMAIL PROTECTED]: On a MacOS X framework build, the LINKFORSHARED variable obtained from distutils.sysconfig.get_config_vars() has the value -u _PyMac_Error Python.framework/Versions/2.5/Python The last item is incomplete, it needs to be prefixed with the path in which the Python framework is installed. Looking at config/Makefile (from which Distutils takes the variables), I find LINKFORSHARED= -u _PyMac_Error $(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK) and PYTHONFRAMEWORKDIR= Python.framework One fix would be to use PYTHONFRAMEWORKINSTALLDIR instead of PYTHONFRAMEWORKDIR in the definition of LINKFORSHARED, but I don't know if this could have undesirable effects on the build process. -- components: Distutils messages: 71324 nosy: khinsen severity: normal status: open title: sysconfig variable LINKFORSHARED has wrong value for MacOS X framework build type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3588 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: parallel processing in standard library
Emin.shopper Martinian.shopper wrote: Is there any hope of a parallel processing toolkit being incorporated into the python standard library? I've seen a wide variety of toolkits each with various features and limitations. Unfortunately, each has its own API. For coarse-grained parallelism, I suspect I'd be pretty happy with many of the existing toolkits, but if I'm going to pick one API to learn and program to, I'd rather pick one that I'm confident is going to be supported for a while. I don't think that parallel computing is mature enough to allow the standardization of APIs, except within a given and well specified parallel computing model such as message passing. The Python Wiki has an impressive list of parallel processing options for Python (see http://wiki.python.org/moin/ParallelProcessing). With the exception of the various MPI interfaces, I don't think that any two of them are based on the same parallel computing model. I don't expect this situation to change any time soon, as parallel computing is still very much experimental. Whereas sequential computing has well-tested software engineering techniques, reliable libraries that can be combined into programs, and ever improving testing techniques, none of these exist for parallel computing. For an overview of parallel computing models and for a more detailed description of one of them as implemented in Python, please see my recent article in Computing in Science and Engineering: http://www.computer.org/portal/site/cise/index.jsp? pageID=cise_level1path=cise/2007/n6file=sci.xmlxsl=article.xsl Konrad. -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python in a path that contains a blank
On 21.05.2007, at 21:11, Stargaming wrote: You could give /foo/bar\ baz/ham or /foo/bar baz/ham (either escaping the blanks or wrapping the path in quotation marks) a try. I can't verify it either, just guess from other terminals' behaviour. I tried both already, but neither one works. If I use a backslash, it doesn't end up in the Makefile, and if I use quotes, I get lots of error messages that I don't really want to analyze. Thanks for your reply anyway! Konrad. -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing Python in a path that contains a blank
On 22.05.2007, at 00:34, Greg Donald wrote: On 5/21/07, John Machin [EMAIL PROTECTED] wrote: Is there not a similar trick on MacOS X? It's called a symlink: ln -s /Users/gdonald /foo Right, but since I have no write permissions anywhere except in my home directory (whose path already has the blank), links won't help me. Konrad. -- http://mail.python.org/mailman/listinfo/python-list
Installing Python in a path that contains a blank
I am trying to install Python from sources in my home directory on a Mac cluster (running MacOS X 10.4.8). The path to my home directory contains a blank, and since the installation procedure insists on getting an absolute path for the prefix, I cannot avoid installing to a path whose name contains a blank. Python does not seem to be prepared for this, as it uses only the part before the blank, resulting in numerous error messages. Does anyone know a workaround? Thanks, Konrad. -- http://mail.python.org/mailman/listinfo/python-list
Re: Parallel Python
On Jan 12, 2007, at 11:21, Paul Boddie wrote: done. My own experience with regard to releasing software is that even with an open source licence, most people are likely to ignore your projects than to suddenly jump on board and take control, and even if My experience is exactly the same. And looking into the big world of Open Source programs, the only case I ever heard of in which a project was forked by someone else is the Emacs/XEmacs split. I'd be happy if any of my projects ever reached that level of interest. Related to your work, I've released a parallel execution solution called parallel/pprocess [1] under the LGPL and haven't really heard about anyone really doing anything with it, let alone forking it and That's one more project... It seems that there is significant interest in parallel computing in Python. Perhaps we should start a special interest group? Not so much in order to work on a single project; I believe that at the current state of parallel computing we still need many different approaches to be tried. But an exchange of experience could well be useful for all of us. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: Parallel Python
On Jan 12, 2007, at 15:08, Paul Boddie wrote: It seems to me that a more useful first step would be to create an overview of the different modules and put it on the python.org Wiki: http://wiki.python.org/moin/FrontPage http://wiki.python.org/moin/UsefulModules (a reasonable entry point) If no-one beats me to it, I may write something up over the weekend. That sounds like a good idea. I won't beat you to it, but I'll have a look next week and perhaps add information that I have. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: Parallel Python
On Jan 8, 2007, at 11:33, Duncan Booth wrote: The 'parallel python' site seems very sparse on the details of how it is implemented but it looks like all it is doing is spawning some subprocesses and using some simple ipc to pass details of the calls and results. I can't tell from reading it what it is supposed to add over any of the other systems which do the same. Combined with the closed source 'no redistribution' license I can't really see anyone using it. I'd also like to see more details - even though I'd probably never use any Python module distributed in .pyc form only. From the bit of information there is on the Web site, the distribution strategy looks quite similar to my own master-slave distribution model (based on Pyro) which is part of ScientificPython. There is an example at http://dirac.cnrs-orleans.fr/hg/ScientificPython/main/? f=08361040f00a;file=Examples/master_slave_demo.py and the code itself can be consulted at http://dirac.cnrs-orleans.fr/hg/ScientificPython/main/? f=bce321680116;file=Scientific/DistributedComputing/MasterSlave.py The main difference seems to be that my implementation doesn't start compute jobs itself; it leaves it to the user to start any number he wants by any means that works for his setup, but it allows a lot of flexibility. In particular, it can work with a variable number of slave jobs and even handles disappearing slave jobs gracefully. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: About alternatives to Matlab
On Dec 11, 2006, at 14:21, Jon Harrop wrote: F# runs under Linux with Mono. Well, then it should also run on my Mac... Do you have any experience with performance of numerical code under Mono, or, for that matter, under .NET? I suspect that the JIT compilers were not written with number crunching in mind, but perhaps I am wrong. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: About alternatives to Matlab
On 11.12.2006, at 14:21, Jon Harrop wrote: It's not a matter of number, it's a matter of availability when new processors appear on the market. How much time passes on average between the availability of a new processor type and the availability of a native code compiler for OCaml? OCaml had AMD64 support before many other language. It had a better optimiser before gcc... A concrete example of interest to me: can I get an OCaml-to-native compiler for an IBM BlueGene? The processor is in the PowerPC family, but it has some modifications, and the binary format is different from standard Linux as well. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows installer for Scientific Python for Python 2.4?
On 06.12.2006, at 23:36, Grant Edwards wrote: Can anybody point me to a windows installer for scientific python that will work with Python 2.4? The Scientific python download page only has an installer for Python 2.3. If you find one, please send me a copy so that I can put it on the download page! Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: About alternatives to Matlab
On Dec 5, 2006, at 16:35, Mark Morss wrote: very well-written) _Practical OCaml_. However, I also understand that OCaml supports only double-precision implementation of real numbers; that its implementation of arrays is a little clunky compared to Fortran 95 or Numpy (and I suspect not as fast as Fortran's); and that the available libraries, while powerful, are by no means as comprehensive as those available for Python. For example, I am unaware of the existance of an HDF5 interface for OCaml. OCaml is a popular language with computer scientists in France (not surprisingly, given its origins), and I have regular contacts with the computer science research community, so I have been exposed quite a bit to OCaml, to the point of once considering it for numerical work. Not as a replacement for Python, but as a replacement for C or Fortran, i.e. for the heavy-duty parts of my work. What made me abandon this idea are mainly two points: 1) the lack of polymorphism 2) the difficulty of interfacing to C and Fortran code 3) the limited processor support of the native code compiler The lack of polymorphism, particularly in operators, makes OCaml code a pain to write and read in my opinion. Float arithmetic is already bad enough, with +. etc. everywhere. If I add complex and vector types (which could easily be defined in OCaml), I'd have to come up with two more sets of arithmetic operators that make my code less readable. In addition, I'd either have to keep multiple implementations for many algorithms, or pass in all operators and mathematical functions as arguments. Neither solution is acceptable for me. Interfacing to C and Fortran code is important because that's what most libraries are written in. While it is possible in principle with OCaml, it is (or at least was at the time I looked) a pain to interface typical array-handling code, for lack of a compatible data structure on the OCaml side. Native code compilation is obviously important for speed. While many popular processors are supported by ocamlopt, scientific users are notorious for grabbing whatever fast hardware they can lay their hands on. It seems safe to count on the GNU suite being ported rapidly to any new platform. I don't have as much faith in the OCaml developers, though perhaps just out of ignorance. Konrad. -- http://mail.python.org/mailman/listinfo/python-list
New parallel computing module for Python
The latest development release of ScientificPython (2.7), which is available now at http://sourcesup.cru.fr/projects/scientific-py/ contains a new module for parallel computing using a master-slave model: a master process defines computational tasks, and any number of slave processes execute them. The main advantages of this approach are simplicity and the possibility to run a variable number of slave processes. Slave processes can even be killed during execution; as long as at least one slave process remains, the computation will terminate correctly. Here is a very simple example that illustrates parallel computation using the new module: from Scientific.DistributedComputing.MasterSlave \ import MasterProcess, SlaveProcess from Scientific import N import sys class Master(MasterProcess): def run(self): for i in range(5): # request a computation task of type sqrt task_id = self.requestTask(sqrt, float(i)) for i in range(5): # retrieve the result from a sqrt computation task task_id, tag, result = self.retrieveResult(sqrt) print result class SquareRoot(SlaveProcess): # implement the computation task sqrt def do_sqrt(self, x): return (x, N.sqrt(x)) if len(sys.argv) == 2 and sys.argv[1] == master: master = True elif len(sys.argv) == 2 and sys.argv[1] == slave: master = False else: print Argument must be 'master' or 'slave' raise SystemExit if master: process = Master(demo) else: process = SquareRoot(demo) process.start() The communication between processes is handled by Pyro (pyro.sourceforge.net), which has to be installed as well. Comments are welcome! -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations.html
Re: Compiling Python using the Portland Group compiler
On Jul 12, 2006, at 15:57, Konrad Hinsen wrote: I am trying to install Python 2.4.3 on an AMD Opteron system using the Portland Group's compiler (pgcc). Using CC=pgcc -DNCURSES_ENABLE_STDBOOL_H=0 OPT=-O0 LINKFORSHARED=-Wl,- export-dynamic ./configure --without-cxx I finally managed to obtain an executable that would start and work, but it fails a couple of test cases: ... I ended up debugging the first case of failure, and diagnosed faulty code generation. I sent a bug report to Portland Group, who promised to look at it. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: ScientificPython - LeastSquareFit diverges
On Jul 19, 2006, at 16:53, Harold Fellermann wrote: :-) Anyway, I had the impression that the leastSquaresFit in Scientific Python is an implementation of the Levenberg Marquardt algorithm as it is presented in the Numerical Recipes. True. Accoring to reviews, this algorithm is not famous for its stability (e.g. http://www.stanford.edu/class/cme302/wnnr/nr.html). Better implementations are out there (e.g. http://www.ics.forth.gr/~lourakis/levmar/). Are there any plans to improve the SciPy algorithm? Would it be a welcome contribution to SciPy to work this part out? Yes, definitely. And no, I have no plans to do it myself any time soon. The current implementation has always been sufficient for my needs, and time is scarce... BTW, ScientificPython (http://dirac.cnrs-orleans.fr/ ScientificPython/) is not the same thing as SciPy (http:// www.scipy.org/). Both are scientific libraries for Python, but their focus is different: ScientificPython aims at providing pythonic modules for scientific computing, whereas SciPy's objective is to provide Python interfaces to the large pool of scientific libraries from the Fortran/C/C++ world. Scientific users of Python should probably have both of them installed. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: ScientificPython - LeastSquareFit diverges
On 18.07.2006, at 15:59, Harold Fellermann wrote: def powerlaw((a,b),x) : ... return a*x**b Fitting power laws is a tricky business, you need a pretty good initial guess to get convergence. Note that I could easily fit the above data using gnuplots internal fitting procedure. Any idea what is going wrong here? Is it a known problem? Are there any work arounds or other packages? My suggestion is to fit, at least as a first step, the logarithms of your data points: import Numeric as N def powerlaw_log((a, b), x) : return N.log(a) + b*N.log(x) params1, chisq = leastSquaresFit(powerlaw_log, (10., -3.), [(x, N.log(y)) for x, y, sigma in data]) You can then use those parameters as starting values for fitting your original problem: params2, chisq = leastSquaresFit(powerlaw, params1, data) Doing this for your data yields: params1: [9469.9675999067185, -2.0881423620750521] params2: [1591.4025775162165, -1.0112284948049179] The big difference between the two fits is a further indicator for a stability problem. I would trust the first set more than the second one. As a general rule, the model to be fitted should be a smoothly varying function of the parameters, and the same should be true for the derivatives. The second general rule is never to trust a non-linear fit algorithm blindly. Look at your data first, see if the model can be a good fit, and play with some paramater values to get a feeling for how they influence the fit. Plotting your data set, it is immediately clear that the first point ruins any nice power law behaviour. You might thus prefer to do the fit without the first point, and you will get a much better defined exponent: params1: [31363.301954929859, -2.4047303053979046] params2: [182522.2346197216, -2.9893640209815757] Plotting the models corresponding to these two sets together with the data, you will see that everything coincides well for large x values, meaning that the first two points make all the difference - another pointer towards a lack of stability in the fit. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: Compiling Python using the Portland Group compiler
Nick, I would try to find out if pgcc has any compatibility switches. I saw you turned optimization off but sometimes there is more you can do disable some of the advanced behind the scenes magic. So apply all those switches, run the tests and then try them one by one to find out how many you can enable before test fail again. If you compiled it as 64bit application, try to compile as a regular 32bit and see what happens. Thanks for your suggestions. I already looked for switches that could possibly change the interpretation of the C code, but I found nothing other than the usual ANSI and C9x compatibility switches, which only change the amount of warnings. However, I will take up your suggestion and see if I can compile a 32- bit executable. Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: hinsen ät cnrs-orleans.fr - -- http://mail.python.org/mailman/listinfo/python-list
Compiling Python using the Portland Group compiler
I am trying to install Python 2.4.3 on an AMD Opteron system using the Portland Group's compiler (pgcc). Using CC=pgcc -DNCURSES_ENABLE_STDBOOL_H=0 OPT=-O0 LINKFORSHARED=-Wl,- export-dynamic ./configure --without-cxx I finally managed to obtain an executable that would start and work, but it fails a couple of test cases: 1) test_coercion reports wrong results for operations with complex numbers. For example, 2**(2.+0j) yields (1+0j). 2) test_compare reports some wrong results, such as (2+0j) != (2+0j) However, typing (2+0j) == (2+0j) into the interpreter yields True. Perhaps the bug is in the execution of the test suite. 3) test_compile reports wrong results as well: test test_compile failed -- Traceback (most recent call last): File /work/experiences/biophys/hinsen/install/Python-2.4.3/Lib/ test/test_compile.py, line 164, in test_literals_with_leading_zeroes self.assertEqual(eval(0777j), 777j) AssertionError: 777j != 777j However, eval(0777j) == 777j yields True. 4) test_cpickle crashes with a segmentation fault. Has anyone encountered such failures before? Does anyone have useful suggestions for analyzing them? Konrad. -- - Konrad Hinsen Centre de Biophysique Moléculaire, CNRS Orléans Synchrotron Soleil - Division Expériences Saint Aubin - BP 48 91192 Gif sur Yvette Cedex, France Tel. +33-1 69 35 97 15 E-Mail: hinsen ät cnrs-orleans.fr - -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for thoughts on PyMPI
On Apr 13, 2006, at 17:37, Carl J. Van Arsdall wrote: Hey, anyone use the PyMPI suite: http://sourceforge.net/projects/ pympi/ ?? I am an engineer doing research with MPI and thought I'd do some digging to see if any scripting languages had adopted it yet. I was just looking for general comments and reviews from the community on this project, thanks! There is also PyPAR which is quite similar: http://datamining.anu.edu.au/~ole/pypar/ Both are high-level interfaces to MPI, i.e. they propose an MPI-like message passing interface with the main added value being communication of arbitrary Python objects. There is also a more low-level MPI interface in my ScientificPython library: http://dirac.cnrs-orleans.fr/ScientificPython/ScientificPythonManual/ Scientific_27.html It handles only strings and arrays, but with almost no overhead. Its strong point is its C interface, which makes it possible to write parallelized mixed C-Python code and to integrate parallelized C libraries into Python projects. Finally, if you are looking for parallel programming in Python but not necessarily an MPI-like approach, consider my BSP interface: http://dirac.cnrs-orleans.fr/ScientificPython/BSP_Tutorial.pdf This is what I personally consider the most convenient interface for parallel programming in Python. It is built on the BSP (Bulk Synchronous Processing) model that works at a higher level than message passing: the programmer does not have to worry about synchronization, which is a major source of hard-to-track- down bugs. Konrad. -- - Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: IMPORTANT 2.5 API changes for C Extension Modules
On 05.04.2006, at 08:44, [EMAIL PROTECTED] wrote: Python 2.5 alpha 1 is in the process of being released later today. There are important changes that are in 2.5 to support 64-bit systems. These changes can cause Python to crash if your module is not upgraded to support the changes. Python was changed internally to use 64-bit values on 64-bit machines for indices. If you've got a machine with more than 16 GB of RAM, it would be great if you can test Python with large ( 2GB) strings and other sequences. For more details about the Python 2.5 schedule: http://www.python.org/dev/peps/pep-0356/ For more details about the 64-bit change: http://www.python.org/dev/peps/pep-0353/ How to fix your module: http://www.python.org/dev/peps/pep-0353/#conversion-guidelines Thanks for the information! One question: Is there a safe way to keep extension modules backward- compatible with older Python versions? I am thinking of something like #ifndef PY_SSIZE_T_DEFINED typedef Py_ssize_t int; #endif assuming that Python 2.5 defines PY_SSIZE_T_DEFINED. Konrad. -- --- Konrad Hinsen Laboratoire Leon Brillouin (CEA-CNRS), CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: [EMAIL PROTECTED] --- -- http://mail.python.org/mailman/listinfo/python-list
Re: An Efficient Scalar Class in Python
On 23.03.2006, at 22:48, Ben Finney wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: A Python class was designed to represent physical scalars and to eliminate errors involving implied physical units (e.g., confusing angular degrees and radians). This sounds like a useful abstraction; I'm not sure if there are established ways to do this, but I'd like to see something like this in PyPI. Maybe not established, but there are at least two packages with similar functionality that have been around for a while: ScientificPython (module Scientific.Physics.PhysicalQuantities): http://dirac.cnrs-orleans.fr/ScientificPython/ Unum http://sourceforge.net/projects/unum/ Konrad. -- --- Konrad Hinsen Laboratoire Leon Brillouin (CEA-CNRS), CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: [EMAIL PROTECTED] --- -- http://mail.python.org/mailman/listinfo/python-list
Re: MPI implementations
On Mar 18, 2006, at 5:04, Daniel Nogradi wrote: I plan to use python parallel and -- fortunately or unfortunately -- there are several implementations. At the moment I'm aware of http://datamining.anu.edu.au/~ole/pypar/ http://pympi.sourceforge.net/ http://www.fysik.dtu.dk/~schiotz/comp/PythonAndSwig/pythonMPI.html and wondered if anyone had experience with any of them. Pros, cons? Did anyone try more than one? Add this one: http://dirac.cnrs-orleans.fr/ScientificPython/ScientificPythonManual/ Scientific_27.html and unless you are 100% convinced that MPI is the interface you want to use, also check out this: http://dirac.cnrs-orleans.fr/ScientificPython/BSP_Tutorial.pdf PyPar and pyMPI are both high-level interfaces to MPI, i.e. they propose an MPI-like message passing interface with the main added value being communication of arbitrary Python objects. My own MPI interface in ScientificPython is more low-level, since it handles only strings and arrays. Its strong point is its C interface, which makes it possible to write parallelized mixed C-Python code and to integrate parallelized C libraries into Python projects. My BSP interface (the second link) is what I personally consider the most convenient interface for parallel programming in Python. It is built on the BSP (Bulk Synchronous Processing) model that works at a higher level than message passing: the programmer does not have to worry about synchronization, which is a major source of hard-to-track- down bugs. Konrad. -- - Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: email package 4.0a2
On Mar 5, 2006, at 22:10, Barry Warsaw wrote: I'm happy to announce the release of the email 4.0a2 standalone package. This is the latest version of the email package and will be released with Python 2.5. The major changes between this version and email 3.0 (released with Python 2.4) is: ... Note that the old, email version 3 package names are still supported for backward compatibility, so you won't have to change existing code. New code should use the new names as the old names will go away in Python 2.6. Also note that email.mime.application is /not/ provided as email.MIMEApplication. I am a bit worried by annoucements such as this one, so I would like to profit from this opportunity to plead for more stability in Python development, even though the concrete case (the email module) is not a problem for me. My interpretation of the above paragraph is that it will be impossible to write Python code using the email module (and possibly other evolving modules) that works with both Python 2.4 and Python 2.6. As an author of Python code, I therefore have to choose if I want to force my users to update their Python installation (knowing that this is impossible or at least a major effort for some of them) or if I want to prevent early adopters of new versions from using my code. I don't like either option. From exchanges with users of my code, I conclude that there are significant numbers of users of Python 2.2, 2.3, and 2.4 at the moment, plus a small number of users of 2.0 and 2.1. From a few cases of Python 2.2 users whose situations I know well, I understand that updating is not always an option. For example, there is someone whose 10 PCs are still running SuSE Linux 8.1 (which includes Python 2.2). The PhD student who handles system administration (with minimal expertise) adopts the wise approach of never breaking a running system. In other words, those machines will remain at SuSE 8.1 and Python 2.2 until they will be replaced. This leaves users with the only option of installing a newer Python in their home directories - not exactly a straightforward task for someone who knows little about Python and nothing about system administration. Given the current situation, I expect that when Python 2.6 is released, Python 2.4 will still be in common use. Personally, I would prefer that all compatibility-breaking changes be postponed until Python 3K. I'd rather have worry about compatibility once than continously. Konrad. -- - Konrad Hinsen Laboratoire Léon Brillouin, CEA Saclay, 91191 Gif-sur-Yvette Cedex, France Tel.: +33-1 69 08 79 25 Fax: +33-1 69 08 82 61 E-Mail: [EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
Stefano Masini wrote: There are a few ares where everybody seems to be implementing their own stuff over and over: logging, file handling, ordered dictionaries, data serialization, and maybe a few more. I don't know what's the ultimate problem, but I think there are 3 main reasons: 1) poor communication inside the community (mhm... arguable) 2) lack of a rich standard library (I heard this more than once) 3) python is such an easy language that the I'll do it myself evil side lying hidden inside each one of us comes up a little too often, and prevents from spending more time on research of what's available. I'd like to add one more that I haven't seen mentioned yet: ease of maintenance and distribution. Whenever I decide to use someone else's package for an important project, I need to make sure it is either maintained or looks clean enough that I can maintain it myself. For small packages, that alone is often more effort than writing my own. If I plan to distribute my code to the outside world, I also want to minimize the number of dependencies to make installation simple enough. This would only stop being a concern if a truly automatic package installation system for Python existed for all common platforms - I think we aren't there yet, in spite of many good ideas. And even then, the maintenance issue would be even more critical with code distributed to the outside world. None of these issues is specific to Python, but with Python making new developments that much simpler, they gain in weight relative to the effort of development. It seems to me that this tendency is hurting python, and I wonder if there is something that could be done about it. I once followed a I don't think it hurts Python. However, it is far from an ideal situation, so thinking about alternatives makes sense. I think the best solution would be self-regulation by the community. Whenever someone discovers three date-format modules on the market, he/she could contact the authors and suggest that they sit together and develop a common version that satisfies everyone's needs, perhaps with adaptor code to make the unified module compatible with everyone's individual modules. Konrad. -- http://mail.python.org/mailman/listinfo/python-list
Re: any Python equivalent of Math::Polynomial::Solve?
Carl Banks wrote: If you don't have a great need for speed, you can accomplish this easily with the linear algebra module of Numeric/numarray. Suppose your quintic polynomial's in the form a + b*x + c*x**2 + d*x**3 + e*x**4 + x**5 The roots of it are equal to the eigenvalues of the companion matrix: 0 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 1 -a -b -c -d -e The method zeros() in Scientific.Functions.Polynomial uses exactly that trick for finding the zeros of a general polynomial. If you need to do more with polynomials than just finding the zeros, the Polynomial class is probably better than an on-the-spot solution. Root finding through eigenvalues is not the fastest method, but it's simple and stable, and not terribly bad either. Sorry for not making that comment earlier, I don't have the time to follow this list at the moment (to my great regret), but I was made aware of this thread through PythonURL. Konrad. -- http://mail.python.org/mailman/listinfo/python-list
