Re: [Python-Dev] Addition of pyprocessing module to standard lib.
-1 on multicore - multiprocess or multiprocessing are a fine names. cores are irrelevant. Thanks you for saying that. I'm constantly amazed how people think multi-core systems are a new thing, conceptually, when they are really just a different packaging for multi-processor systems (perhaps with NUMA consequences that the operating system, but not application, needs to deal with). So -1 on multicore from me as well, despise marketing (typo intentional :-) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Gregory P. Smith wrote: -1 on multicore - multiprocess or multiprocessing are a fine names. cores are irrelevant. systems have multiple cpus real or virtual regardless of how many dies, sockets and cores there are. +0.5 on inclusion. that means i am happy if it does but don't think it needs to make it into 2.6/3.0. leave inclusion for 2.7/3.1. its easy for people to install from an external source for now if they want it. This is a nice summary of my opinion as well. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Gregory P. Smith schrieb: +0.5 on inclusion. that means i am happy if it does but don't think it needs to make it into 2.6/3.0. leave inclusion for 2.7/3.1. its easy for people to install from an external source for now if they want it. I'm still -0.5 on inclusion *NOW*, but +1 on inclusion in 2.7/3.1. IMHO pyprocessing isn't mature enough - the author has labeled it as 'beta' - and the proposal came too late. It's going to take a while to give the package a security audit and integrate the C code into Python. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] rename of ConfigParser module?
Trying to build pywin32 from the trunk, I see: from distutils.config import PyPIRCCommand File C:\src\python-svn\lib\distutils\config.py, line 8, in module from ConfigParser import ConfigParser ImportError: No module named ConfigParser Digging a little deeper, I see: |r63242 | alexandre.vassalotti | 2008-05-15 08:07:07 +1000 (Thu, 15 May 2008) | 2 lines | |Renamed the ConfigParser module to 'configparser'. Is there something I've missed? Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rename of ConfigParser module?
On Thu, May 15, 2008 at 7:37 AM, Mark Hammond [EMAIL PROTECTED] wrote: Trying to build pywin32 from the trunk, I see: from distutils.config import PyPIRCCommand File C:\src\python-svn\lib\distutils\config.py, line 8, in module from ConfigParser import ConfigParser ImportError: No module named ConfigParser Digging a little deeper, I see: |r63242 | alexandre.vassalotti | 2008-05-15 08:07:07 +1000 (Thu, 15 May 2008) | 2 lines | |Renamed the ConfigParser module to 'configparser'. Is there something I've missed? http://www.python.org/dev/peps/pep-3108? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rename of ConfigParser module?
Mark Hammond wrote: Trying to build pywin32 from the trunk, I see: from distutils.config import PyPIRCCommand File C:\src\python-svn\lib\distutils\config.py, line 8, in module from ConfigParser import ConfigParser ImportError: No module named ConfigParser Digging a little deeper, I see: |r63242 | alexandre.vassalotti | 2008-05-15 08:07:07 +1000 (Thu, 15 May 2008) | 2 lines | |Renamed the ConfigParser module to 'configparser'. Is there something I've missed? My money would be on the warning from the build process that Modules/Setup.dist is newer than Modules/Setup :) To keep NTFS and any other case insensitive filesystems from choking on module renames which only differ by case, the old names have been moved to the lib-old directory. You need the newer Setup file to get that directory to appear in sys.path. (Hmm, is changing Modules/Setup enough to sort the Windows build out as well? Or does that need a separate change to some of the Visual Studio files?) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python parallel benchmark
All the discussion recently about pyprocessing got me interested in actually benchmarking Python's multiprocessing performance to see if reality matched my expectations around what would scale up and what would not. I knew Python threads wouldn't be good for compute bound problems, but I was curious to see how well they worked for i/o bound problems. The short answer is that for i/o bound problems, python threads worked just as well as using multiple operating system processes. I wrote two simple benchmarks, one compute bound and the other i/o bound. The compute bound one did a parallel matrix multiply and the i/ o bound one read random records from a remote MySQL database. I ran each benchmark via python's thread module and via MPI (using mpi4py and openmpi and Send()/Recv() for communication). Each test was run multiple times and the numbers were consistent between test runs. I ran the tests on a dual-core Macbook Pro running OS X 10.5 and the included python 2.5.1. 1) Python threads a) compute bound: 1 thread - 16 seconds 2 threads - 21 seconds b) i/o bound: 1 thread -- 13 seconds 4 threads -- 10 seconds 8 threads -- 5 seconds 12 threads - 4 seconds 2) MPI a) compute bound: 1 thread - 17 seconds 2 threads -- 11 seconds b) i/o bound 1 thread -- 13 seconds 4 threads -- 10 seconds 8 threads -- 6 seconds 12 threads -- 4 seconds ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rename of ConfigParser module?
(Hmm, is changing Modules/Setup enough to sort the Windows build out as well? Or does that need a separate change to some of the Visual Studio files?) The latter. Whenever you add, remove, or rename an extension module, you need to adjust the PCbuild files as well. (technically, you also have to adjust PC/os2emx/Makefile, PC/os2vacpp/makefile.omk, and PC/VC6, but these changes are waived). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python parallel benchmark
Tom Pinckney wrote: All the discussion recently about pyprocessing got me interested in actually benchmarking Python's multiprocessing performance to see if reality matched my expectations around what would scale up and what would not. I knew Python threads wouldn't be good for compute bound problems, but I was curious to see how well they worked for i/o bound problems. The short answer is that for i/o bound problems, python threads worked just as well as using multiple operating system processes. Interesting - given that your example compute bound problem happened to be a matrix multiply, I'd be curious what the results are when using python threads with numpy to do the same thing (my understanding is that numpy will usually release the GIL while doing serious number-crunching) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils configparser rename
A.M. Kuchling wrote: Python 2.6 renames the ConfigParser module to be configparser. Distutils imports ConfigParser in various places. I just made a commit updating the import in one places, and then noticed that part of commit r63248, which made the same change, was reverted in order to preserve backward-compatibility. Instead, the default path will include lib-old again to keep the old module name available. Well, lib-old got added back to the path to support external users (since the deprecated ConfigParser name will emit a warning only under the -3 Py3k warning flag). Since it would be nice for the standard library to not emit any warnings with the -3 flag, perhaps distutils should at least be trying the new name first, and only falling back to the old name on an ImportError (assuming we do decide we want to be able to run the 2.6 distutils on older versions of Python). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python parallel benchmark
Do you have the code posted someplace for this? I'd like to add it into the tests I am running On May 15, 2008, at 11:56 AM, Tom Pinckney [EMAIL PROTECTED] wrote: All the discussion recently about pyprocessing got me interested in actually benchmarking Python's multiprocessing performance to see if reality matched my expectations around what would scale up and what would not. I knew Python threads wouldn't be good for compute bound problems, but I was curious to see how well they worked for i/o bound problems. The short answer is that for i/o bound problems, python threads worked just as well as using multiple operating system processes. I wrote two simple benchmarks, one compute bound and the other i/o bound. The compute bound one did a parallel matrix multiply and the i/o bound one read random records from a remote MySQL database. I ran each benchmark via python's thread module and via MPI (using mpi4py and openmpi and Send()/Recv() for communication). Each test was run multiple times and the numbers were consistent between test runs. I ran the tests on a dual-core Macbook Pro running OS X 10.5 and the included python 2.5.1. 1) Python threads a) compute bound: 1 thread - 16 seconds 2 threads - 21 seconds b) i/o bound: 1 thread -- 13 seconds 4 threads -- 10 seconds 8 threads -- 5 seconds 12 threads - 4 seconds 2) MPI a) compute bound: 1 thread - 17 seconds 2 threads -- 11 seconds b) i/o bound 1 thread -- 13 seconds 4 threads -- 10 seconds 8 threads -- 6 seconds 12 threads -- 4 seconds ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python parallel benchmark
Jesse Noller wrote: Do you have the code posted someplace for this? I'd like to add it into the tests I am running It would also be interesting to see how pyprocessing performs. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python parallel benchmark
On May 15, 2008, at 6:54 PM, Eric Smith eric+python- [EMAIL PROTECTED] wrote: Jesse Noller wrote: Do you have the code posted someplace for this? I'd like to add it into the tests I am running It would also be interesting to see how pyprocessing performs. Eric. I'm working on exactly that - I have some I/O work - mandlebrot crunching, prime crunching and othe tests to run with threads, pyprocessing, parallel python (as soon as I figure out why it's hitting open file handle issues) and single threaded -Jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils configparser rename
On Thu, May 15, 2008 at 1:33 PM, A.M. Kuchling [EMAIL PROTECTED] wrote: Python 2.6 renames the ConfigParser module to be configparser. Distutils imports ConfigParser in various places. I just made a commit updating the import in one places, and then noticed that part of commit r63248, which made the same change, was reverted in order to preserve backward-compatibility. Instead, the default path will include lib-old again to keep the old module name available. I suggest dropping that goal, though. We've preserved compatibility but I'm not aware that anyone uses the Python 2.x Distutils with earlier versions of Python. In particular: * There's no standalone distutils package on PyPI, nor can I find such a package with a general web search. Am I missing it? * I do not see users advising other users to use a later version of Distutils to fix their problems. Is anyone actually benefiting from the effort of maintaining backward compatibility? The change was reverted at MAL's request, but he didn't qualify it beyond wanting the backwards-compatibility. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] platform module testing
Benjamin Peterson schrieb: At the moment, the test for the platform module merely calls each function. I realize that this is a hard module to test well, but are there some assumptions we can make? For example, if sys.platform is 'java', can it be assumed that java_ver is going to return something which is not empty. When sys.platform is 'darwin' and the gestalt module is present, is it reasonable to require that a empty tuple not be returned? A student has created a patch during the GHOP contest which adds some features and tests for Linux. AFAIK the patch hasn't been applied yet. See http://bugs.python.org/issue1322 Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rename of ConfigParser module?
Martin v. Löwis schrieb: (Hmm, is changing Modules/Setup enough to sort the Windows build out as well? Or does that need a separate change to some of the Visual Studio files?) The latter. Whenever you add, remove, or rename an extension module, you need to adjust the PCbuild files as well. (technically, you also have to adjust PC/os2emx/Makefile, PC/os2vacpp/makefile.omk, and PC/VC6, but these changes are waived). Don't forget PC/config.c and the build files for VC 6, VS 7.1 and VS 8.0 in the PC/ directory. :] Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rename of ConfigParser module?
Martin v. Löwis schrieb: Don't forget PC/config.c and the build files for VC 6, VS 7.1 and VS 8.0 in the PC/ directory. :] Aren't the 7.1 and 8.0 files generated? Only the 8.0 files are generated from the 9.0 files. The 6.0 and 7.1 files still require manual work. It might be possible to create the 7.1 files from the 9.0 as well. But nobody has written a tool so far. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rename of ConfigParser module?
Don't forget PC/config.c and the build files for VC 6, VS 7.1 and VS 8.0 in the PC/ directory. :] Aren't the 7.1 and 8.0 files generated? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rename of ConfigParser module?
(Hmm, is changing Modules/Setup enough to sort the Windows build out as well? Or does that need a separate change to some of the Visual Studio files?) The latter. Whenever you add, remove, or rename an extension module, you need to adjust the PCbuild files as well. (technically, you also have to adjust PC/os2emx/Makefile, PC/os2vacpp/makefile.omk, and PC/VC6, but these changes are waived). Correct me if I'm wrong, but in this case we are talking about adding a new directory to sys.path, correct? On Windows, this means a change in PCBuild/pyconfig.h and tools/msi/msi.py. A patch seems simple, so I'll check one in (assuming noone beats me) after clarification of a couple of points. * I assume lib-old should go at the end of the sys.path managed by the above files? * What is the story with plat-win? pyconfig.h includes a 'Lib\plat-win' directory, and although this directory does not exist, it usually ends up on sys.path. msi.py does *not* include this entry, which means it doesn't end up on sys.path in certain embedding environments (specifically, when the hosting application is using a python.dll located outside the Python directory). I'm sure there are pros and cons for including that directory, but I can't see justification for it to sometimes be used and sometimes not. So should I change msi.py to include this directory, or change pyconfig.h to not include it? Thanks, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Visual Studio 2008 compiler option EHsc ?
In building a package with several platforms, I ran across the warning message below from Visual Studio 2008. Should we add the /EHsc option to the compile_options in distutils for MSVC? Or is it more complex than that... This link describes the warning: http://tinyurl.com/4fmjue http://msdn.microsoft.com/en-us/library/2axwkyt4.aspx This link describes a patch: http://tinyurl.com/63bqo2 http://projects.scipy.org/pipermail/numpy-discussion/2007-January/025527.html === Warning message: C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(2092) : warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(2083) : while compiling class template member function 'void std::basic_string_Elem,_Traits,_Ax::_Copy(unsigned int,unsigned int)' with [ _Elem=char, _Traits=std::char_traitschar, _Ax=std::allocatorchar ] C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE\xstring(2221) : see reference to class template instantiation 'std::basic_string_Elem,_Traits,_Ax' being compiled with [ _Elem=char, _Traits=std::char_traitschar, _Ax=std::allocatorchar ] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rename of ConfigParser module?
On Thu, May 15, 2008 at 4:35 PM, Mark Hammond [EMAIL PROTECTED] wrote: (Hmm, is changing Modules/Setup enough to sort the Windows build out as well? Or does that need a separate change to some of the Visual Studio files?) The latter. Whenever you add, remove, or rename an extension module, you need to adjust the PCbuild files as well. (technically, you also have to adjust PC/os2emx/Makefile, PC/os2vacpp/makefile.omk, and PC/VC6, but these changes are waived). Correct me if I'm wrong, but in this case we are talking about adding a new directory to sys.path, correct? On Windows, this means a change in PCBuild/pyconfig.h and tools/msi/msi.py. A patch seems simple, so I'll check one in (assuming noone beats me) after clarification of a couple of points. * I assume lib-old should go at the end of the sys.path managed by the above files? Yes. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python parallel benchmark
I switched to using numpy for the matrix multiply and while the overall time to do the matrix multiply is much faster, there is still no speed up from using more than one python thread. If I look at top while running 2 or more threads, both cores are being used 100% and there is no idle time on the system. I did a quick google search and didn't find anything conclusive about numpy releasing the GIL. The most conclusive and recent reference I found was http://mail.python.org/pipermail/python-list/2007-October/463148.html I found some other references where people were expressing concern over numpy releasing the GIL due to the fact that other C extensions could call numpy and unexpectedly have the GIL released on them (or something like that). On May 15, 2008, at 6:43 PM, Nick Coghlan wrote: Tom Pinckney wrote: All the discussion recently about pyprocessing got me interested in actually benchmarking Python's multiprocessing performance to see if reality matched my expectations around what would scale up and what would not. I knew Python threads wouldn't be good for compute bound problems, but I was curious to see how well they worked for i/ o bound problems. The short answer is that for i/o bound problems, python threads worked just as well as using multiple operating system processes. Interesting - given that your example compute bound problem happened to be a matrix multiply, I'd be curious what the results are when using python threads with numpy to do the same thing (my understanding is that numpy will usually release the GIL while doing serious number-crunching) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 extras
Christian, you get this week's Awesome Award. Hah, 'Weekly Awesome Award', we should make that one of our things, like QOTW. Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Importing bsddb 4.6.21; with or without AES encryption?
I was about to commit an initial import of the bsddb 4.6.21 source to the 'external' area in the repo, which I obtained from the following URL: http://www.oracle.com/technology/software/products/berkeley-db/index.html I downloaded the source that includes AES encryption, for no reason other than it was first on the list. I'm now wondering if we should only be importing the 'NC' source that doesn't contain any encryption? Jesus, does pybsddb use any of the Berkeley DB encryption facilities? Would anything break if we built the bsddb module without encryption? (Note that all of this only applies to Windows.) Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils configparser rename
On Thu, May 15, 2008 at 6:49 PM, Nick Coghlan [EMAIL PROTECTED] wrote: Since it would be nice for the standard library to not emit any warnings with the -3 flag, perhaps distutils should at least be trying the new name first, and only falling back to the old name on an ImportError (assuming we do decide we want to be able to run the 2.6 distutils on older versions of Python). Well, that is a good idea. And, that will silence the Windows buildbots while other developers find out how to add lib-old/ to the sys.path. -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python parallel benchmark
Tom Pinckney wrote: If I look at top while running 2 or more threads, both cores are being used 100% and there is no idle time on the system. If you run it with just one thread, does it use up only one core's worth of CPU? If so, this suggests that the GIL is being released. If it wasn't, two threads would still only use one core's worth. Also, if you have only two cores, using more than two threads isn't going to gain you anything whatever happens. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Importing bsddb 4.6.21; with or without AES encryption?
In the past I believe we've built it with encryption. Regardless, we already ship encryption with Python thanks to the ssl module and I'm assuming the PSF has taken care of the necessary silly export document filing for the US so I see no reason to exclude it from bsddb. On Wed, May 14, 2008 at 8:08 AM, Trent Nelson [EMAIL PROTECTED] wrote: I was about to commit an initial import of the bsddb 4.6.21 source to the 'external' area in the repo, which I obtained from the following URL: http://www.oracle.com/technology/software/products/berkeley-db/index.html I downloaded the source that includes AES encryption, for no reason other than it was first on the list. I'm now wondering if we should only be importing the 'NC' source that doesn't contain any encryption? Jesus, does pybsddb use any of the Berkeley DB encryption facilities? Would anything break if we built the bsddb module without encryption? (Note that all of this only applies to Windows.) Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils configparser rename
On Thu, May 15, 2008 at 4:04 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 1:33 PM, A.M. Kuchling [EMAIL PROTECTED] wrote: Python 2.6 renames the ConfigParser module to be configparser. Distutils imports ConfigParser in various places. I just made a commit updating the import in one places, and then noticed that part of commit r63248, which made the same change, was reverted in order to preserve backward-compatibility. Instead, the default path will include lib-old again to keep the old module name available. I suggest dropping that goal, though. We've preserved compatibility but I'm not aware that anyone uses the Python 2.x Distutils with earlier versions of Python. In particular: * There's no standalone distutils package on PyPI, nor can I find such a package with a general web search. Am I missing it? * I do not see users advising other users to use a later version of Distutils to fix their problems. Is anyone actually benefiting from the effort of maintaining backward compatibility? The change was reverted at MAL's request, but he didn't qualify it beyond wanting the backwards-compatibility. -Brett backwards compatibility? whats wrong with just doing: try: import configparser as ConfigParser except ImportError: import ConfigParser in the distutils code that needs to be. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python parallel benchmark
Interestingly, I think there's something magic going on with numpy.dot() on my mac. If I just run a program without threading--that is just a numpy matrix multiply such as: import numpy a = numpy.empty((4000,4000)) b = numpy.empty((4000,4000)) c = numpy.dot(a,b) then I see both cores fully maxed out on my mac. On a dual-core linux machine I see only one core maxed out by this program and it runs VASTLY slower on the linux box. It turns out that numpy on Mac's uses Apple's Accelerate.framekwork BLAS and LAPACK which in turn is multi-threaded as of OS X 10.4.8. On May 15, 2008, at 10:55 PM, Greg Ewing wrote: Tom Pinckney wrote: If I look at top while running 2 or more threads, both cores are being used 100% and there is no idle time on the system. If you run it with just one thread, does it use up only one core's worth of CPU? If so, this suggests that the GIL is being released. If it wasn't, two threads would still only use one core's worth. Also, if you have only two cores, using more than two threads isn't going to gain you anything whatever happens. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/thomaspinckney3%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils configparser rename
On Thu, May 15, 2008 at 9:08 PM, Gregory P. Smith [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 4:04 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 1:33 PM, A.M. Kuchling [EMAIL PROTECTED] wrote: Python 2.6 renames the ConfigParser module to be configparser. Distutils imports ConfigParser in various places. I just made a commit updating the import in one places, and then noticed that part of commit r63248, which made the same change, was reverted in order to preserve backward-compatibility. Instead, the default path will include lib-old again to keep the old module name available. I suggest dropping that goal, though. We've preserved compatibility but I'm not aware that anyone uses the Python 2.x Distutils with earlier versions of Python. In particular: * There's no standalone distutils package on PyPI, nor can I find such a package with a general web search. Am I missing it? * I do not see users advising other users to use a later version of Distutils to fix their problems. Is anyone actually benefiting from the effort of maintaining backward compatibility? The change was reverted at MAL's request, but he didn't qualify it beyond wanting the backwards-compatibility. -Brett backwards compatibility? whats wrong with just doing: try: import configparser as ConfigParser except ImportError: import ConfigParser in the distutils code that needs to be. Nothing's wrong with it. It's just that Alexandre did what we have done for all of the stdlib and just moved entirely over to the new name. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visual Studio 2008 compiler option EHsc ?
In building a package with several platforms, I ran across the warning message below from Visual Studio 2008. Should we add the /EHsc option to the compile_options in distutils for MSVC? Or is it more complex than that... Who is we? If you have a module that uses C++ exceptions, you should certainly enable compiler support for exceptions, for that module. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Help with finishing PEP 3108
I need help to finish implementing PEP 3108. While over 80 modules are now deprecated in Python 2.6 (of which I did over 50 of), there are still over 20 tasks left to do in relation to the PEP. My free time is being sucked away since I have a conference paper deadline of June 1. And I am moving May 31. And I have to fly down to California to help my mother move on June 4. And other personal stuff (see a certain trend in my life at the moment?). So if you have time to help, please see issue 2775 (http://bugs.python.org/issue2775) and the dependencies list. The issues range from doing patch reviews of work people have already done, renaming a module, creating a new package, removing some use from the stdlib, or even backporting some changes made to 3.0 that were never merged into 2.6. In other words a wide variety of things. =) The PEP outlines the steps necessary to deprecate a module for deletion or for a rename in a step-by-step manner so you don't need to worry about forgetting a step. If you can't choose what to do, the issues that will lead to a module be deleted are the highest priority as renames can be handled by 2to3 in a later version while module deletions are harder to get pushed through and accepted. The modules left to still remove are still there because they are still used somehow in the stdlib. The module renames are mostly done at this point, but the new packages have not been handled yet. Obviously I don't want the beta to be held up by this, nor do I want to see any of the work left out because I couldn't get to it all. So any and all help is appreciated. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
