Re: [Python-Dev] generated NEWS files
While it's easy to fix NEWS its not easy to fix changelog entries (only a few svn super-users can do it, and it's a pain). Actually, any committer can do that: svn pe --revprop -rrev svn:log It may be difficult to remember, but it's fairly easy to execute. 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] generated NEWS files
Benjamin Peterson schrieb: I know that doing merges is rather painful because of the Misc/NEWS files. Would it be possible to have the NEWS log generated from commit messages? I was thinking something like this in a message: No, it's not painful ;) The NEWS files doesn't get merged from trunk to 3.0. $ svnmerge.py merge $ svn revert Misc/NEWS resolve conflicts, compile, test $ svn ci -F svn 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] Python 2.6a2 execution times with various compilers
I did some performance comparisons with various compilers and the resulting Python 2.6a2 and pybench. I put the details on http://www.in-nomine.org/2008/04/11/python-26a2-execution-times-with-various-compilers/ Of course, take benchmark results with a grain of salt, but it seems ICC can provide people with an added performance edge when using Python. In short: I measured a speedup between ~21%-29% with ICC compared to GCC. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ I was searching through the Heavens and somehow I slipped... ___ 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] Summary of Tracker Issues
ACTIVITY SUMMARY (04/04/08 - 04/11/08) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1826 open (+45) / 12616 closed (+21) / 14442 total (+66) Open issues with patches: 544 Average duration of open issues: 709 days. Median duration of open issues: 1287 days. Open Issues Breakdown open 1801 (+45) pending25 ( +0) Issues Created Or Reopened (68) ___ setitimer, getitimer wrapper 04/05/08 http://bugs.python.org/issue2240reopened loewis patch Unicode escape sequences not parsed in raw strings. 04/05/08 http://bugs.python.org/issue2541reopened gvanrossum patch Python 2.6a2 on Solaris 10 built with SUN C 04/04/08 CLOSED http://bugs.python.org/issue2551created MrJean1 test_ctypes failed Python 2.6a2 Solaris 10 SUN C 04/04/08 http://bugs.python.org/issue2552created MrJean1 patch test_ioctrl failed Python 2.6a2 Solaris 10 SUN C 04/04/08 CLOSED http://bugs.python.org/issue2553created MrJean1 test_ioctl failed Python 2.6a2 Solaris 10 SUN C 04/04/08 http://bugs.python.org/issue2554created MrJean1 test_parser failed Python 2.6a2 Solaris 10 SUN C 04/04/08 CLOSED http://bugs.python.org/issue2555created MrJean1 changing sys.dont_write_bytecode has not effect 04/05/08 CLOSED http://bugs.python.org/issue2556created benjamin.peterson \u and \U in raw strings have regressed in 3.0a4 04/05/08 CLOSED http://bugs.python.org/issue2557created gvanrossum Document pickle protocol 3 04/05/08 CLOSED http://bugs.python.org/issue2558created georg.brandl patch atom sorting error when buiding ctypes 04/05/08 http://bugs.python.org/issue2559created skip.montanaro removal of stale code from myreadline.c 04/06/08 http://bugs.python.org/issue2560created JosephArmbruster patch Instance remembers old values from former life 04/06/08 CLOSED http://bugs.python.org/issue2561created warnhold Cannot use non-ascii letters in disutils if setuptools is used. 04/06/08 http://bugs.python.org/issue2562reopened loewis patch embed manifest in windows extensions 04/06/08 http://bugs.python.org/issue2563created mhammond patch, patch Python hangs on FreeBSD7 in test_capi04/06/08 CLOSED http://bugs.python.org/issue2564created trepan Change 'type' to 'class' in repr/str(builtin-class) 04/07/08 CLOSED http://bugs.python.org/issue2565created tjreedy easy Py3.0a4 wsgiref simple_server failed to start04/07/08 http://bugs.python.org/issue2566created delimy Section New-style and classic classes needs to be removed/rewr 04/07/08 CLOSED http://bugs.python.org/issue2567created loewis Seconds range in time unit
[Python-Dev] Need help for SWIG's Python 3.0 backend
Hello, I am a Google Summer of Code student who preparing a SWIG's Python 3.0 support proposal. Here's detail of my proposal: http://www.dabeaz.com/cgi-bin/wiki.pl?GSoCPython3Proposal And abstract shown below for convenient: This project adds Python 3.0 support for SWIG. We will add a -3 option to SWIG's current backend, which indicates SWIG to generate wrapper for Python 3. We also make SWIG generate more efficient code and more clear proxy by utilizing Python 3's new features. The considered features are as follows: * Function Annotations * Mutable Buffer Support * Abstract Base Classes I have read PEPs and Python 3's document, then did some experiment on the API. I have modified a SWIG generated wrapper code by hand so it can running with Python 3.0. However, there still some API changes I can't handle. SWIG used some undocumented C API, for example the _PyInstance_Lookup(). And some API disappeared, I can't found the alternative of them, for example PyInstance_NewRaw(). I think I will need a lot of help from Python developers if my proposal is accepted. So I post this here to make sure if I can get help when doing this project. And I really appreciate if you can give any advice about how to solve the problems I mentioned before. Thank you! Best regards, Haoyu Bai 4/12/2008 ___ 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 32- and 64-bit living together
Hi all, My question is simple: is there any problem when installing/using both 32- and 64-bit Python's on the same machine? I'm more concerned about header files (those installed under /usr/include/python-2.x), because as far as I could see there's nothing similar to a #ifdef USE_64BIT or something on them. Thanks, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ 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] Reserving an arg space for Jython
Hi all, I was wondering if it might be possible for Jython to get an arg space for command line execution. We try to deliver the same switches that Python delivers (so for example -c means program passed in as string on Python and Jython). We have some need for arguments that would be Jython-specific, for example we would like to be able to pass arguments to the Java process that starts Jython. I would just make one up, but it would be best if it was future compatible with Python (so -J would be great, but it would be annoying if -J started to mean something in a future Python). So what do guys say? Can we hava -J? I don't think it is being used yet... -Frank ___ 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] Reserving an arg space for Jython
Works for me. We should have a patch to CPython that looks for -J and rejects it with -J is reserved for Jython. On Fri, Apr 11, 2008 at 10:38 AM, Frank Wierzbicki [EMAIL PROTECTED] wrote: Hi all, I was wondering if it might be possible for Jython to get an arg space for command line execution. We try to deliver the same switches that Python delivers (so for example -c means program passed in as string on Python and Jython). We have some need for arguments that would be Jython-specific, for example we would like to be able to pass arguments to the Java process that starts Jython. I would just make one up, but it would be best if it was future compatible with Python (so -J would be great, but it would be annoying if -J started to mean something in a future Python). So what do guys say? Can we hava -J? I don't think it is being used yet... -Frank ___ 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Reserving an arg space for Jython
On Fri, Apr 11, 2008 at 1:40 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Works for me. We should have a patch to CPython that looks for -J and rejects it with -J is reserved for Jython. Great! Knowing this crowd it is probably already implemented -- but if not I'd love to dust off my C skills and upload a patch, I doubt I would cause harm in this area of Python :) -Frank ___ 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 32- and 64-bit living together
On 2008-04-11 19:10, Sérgio Durigan Júnior wrote: Hi all, My question is simple: is there any problem when installing/using both 32- and 64-bit Python's on the same machine? I'm more concerned about header files (those installed under /usr/include/python-2.x), because as far as I could see there's nothing similar to a #ifdef USE_64BIT or something on them. The include files are all static and can be used on both 32-bit and 64-bit platforms or installations. Only the /usr/lib/python2.x files differ between 32-bit and 64-bit (the configuration files are in /usr/lib/python2.x/config). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 11 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] Reserving an arg space for Jython
On Fri, Apr 11, 2008 at 2:51 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 7:40 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Works for me. We should have a patch to CPython that looks for -J and rejects it with -J is reserved for Jython. Do we want it to be Jython-specific, or should it be available to any alternative VM? I don't know if the IronPython folks need anything for .NET, but maybe they would like one? -X was suggested on Jython's irc. I kind of like -J, but -X would work for us too. -Frank ___ 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] Reserving an arg space for Jython
IronPython already uses -X:OptionName for special IronPython only options so +1 for -X. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Wierzbicki Sent: Friday, April 11, 2008 12:14 PM To: Brett Cannon Cc: Guido van Rossum; python-dev@python.org Subject: Re: [Python-Dev] Reserving an arg space for Jython On Fri, Apr 11, 2008 at 2:51 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 7:40 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Works for me. We should have a patch to CPython that looks for -J and rejects it with -J is reserved for Jython. Do we want it to be Jython-specific, or should it be available to any alternative VM? I don't know if the IronPython folks need anything for .NET, but maybe they would like one? -X was suggested on Jython's irc. I kind of like -J, but -X would work for us too. -Frank ___ 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/dinov%40microsoft.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] Reserving an arg space for Jython
Frank Wierzbicki wrote: On Fri, Apr 11, 2008 at 2:51 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 7:40 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Works for me. We should have a patch to CPython that looks for -J and rejects it with -J is reserved for Jython. Do we want it to be Jython-specific, or should it be available to any alternative VM? I don't know if the IronPython folks need anything for .NET, but maybe they would like one? -X was suggested on Jython's irc. I kind of like -J, but -X would work for us too. IronPython has a host of -X:Something command line switches - so reserving -X would be helpful. Michael Foord -Frank ___ 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] Reserving an arg space for Jython
I was also going to suggest a platform independent option. I like -Xwhat-follows-is-impl-dependent. n On Fri, Apr 11, 2008 at 12:39 PM, Dino Viehland [EMAIL PROTECTED] wrote: IronPython already uses -X:OptionName for special IronPython only options so +1 for -X. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Wierzbicki Sent: Friday, April 11, 2008 12:14 PM To: Brett Cannon Cc: Guido van Rossum; python-dev@python.org Subject: Re: [Python-Dev] Reserving an arg space for Jython On Fri, Apr 11, 2008 at 2:51 PM, Brett Cannon [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 7:40 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Works for me. We should have a patch to CPython that looks for -J and rejects it with -J is reserved for Jython. Do we want it to be Jython-specific, or should it be available to any alternative VM? I don't know if the IronPython folks need anything for .NET, but maybe they would like one? -X was suggested on Jython's irc. I kind of like -J, but -X would work for us too. -Frank ___ 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/dinov%40microsoft.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/nnorwitz%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 32- and 64-bit living together
On 2008-04-11 20:21, Sérgio Durigan Júnior wrote: Hi Lemburg, On Fri, 2008-04-11 at 19:38 +0200, M.-A. Lemburg wrote: On 2008-04-11 19:10, Sérgio Durigan Júnior wrote: Hi all, My question is simple: is there any problem when installing/using both 32- and 64-bit Python's on the same machine? I'm more concerned about header files (those installed under /usr/include/python-2.x), because as far as I could see there's nothing similar to a #ifdef USE_64BIT or something on them. The include files are all static and can be used on both 32-bit and 64-bit platforms or installations. Thanks :-). Only the /usr/lib/python2.x files differ between 32-bit and 64-bit (the configuration files are in /usr/lib/python2.x/config). Hmm, right. I tried to modify the installation path (using --libdir in ./configure) to /usr/lib64, but some *.pyo objects still are installed under /usr/lib. AFAIK, these objects are bitness-dependent (i.e., if they were generated by a 32-bit Python, they can only be execute by a 32-bit Python - and vice-versa), right? Right. Is there any way to separate these arch-dependent files in /usr/lib and /usr/lib64 depending on their bitness? There's no need for that. Only the config/ dir which is included in the Python lib dir is dependent on the Python configuration. Thanks, P.S.: I think this misbehaviour of --libdir is a bug. IMHO, it should put every arch-dependent file in the path that the user provided. You should probably have a look at how RedHat or openSUSE solve these problems. Some of them have patched Python to fit their needs. You may have to do that as well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 11 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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 32- and 64-bit living together
On Fri, 2008-04-11 at 22:06 +0200, M.-A. Lemburg wrote: Hmm, right. I tried to modify the installation path (using --libdir in ./configure) to /usr/lib64, but some *.pyo objects still are installed under /usr/lib. AFAIK, these objects are bitness-dependent (i.e., if they were generated by a 32-bit Python, they can only be execute by a 32-bit Python - and vice-versa), right? Right. Is there any way to separate these arch-dependent files in /usr/lib and /usr/lib64 depending on their bitness? There's no need for that. Only the config/ dir which is included in the Python lib dir is dependent on the Python configuration. I'm afraid I still don't understand your point. I mean, if the *.pyo file *is* dependent on the bitness of the Python interpreter (as you confirmed in my first question), therefore when I decide to have both 32- and 64-bit Python on my system I *must* have two versions of every .pyo file: one for 32- and another for 64-bit Python. What I've missed? You should probably have a look at how RedHat or openSUSE solve these problems. Some of them have patched Python to fit their needs. You may have to do that as well. I'll sure take a look at them. Thanks! -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ 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 32- and 64-bit living together
On 2008-04-11 22:25, Sérgio Durigan Júnior wrote: On Fri, 2008-04-11 at 22:06 +0200, M.-A. Lemburg wrote: Hmm, right. I tried to modify the installation path (using --libdir in ./configure) to /usr/lib64, but some *.pyo objects still are installed under /usr/lib. AFAIK, these objects are bitness-dependent (i.e., if they were generated by a 32-bit Python, they can only be execute by a 32-bit Python - and vice-versa), right? Right. Sorry, I misread you question. PYO and PYC files are *not* dependent on 32/64 bit sizes. Is there any way to separate these arch-dependent files in /usr/lib and /usr/lib64 depending on their bitness? There's no need for that. Only the config/ dir which is included in the Python lib dir is dependent on the Python configuration. I'm afraid I still don't understand your point. I mean, if the *.pyo file *is* dependent on the bitness of the Python interpreter (as you confirmed in my first question), therefore when I decide to have both 32- and 64-bit Python on my system I *must* have two versions of every .pyo file: one for 32- and another for 64-bit Python. What I've missed? Sorry for the confusion. You should probably have a look at how RedHat or openSUSE solve these problems. Some of them have patched Python to fit their needs. You may have to do that as well. I'll sure take a look at them. Thanks! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 11 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] generated NEWS files
On Fri, Apr 11, 2008 at 2:23 AM, Martin v. Löwis [EMAIL PROTECTED] wrote: While it's easy to fix NEWS its not easy to fix changelog entries (only a few svn super-users can do it, and it's a pain). Actually, any committer can do that: svn pe --revprop -rrev svn:log Wow, I'm adding that to my list of things I never dreamed Subversion could do! :P I just tried it, and although it works, I get this output: svn: 'post-revprop-change' hook failed; no error output available Significant? It may be difficult to remember, but it's fairly easy to execute. Regards, Martin -- Cheers, Benjamin Peterson ___ 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] generated NEWS files
I just tried it, and although it works, I get this output: svn: 'post-revprop-change' hook failed; no error output available Significant? It's the mailer.py hook failing. I'm not quite sure why it fails, and had no time to look it up. It reads #!/bin/sh REPOS=$1 REV=$2 USER=$3 PROPNAME=$4 /data/repos/projects/hooks/mailer.py propchange $@ The script is the same mailer.py that is also invoked in post-commit. Can anybody see a problem with that? 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] generated NEWS files
On Fri, Apr 11, 2008 at 2:28 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 2:23 AM, Martin v. Löwis [EMAIL PROTECTED] wrote: While it's easy to fix NEWS its not easy to fix changelog entries (only a few svn super-users can do it, and it's a pain). Actually, any committer can do that: svn pe --revprop -rrev svn:log Wow, I'm adding that to my list of things I never dreamed Subversion could do! :P Then you should read http://python.org/dev/faq/ which is essentially a svn FAQ for Python development. -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 32- and 64-bit living together
My question is simple: It's also off-topic for python-dev, which is about the development of Python, not the development with Python. is there any problem when installing/using both 32- and 64-bit Python's on the same machine? I'm more concerned about header files (those installed under /usr/include/python-2.x), because as far as I could see there's nothing similar to a #ifdef USE_64BIT or something on them. You can't install them both into the same prefix (obviously, as they would overwrite their binary files). With two installation, use the header files you got from the 32-bit install for 32-bit extensions/embedding, and the header files you got from the 64-bit install for 64-bit extensions/embedding. The only header file that will actually differ is pyconfig.h. 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 32- and 64-bit living together
Hi Martin, On Fri, 2008-04-11 at 23:58 +0200, Martin v. Löwis wrote: My question is simple: It's also off-topic for python-dev, which is about the development of Python, not the development with Python. With all respect, I think you're confusing things. I'm here trying to find some solutions for Python's build system (which, AFAIK, is about the development *of* Python), which I think is bogus on some systems. I'm just trying to better understand how it works here, and maybe send some patches if I find some solution for my problems. is there any problem when installing/using both 32- and 64-bit Python's on the same machine? I'm more concerned about header files (those installed under /usr/include/python-2.x), because as far as I could see there's nothing similar to a #ifdef USE_64BIT or something on them. You can't install them both into the same prefix (obviously, as they would overwrite their binary files). I was thinking about renaming the binary files, since they're (apparently) the only things that get overwritten *and* are dependent of the bit size (32/64). The rest of the files that would be overwritten, AFAIK, is not dependent of bitness so there's no problem at all. I think this may work (actually, I did the same thing successfuly with Perl). With two installation, use the header files you got from the 32-bit install for 32-bit extensions/embedding, and the header files you got from the 64-bit install for 64-bit extensions/embedding. The only header file that will actually differ is pyconfig.h. If I correctly understand what you're saying, you're proposing installing the header files in different places, right? Since these files are the same (except for pyconfig.h, as you said), I assume that the reason for this separation is only for safety. I'll consider your proposal. Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ 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] strange import encodings error in trunk?
has anyone ever seen this error? this is a pristine --with-pydebug build of
trunk:
msg = 'ABC'
x = msg.decode('utf8')
Traceback (most recent call last):
File stdin, line 1, in module
File /home/gps/python/trunk/Lib/encodings/__init__.py, line 100, in
search_function
level=0)
TypeError: SetupPathsAndImport() got an unexpected keyword argument 'level'
___
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] strange import encodings error in trunk?
On Sat, Apr 12, 2008 at 3:31 AM, Gregory P. Smith [EMAIL PROTECTED] wrote:
has anyone ever seen this error? this is a pristine --with-pydebug build
of trunk:
msg = 'ABC'
x = msg.decode('utf8')
Traceback (most recent call last):
File stdin, line 1, in module
File /home/gps/python/trunk/Lib/encodings/__init__.py, line 100, in
search_function
level=0)
TypeError: SetupPathsAndImport() got an unexpected keyword argument
'level'
Your Google sitecustomize is in the way :) Run python with -E.
--
Thomas Wouters [EMAIL PROTECTED]
Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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] an example of setuptools being used to good effect -- allmydata.org Tahoe
Folks: I'm sorry, but I am not caught up on the current conversation about packaging. I'm very busy with exciting Python development -- http:// allmydata.com and http://allmydata.org . I understand from PJE's message that he thinks I misunderstand some things about PEP 262; this is entirely possible. I intend to catch up on reading the emails of this conversation and to read carefully PJE's messages about PEP 262 in the coming days. Meanwhile, here is the last message that I wrote before I got swamped with the aforementioned excitement: On Apr 9, 2008, at 5:59 PM, Greg Ewing wrote: Paul Moore wrote: I believe that Mac OS X goes for an even simpler structure - applications store *everything* in the one directory, so that install/uninstall is simply a directory copy/remove. Yep, and thereby cuts the whole gordian knot, throws the pieces on the fire and burns them. :-) Package managers have always seemed to me to be an excessively complex solution to a problem that needn't have existed in the first place. Yes! I love the Zen of the Mac OS X packaging approach. The best install is none at all! (Of course, I also love apt.) I keep hoping that someday Linux will support something like MacOSX application bundles and frameworks, but I haven't seen any sign of it yet. We're slowly approaching this level of simplicity in packaging of the *source code* of Allmydata.org Tahoe, using setuptools. http://allmydata.org/source/tahoe/trunk/docs/install.html The list of dependencies which are automatically resolved by setuptools is visible here: [1]. It currently includes zfec, foolscap, simplejson, pycryptopp, nevow, zope.interface, twisted, and pywin32. This automatic resolution of dependencies works while fully preserving the user's ability to use their own packages and their own packaging tools. That is: 1. If any of these dependencies are already installed, such as in a Debian package or if the user has installed them by hand, then installing Tahoe will use the already-installed versions and not install anything new, and 2. For any of these dependencies that are not already installed, installing Tahoe will *not* write these dependencies into your standard system directory (which is potentially a sacred place where only your own packaging tool or your root account is allowed to tread) but will instead write them into a local, newly-created install directory from which you can then run Tahoe. (This part is similar in spirit to the Mac OS packaging technique.) Also, this install process never downloads anything from the Internet at install time, per our policy [2, 3], which also happens to be a policy some other people have, e.g. [4, 5]. This works on all of our supported platforms, which includes Linux, Solaris, Windows, Cygwin, and Mac OS X. Oh yes, we also have our buildbot [6] automatically produce Debian packages for edgy, feisty, etch, and gutsy. As far as I know, all of this is accomplished without breaking any of the use cases traditionally associated with setuptools / easy_install, for example easy_install allmydata-tahoe works, and if you want setup.py install to install into your standard system directory, it will. The reason that I am posting this is to let other programmers know that setuptools is actually a pretty useful tool, even if the use cases that you want to support are incompatible with certain easy_install traditions such as fetching new packages from the internet at buildtime or installing into your system directory. Regards, Zooko P.S. Two days ago I was able to remove twisted from the list of Manual Dependencies that people have to be aware of in order to try out Allmydata Tahoe from the source tarball. I think I can safely remove pyOpenSSL now, but that remains to be properly tested by our buildbot. I will be able to remove Crypto++ soon, due to the pycryptopp [7] library. If I can figure out a hack to work-around one of the major frustrations of setuptools (that you can't simply run ./setup.py install --prefix=$FOO), and if I finish my setuptools plugin to run Twisted trial instead pyunit when ./setup.py test, then I'll be able to remove GNU make from the dependencies. That will leave only g++, Python, and OpenSSL as packages that a programmer has to manually deal with in order to try out Allmydata Tahoe from source. [1] http://allmydata.org/trac/tahoe/browser/_auto_deps.py [2] http://allmydata.org/trac/tahoe/wiki/Packaging [3] http://allmydata.org/trac/tahoe/ticket/229 [4] http://bytes.com/forum/thread666455.html [5] http://fedoraproject.org/wiki/Packaging/Python/Eggs [6] http://allmydata.org/buildbot/waterfall?show_events=false [7] http://allmydata.org/trac/pycryptopp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
Re: [Python-Dev] generated NEWS files
On Fri, Apr 11, 2008 at 2:53 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: I just tried it, and although it works, I get this output: svn: 'post-revprop-change' hook failed; no error output available Significant? It's the mailer.py hook failing. I'm not quite sure why it fails, and had no time to look it up. It reads #!/bin/sh REPOS=$1 REV=$2 USER=$3 PROPNAME=$4 /data/repos/projects/hooks/mailer.py propchange $@ The script is the same mailer.py that is also invoked in post-commit. Can anybody see a problem with that? No, but how many parameters are passed to mailer.py? if cmd == 'commit': if len(sys.argv) 5: usage() if len(sys.argv) 4: config_fname = sys.argv[4] elif cmd == 'propchange': if len(sys.argv) 6 or len(sys.argv) 7: usage() # ... For commit, sys.argv must be = 5, but for propchange sys.argv must == 6, unless my tired eyes are reading that wrong. I don't know if the # of args passed are the same in both cases or not. n ___ 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
