Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Could it be a solution to build libffi with gcc, then configure Python with '--with-system--ffi' and compile with the sun compiler, or would this introduce the dependencies on libgcc or whatever again that Ulrich wanted to avoid? It depends on the processor and the code, but chances are high that this would indeed create a dependency on libgcc. 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.
Martin v. Löwis schrieb: I can neither find recvfd in my man pages nor in my header files in /usr/include on Linux (Ubuntu 8.04 i686). I assume recvfd and sendfd aren't syscalls but the proposed names for the functions. Yes (and no). The system call is sendmsg, with a cmsg_type of SCM_RIGHTS. I don't think there is a plan to add library functions with that name. There is at least a patch: http://bugs.python.org/issue1194378 Georg ___ 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.
Brett Cannon wrote: On Mon, May 19, 2008 at 2:03 AM, Ulrich Berning [EMAIL PROTECTED] wrote: Gregory P. Smith wrote: On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning [EMAIL PROTECTED] wrote: As long as the ctypes extension doesn't build on major Un*x platforms (AIX, HP-UX), I don't like to see ctypes dependend modules included into the stdlib. Please keep the stdlib as portable as possible. Nice in theory but ctypes already works on at least the top 3 popular platforms. Lets not hold Python's stdlib back because nobody who uses IBM and HP proprietary stuff has contributed the necessary support. Making nice libraries available for other platforms is a good way to encourage people to either pitch in and add support or consider their platform choices in the future. -gps It's not my platform choice, it's the choice of our customers. I'm not using these platforms just for fun (in fact it isn't fun compared to Linux or Windows). If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using vendor compilers) would be an easy job, I'm sure it would have been done already. Well, ctypes isn't simple. =) If more and more essential packages depend on ctypes, we should make a clear statement, that Python isn't supported any longer on platform/compiler combinations where libffi/ctypes doesn't build. This would give me arguments to drop support of our software on those platforms. You are mixing the stdlib in with the language in terms of what is required for Python to work, which I think is unfair. Just because some part of the stdlib isn't portable to some OS does not mean Python is not supported on that platform. If you can run a pure Python module that does not depend on any C extension, then that platform has the support needed to run Python. Everything else is extra (which is why we have modules in the stdlib only available on specific platforms). -Brett I don't think it is unfair. If the development team decides one day to reimplement essential extensions like math, _socket, select, _ssl, pwd, grp, time, _locale, zlib... based on ctypes because it may be much easier to maintain python modules instead of dealing with complicated C code, Python will become pretty useless. It's like a cool radio without the chance to get any batteries for it, pretty useless. Platform specific modules are documented as such and nobody would expect a _winreg module on AIX or HP-UX. As said before, PyOpenGL is an example of an extension that moved from C code to Python/ctypes, luckily we don't use it, but what if the maintainers of MySQL-Python or cx_Oracle decide to move to ctypes. Having the ctypes extension in the stdlib doesn't imply it runs on any platform where python runs. Extension writers should keep this in mind when they decide to use ctypes. They should document, that their extension depends on ctypes and therefore doesn't run on platforms where ctypes doesn't work. Ulli ___ 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] Proposal: new environment variable PYTHONSTDOUTENCODING
Hi Martin, On Tue, May 20, 2008 at 10:22:37AM +0200, Martin v. Löwis wrote: In particular, setting this environment variable would also disable the detection of whether stdout is a terminal. In this case, it seems to me that existing programs that start python as a non-interactive subprocess, via a mecanism like os.popen2() or the equivalent in other languages, will receive bogus data (the python banner) and/or hang in unexpected ways (the subprocess waiting for more input after the prompt). A bientot, Armin ___ 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] Issue 643841: Including a new-style proxy base class in 2.6/3.0
Fred Drake wrote: Nick Coghlan wrote: So what do people think of including a ProxyBase implementation in 2.6 and 3.0 that explicitly delegates all of the C-level slots to a designated target instance? On May 20, 2008, at 7:55 PM, Greg Ewing wrote: Sounds good to me. Same here. There's an implementation in zope.proxy which might be useful as a starting point: While a proxy class written in C would no doubt be faster than one written in Python, one of the things I'm hoping to achieve is for the stdlib generic proxy to serve as an example for people writing their own new-style proxy classes in addition to being usable as a base class (Adam Olsen suggested ProxyMixin instead of ProxyBase as a possible name). One other issue is where to put it - none of the existing stdlib modules seemed appropriate, so my sample implementation in the tracker issue just invents a new 'typetools' module. 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] Issue 643841: Including a new-style proxy base class in 2.6/3.0
On May 21, 2008, at 5:41 AM, Nick Coghlan wrote: While a proxy class written in C would no doubt be faster than one written in Python, one of the things I'm hoping to achieve is for the stdlib generic proxy to serve as an example for people writing their own new-style proxy classes in addition to being usable as a base class (Adam Olsen suggested ProxyMixin instead of ProxyBase as a possible name). The idea that it would serve as an example seems odd; the reason to make things part of the standard library is because their implementation needs to track the Python core closely. For a proxy, it would be the need to reflect additional slot methods as they're added. A Python implementation may be able to do this just fine, but the performance penalty would make it uninteresting for many large applications. For what it's worth, zope.proxy does support subclassing. -Fred -- Fred Drake fdrake at acm.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] Issue 643841: Including a new-style proxy base class in 2.6/3.0
Fred Drake wrote: On May 21, 2008, at 5:41 AM, Nick Coghlan wrote: While a proxy class written in C would no doubt be faster than one written in Python, one of the things I'm hoping to achieve is for the stdlib generic proxy to serve as an example for people writing their own new-style proxy classes in addition to being usable as a base class (Adam Olsen suggested ProxyMixin instead of ProxyBase as a possible name). The idea that it would serve as an example seems odd; the reason to make things part of the standard library is because their implementation needs to track the Python core closely. For a proxy, it would be the need to reflect additional slot methods as they're added. It does that too - the unit tests I just added to the tracker issue for this proposal will actually start to fail if something is added to the operator module without the unit tests for the proposed ProxyMixin being updated appropriately (it would actually probably be a good thing to have something similar in the weakref.proxy test suite to prevent a repeat of our effort with forgetting to update that when the operator.index slot was added) A Python implementation may be able to do this just fine, but the performance penalty would make it uninteresting for many large applications. It should still be faster than the classic class __getattr__ based proxy implementations it is primarily intended to replace. People that are already using a C-based implementation like zope.proxy aren't going to be affected by the removal of classic classes in 3.0, since they weren't relying on them anyway. In many ways, the TestProxyMixin test suite may prove more useful in the long run than the ProxyMixin class itself, since the test suite provides a template for how to test that a proxy class is doing its job, and also to automatically detect when new C-level operations have been added to the interpreter that the proxy class doesn't support. For what it's worth, zope.proxy does support subclassing. But not in a mixin style - since zope.proxy is an extension class in its own right, it can't be combined with other extension classes. The Python version can be combined with anything. 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.
Ulrich Having the ctypes extension in the stdlib doesn't imply it runs Ulrich on any platform where python runs. Maybe the presence of a functioning ctypes (can|might|should|will) become the operational definition of Python runs on platform X. Skip ___ 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] A smarter shutil.copytree ?
On Tue, Apr 22, 2008 at 7:04 PM, Steven Bethard [EMAIL PROTECTED] wrote: The callable takes the src directory + its content as a list, and returns filter eligible for exclusion FWIW, that looks better to me. That makes me wonder, like Alexander said on the bug tracker: In the glob-style patterns callable, do we want to deal with absolute paths ? I think that it would be okay to document that shutil.ignore_patterns() only accepts patterns matching individual filenames (not complex paths). If someone needs to do something with absolute paths, then they can write their own 'ignore' function, right? Yes, the patch has been changed and corrected by a few people (thanks), and so the doc, http://bugs.python.org/issue2663 So i guess it can be reviewed by a commiter at this stage Regards Tarek Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.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] Addition of pyprocessing module to standard lib.
On Wed, May 21, 2008 at 10:11:05AM -0500, [EMAIL PROTECTED] wrote: Maybe the presence of a functioning ctypes (can|might|should|will) become the operational definition of Python runs on platform X. It is not black-or-white, runs or doesn't. PythonD, e.g., runs on DOS, can use sockets (from WatTCP library), but certainly cannot do multithreading or multitasking. So the wording should be Python supports platform X with the following limitations: ... Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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.
[EMAIL PROTECTED] wrote: Ulrich Having the ctypes extension in the stdlib doesn't imply it runs Ulrich on any platform where python runs. Maybe the presence of a functioning ctypes (can|might|should|will) become the operational definition of Python runs on platform X. And what about platforms like the JVM or CLR? Incidentally there were a small but vocal group of Pythonistas who were (are?) certain that IronPython is not Python because it doesn't have [all of...] the C extensions. Michael Foord Skip ___ 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/fuzzyman%40voidspace.org.uk ___ 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.
James Y Knight wrote: On May 21, 2008, at 11:26 AM, Michael Foord wrote: And what about platforms like the JVM or CLR? Incidentally there were a small but vocal group of Pythonistas who were (are?) certain that IronPython is not Python because it doesn't have [all of...] the C extensions. It seems likely to be easier to port ctypes to Jython/IronPython than it is to port 500 C extensions to Jython. So more software using ctype seems like an improvement for those communities. Yes, both of them have their own FFIs. Seo Sanghyeon started a port of ctypes for IronPython that should be revived by 'someone'. :-) Michael Foord James ___ 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.
On May 21, 2008, at 11:26 AM, Michael Foord wrote: And what about platforms like the JVM or CLR? Incidentally there were a small but vocal group of Pythonistas who were (are?) certain that IronPython is not Python because it doesn't have [all of...] the C extensions. It seems likely to be easier to port ctypes to Jython/IronPython than it is to port 500 C extensions to Jython. So more software using ctype seems like an improvement for those communities. James ___ 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.
Skip Maybe the presence of a functioning ctypes (can|might|should|will) Skip become the operational definition of Python runs on platform X. Michael And what about platforms like the JVM or CLR? Sorry, allow me to rephrase: Maybe the presence of a functioning ctypes (can|might|should|will) become the operational definition of CPython runs on platform X. Michael Incidentally there were a small but vocal group of Pythonistas Michael who were (are?) certain that IronPython is not Python because Michael it doesn't have [all of...] the C extensions. From my perspective IronPython isn't Python because it doesn't run on my platforms (Solaris Mac). ;-) (At least not easily enough for an old codger like me to install.) Skip ___ 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.
Bill Janssen schrieb: What happens on those platforms where ctypes doesn't work? Does the module fail to import, either because it isn't present, or because it can't load the libffi library? Or does it fail silently in some way? It doesn't compile, and Python's setup.py script removes if afterwards IIRC so it cannot be imported. In some cases it compiles, but the ctypes unittests segfault (I have seen this some days ago on HP-UX PA with gcc). The cause for the segfault is either a ctypes bug or a libffi bug. Thomas ___ 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.
A.M. Kuchling schrieb: On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: Myself I would rather spend my energy to make ctypes more portable, within my skills and the platforms I have access to. Someone could run Solaris x86 inside a hosted virtual machine and make it available to the Python developers. Is it possible to find similar hosting for HP-UX and AIX? Or might IBM or HP be willing to donate a low-end machine to the PSF for porting use? I have a vmware appliance installed that runs solaris 10 update 2, gcc and the sun compiler are installed. As expected (?), ctypes works fine when compiled with gcc, but fails to build with the siun compiler. There is also a solaris buildbot running on a sparc machine. Thomas ___ 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.
Ulrich Berning schrieb: If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using vendor compilers) would be an easy job, I'm sure it would have been done already. If more and more essential packages depend on ctypes, we should make a clear statement, that Python isn't supported any longer on platform/compiler combinations where libffi/ctypes doesn't build. This would give me arguments to drop support of our software on those platforms. Ulrich, if *you* have access to these platforms and want to help a good start which hopefully wouldn't take too much time would be to compile the current libffi release [1], run the test suite, and report the results. Compile with gcc, for a start, and note that the testsuite requires dejagnu (the PyObjC folks have written a dejagnu replacement in Python for testing libffi, but I haven't tried that). [1] http://sourceware.org/libffi/ -- Thanks, Thomas ___ 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.
Michael Foord schrieb: James Y Knight wrote: On May 21, 2008, at 11:26 AM, Michael Foord wrote: And what about platforms like the JVM or CLR? Incidentally there were a small but vocal group of Pythonistas who were (are?) certain that IronPython is not Python because it doesn't have [all of...] the C extensions. It seems likely to be easier to port ctypes to Jython/IronPython than it is to port 500 C extensions to Jython. So more software using ctype seems like an improvement for those communities. Yes, both of them have their own FFIs. Seo Sanghyeon started a port of ctypes for IronPython that should be revived by 'someone'. :-) OT: There is also some noise about a ctypes-js implementation for JavaScript; although I do not know how far they are. Thomas ___ 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?
Gah. I just went and visited the Berkeley DB download site as I was preparing my commit message so I could refer to the exact .tar.gz being imported, only to notice that the latest version is now 4.7.25. Jesus, can we use this version? Trent. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Jesus Cea [EMAIL PROTECTED] Sent: 19 May 2008 23:46 To: Python DEV Subject: Re: [Python-Dev] Importing bsddb 4.6.21; with or without AES encryption? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trent Nelson wrote: | 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? Yes, pybsddb3 4.6.4 supports cryptography if the underlying Berkeley DB library is crypto enabled. In principle, you can compile BDB without crypto, and pybsddb3 should work, but you would lose ability to open any DB formerly created using page encryption or page checksum. Export laws aside, we better compile with crypto :). Details: http://www.jcea.es/programacion/pybsddb_doc/dbenv.html#set_encrypt http://www.oracle.com/technology/documentation/berkeley-db/xml/api_c/db_set_flags.html#DB_CHKSUM - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDIDWplgi5GaxT1NAQKaagP+Myn6t364B9cVMUtlKjTIX1LBZkkEG7SX pv+hjUZ68r0Suw8SkhXnBbL2Ek3/yFhvNHH8qAZvEtRGsFGmKiNXccn9Ce3oy0me rAYhuuICleAUJ8RO8FZz+sGK3SR4kITrqnGfMnG46u0rXDQy82NSRW2+uWz/D96d U+X/wfV2HgQ= =io+q -END PGP SIGNATURE- ___ 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/tnelson%40onresolve.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] Addition of pyprocessing module to standard lib.
[EMAIL PROTECTED] wrote: Skip Maybe the presence of a functioning ctypes (can|might|should|will) Skip become the operational definition of Python runs on platform X. Michael And what about platforms like the JVM or CLR? Sorry, allow me to rephrase: Maybe the presence of a functioning ctypes (can|might|should|will) become the operational definition of CPython runs on platform X. Michael Incidentally there were a small but vocal group of Pythonistas Michael who were (are?) certain that IronPython is not Python because Michael it doesn't have [all of...] the C extensions. From my perspective IronPython isn't Python because it doesn't run on my platforms (Solaris Mac). ;-) (At least not easily enough for an old codger like me to install.) IronPython runs very well on the Mac. Installing Mono is pretty much 'one click' these days and it *comes* with IronPython (and has done for a while). I'm writing IronPython in Action on the Mac. Solaris I don't care about... :-) Michael Foord Skip ___ 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trent Nelson wrote: | Gah. I just went and visited the Berkeley DB download site as | I was preparing my commit message so I could refer to the | exact .tar.gz being imported, only to notice that the latest | version is now 4.7.25. Jesus, can we use this version? Err No. It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 or 4.7 support. 4.6 has several known issues, apparently solved in 4.7. I will comment when I have spend some time with 4.7. Any comment, Greg?. In any case, what would be the procedure to update the buildbot infraestructure?. No, DO NOT update Berkeley DB yet!. I keep a private branch in pybsddb for BDB 4.7 support, waiting for Oracle publication. Since they already pushed 4.7.25 out (no pre warning for bindings developers, too bad!), I think I can publish pybsddb 4.7.0 in a couple of days. That done, I will update python version. PS: pybsddb 4.7.0 will support Berkeley DB 4.0 to 4.7. So, the buildbots don't need to be upgraded.. unless we decide that Python 4.6/3.0 will have Berkeley DB 4.7. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ ~ _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSDRmkplgi5GaxT1NAQIGGwP/Rxn2A1TgEfKPU14utLBe2Q9oJlILvusX Fdn69/ZXr4Rk7AiVHrvIkokNxBxnQKMWKykXnZmXAF0Tu75IqbOFuokkE8bu7PG9 yvsPsISbgpFmxrdo1bbJcO4r2ZtsMivw+p5l47GSon9reInl8Dr4cOOG3PayiuSq 9icmszNADCo= =u5Qg -END PGP SIGNATURE- ___ 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.
As said before, PyOpenGL is an example of an extension that moved from C code to Python/ctypes, luckily we don't use it, but what if the maintainers of MySQL-Python or cx_Oracle decide to move to ctypes. Having the ctypes extension in the stdlib doesn't imply it runs on any platform where python runs. Extension writers should keep this in mind when they decide to use ctypes. They should document, that their extension depends on ctypes and therefore doesn't run on platforms where ctypes doesn't work. Plus, even if ctypes works, the code might be incorrect, because they had been assuming structure layouts and symbolic constants that have just a different definition on some other platform, causing the extension module to crash. Writing portable ctypes modules is really hard - significantly harder than writing portable C code (although writing non-portable ctypes code is apparently easier than writing non-portable C code). 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] Importing bsddb 4.6.21; with or without AES encryption?
In any case, what would be the procedure to update the buildbot infraestructure?. You need to import the sources into the Python subversion repository; I understand Trent was about to do that. Then you need to adjust Tools/msi/external.bat to have the slaves export the new version. 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.
Thomas Heller schrieb: A.M. Kuchling schrieb: On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: Myself I would rather spend my energy to make ctypes more portable, within my skills and the platforms I have access to. Someone could run Solaris x86 inside a hosted virtual machine and make it available to the Python developers. Is it possible to find similar hosting for HP-UX and AIX? Or might IBM or HP be willing to donate a low-end machine to the PSF for porting use? I have a vmware appliance installed that runs solaris 10 update 2, gcc and the sun compiler are installed. As expected (?), ctypes works fine when compiled with gcc, but fails to build with the siun compiler. There is also a solaris buildbot running on a sparc machine. I just downloaded the Python 2.5.2 source tar, and tried to build it on a Solaris 11 machine with the SunPro 8 compiler (Sun CC 5.5), and failed: % ./configure [...] creating Modules/Setup creating Modules/Setup.local creating Makefile % make cc -c -DNDEBUG -O -I. -IInclude -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c /usr/include/sys/feature_tests.h, line 353: #error: Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications cc: acomp failed for ./Modules/python.c *** Error code 2 make: Fatal error: Command failed for target `Modules/python.o' % So maybe Python just doesn't run on Solaris with the Sun C compiler. Certainly doesn't build out of the box. Bill ___ 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.
On Wed, 21 May 2008 20:57:33 +0200, \Martin v. Löwis\ [EMAIL PROTECTED] wrote: As said before, PyOpenGL is an example of an extension that moved from C code to Python/ctypes, luckily we don't use it, but what if the maintainers of MySQL-Python or cx_Oracle decide to move to ctypes. Having the ctypes extension in the stdlib doesn't imply it runs on any platform where python runs. Extension writers should keep this in mind when they decide to use ctypes. They should document, that their extension depends on ctypes and therefore doesn't run on platforms where ctypes doesn't work. Plus, even if ctypes works, the code might be incorrect, because they had been assuming structure layouts and symbolic constants that have just a different definition on some other platform, causing the extension module to crash. Writing portable ctypes modules is really hard - significantly harder than writing portable C code (although writing non-portable ctypes code is apparently easier than writing non-portable C code). True. There's some room for improvement in ctypes here, fortunately. For example, PyPy has some tools which resolve the particular problem you're talking about; the library is even available separately and can (and probably should) be used by anyone writing a ctypes module. Sample usage and installation instructions available here: http://codespeak.net/~fijal/configure.html Jean-Paul ___ 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.
On May 21, 2008, at 3:58 PM, Jean-Paul Calderone wrote: Plus, even if ctypes works, the code might be incorrect, because they had been assuming structure layouts and symbolic constants that have just a different definition on some other platform, causing the extension module to crash. Writing portable ctypes modules is really hard - significantly harder than writing portable C code (although writing non-portable ctypes code is apparently easier than writing non-portable C code). True. There's some room for improvement in ctypes here, fortunately. For example, PyPy has some tools which resolve the particular problem you're talking about; the library is even available separately and can (and probably should) be used by anyone writing a ctypes module. Sample usage and installation instructions available here: http://codespeak.net/~fijal/configure.html The csvn subversion bindings use ctypesgen to grovel header files: http://code.google.com/p/ctypesgen/ There's also ctypeslib, which uses gcc-xml to parse the headers instead of a pure python C parser as ctypesgen does: http://svn.python.org/projects/ctypes/trunk/ctypeslib/ I don't really know how all these tools compare to eachother. It sure would be nice if someone could compare them, and figure out if one can be blessed and included with python so that doing the right thing is easy. James ___ 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.
This thread has diverged a bit from the original topic. I suggest going ahead and adding pyprocessing to the library. IMO, its functionality is going to be an essential capability as more and more computers ship with multiple processors. At this point, the basic API for pyprocessing seems well thought-out and somewhat stable. Over time, I expect the implementation will get tweaked in a number of ways including support more platforms as developers figure-out that they like the idea enough to write some platform dependent patches. Putting this functionality in 2.6/3.0 would provide a really nice incentive to update from Py2.5. It would be a sad lost opportunity if this module had to wait another couple years. Raymond ___ 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.
The csvn subversion bindings use ctypesgen to grovel header files: http://code.google.com/p/ctypesgen/ Thanks for the pointer. Looks nice. I've used ctypeslib before, but it takes a bit of infrastructure building (gcc-xml) before it works. Bill ___ 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.
On Wed, May 21, 2008 at 1:53 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: This thread has diverged a bit from the original topic. I suggest going ahead and adding pyprocessing to the library. IMO, its functionality is going to be an essential capability as more and more computers ship with multiple processors. At this point, the basic API for pyprocessing seems well thought-out and somewhat stable. Over time, I expect the implementation will get tweaked in a number of ways including support more platforms as developers figure-out that they like the idea enough to write some platform dependent patches. Putting this functionality in 2.6/3.0 would provide a really nice incentive to update from Py2.5. It would be a sad lost opportunity if this module had to wait another couple years. I feel essentially the same way: it WOULD be sad to waste this excellent opportunity, so I second the suggestion to put pyprocessing in the library right now. Alex ___ 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.
Martin v. Löwis wrote: IIRC, it chokes on the attempt to compile assembler code that has C preprocessor macros in it (can't test it right now). Could the build process be modified to run the C preprocessor over the assembly language first? -- 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] Addition of pyprocessing module to standard lib.
Alex Martelli wrote: On Wed, May 21, 2008 at 1:53 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Putting this functionality in 2.6/3.0 would provide a really nice incentive to update from Py2.5. It would be a sad lost opportunity if this module had to wait another couple years. I feel essentially the same way: it WOULD be sad to waste this excellent opportunity, so I second the suggestion to put pyprocessing in the library right now. Thirded (I think I'm contradicting what I posted earlier in the thread, but I've had more of a chance to think about it and 18 months really is quite a long time to wait for this functionality...) 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] Importing bsddb 4.6.21; with or without AES encryption?
Trent Nelson wrote: | Gah. I just went and visited the Berkeley DB download site as | I was preparing my commit message so I could refer to the | exact .tar.gz being imported, only to notice that the latest | version is now 4.7.25. Jesus, can we use this version? Err No. It is not clear to me that python 2.6/3.0 will be published with BDB 4.6 or 4.7 support. 4.6 has several known issues, apparently solved in 4.7. I could have sworn I heard a few people mention that 4.5 has issues, but they're solved in 4.6 at PyCon ;-) I keep a private branch in pybsddb for BDB 4.7 support, waiting for Oracle publication. Since they already pushed 4.7.25 out (no pre warning for bindings developers, too bad!), I think I can publish pybsddb 4.7.0 in a couple of days. That done, I will update python version. PS: pybsddb 4.7.0 will support Berkeley DB 4.0 to 4.7. So, the buildbots don't need to be upgraded.. unless we decide that Python 4.6/3.0 will have Berkeley DB 4.7. Seems like the amount of work you have to do has doubled now that you've been added as an svn committer, given that you're maintaining multiple branches of code, one for pybsddb, and one for an official Python branch. I was under the impression that pybsddb would be assimilated into trunk/ Lib/bsddb and become the sole pybsddb incarnation. That is, you'd ditch the separate SourceForge pybsddb project and just work directly in the Python tree. I think I remember reading some concerns you had about doing this last week though, surrounding things like wanting to be able to release pybsddb versions more frequently than Python versions are released. Just because you live in trunk/Lib/bsddb shouldn't prevent you from doing this though; in fact, as long as you're sensitive to major release timeframes, I'm sure we'd love trunk to always track the latest Berkeley DB version; if all the buildbots stay green with 4.7 and there are no regressions in functionality, then hey, lets go with 4.7 for 2.6/3.0. It's probably safe to say that you're the one doing the most work with the code base and Berkeley DB in general, which means you'll be in a much better position to advise us as to which version we should be including or ignoring for a given Python release. In general, if we can support the latest release, we will. If Oracle come out with Berkeley DB 4.8 a week after 2.6 is released, that's fine, we'll keep release26-maint chugging along with 4.7, but we can switch trunk over to 4.8 once you're ready. By the time it's ready to cut 2.7, who knows, trunk's bsddb may be supporting Berkeley DB 5.2 at that stage. I would also think that you could cut independent releases (in the sense that they're not linked to any Python release schedule) of 'pybsddb' from the code living in trunk/Lib/bsddb. That way, users of 2.6 could still easy_install (or whatever) the latest pybsddb 4.8.0 to pick up the newest features. 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
