Re: [Python-Dev] No releases tonight
-On [20080301 19:57], Christian Heimes ([EMAIL PROTECTED]) wrote: >I also propose translations of the shorter text to important languages >like French, German, Japanese, Portuguese and Spanish. I'm willing to >help with the German translation. I can probably get a translation done in Japanese, Chinese and Korean. For Portuguese I guess we could ask the ASync guys in Brazil, they're huge Python users with their work for Canonical/Ubuntu. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ There can be no justice so long as laws are absolute... ___ 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] C-API status of Python 3?
Alex Martelli wrote: > Yep, but please do keep the PyUnicode for str and PyString for bytes > (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the > task of porting existing extensions... the bytearray functions should > no doubt be PyBytearray, though. Yeah, we've already planed to keep PyUnicode as prefix for str type functions. It makes perfectly sense, not only from the historical point of view. But for PyString I planed to rename the prefix to PyBytes. In my opinion we are going to regret it, when we keep too many legacy names from 2.x. In order to make the migration process easier I can add a header file that provides PyString_* functions as aliases for PyBytes_* Comments? 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] C-API status of Python 3?
On 2008-03-02 14:47, Christian Heimes wrote: > Alex Martelli wrote: >> Yep, but please do keep the PyUnicode for str and PyString for bytes >> (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the >> task of porting existing extensions... the bytearray functions should >> no doubt be PyBytearray, though. > > Yeah, we've already planed to keep PyUnicode as prefix for str type > functions. It makes perfectly sense, not only from the historical point > of view. > > But for PyString I planed to rename the prefix to PyBytes. In my opinion > we are going to regret it, when we keep too many legacy names from 2.x. > In order to make the migration process easier I can add a header file > that provides PyString_* functions as aliases for PyBytes_* > > Comments? +1 Why not also make unicode() the default type constructor and only keep str() as alias to simplify porting (perhaps with a warning) ? The term "string" is just too overloaded with all kinds of misinterpretations. The term "string" just refers to a string of bytes - a variable length array so to speak. However, depending on the application space, "string" is used as synonym for "text string" just as well as "data string". Removing the term "string" altogether would make it easier for people to understand that Py3k only has unicode (for text data) and bytes (for binary data). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 02 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] C-API status of Python 3?
On 3/2/08, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Alex Martelli wrote: > > Yep, but please do keep the PyUnicode for str and PyString for bytes > > (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the > > task of porting existing extensions... the bytearray functions should > > no doubt be PyBytearray, though. > > > Yeah, we've already planed to keep PyUnicode as prefix for str type > functions. It makes perfectly sense, not only from the historical point > of view. > > But for PyString I planed to rename the prefix to PyBytes. In my opinion > we are going to regret it, when we keep too many legacy names from 2.x. > In order to make the migration process easier I can add a header file > that provides PyString_* functions as aliases for PyBytes_* +1 on only doing this via a header that must be explicitly included by modules wanting the compatibility names. ___ 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] C-API status of Python 3?
On Sun, Mar 2, 2008 at 10:39 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > > On 3/2/08, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Alex Martelli wrote: > > > Yep, but please do keep the PyUnicode for str and PyString for bytes > > > (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the > > > task of porting existing extensions... the bytearray functions should > > > no doubt be PyBytearray, though. > > > > Yeah, we've already planed to keep PyUnicode as prefix for str type > > functions. It makes perfectly sense, not only from the historical point > > of view. > > > > But for PyString I planed to rename the prefix to PyBytes. In my opinion > > we are going to regret it, when we keep too many legacy names from 2.x. > > In order to make the migration process easier I can add a header file > > that provides PyString_* functions as aliases for PyBytes_* > > +1 on only doing this via a header that must be explicitly included by > modules wanting the compatibility names. OK, as long as it's also supplied (and presumably empty) for 2.6 -- my key concern is faciitating the maintenance of a single codebase for C-coded Python extensions that can be compiled for both 2.6 and 3.0. (I'm also thinking of SWIG and similar utilities, but those can probably best be tweaked to emit rather different C code for the two cases; still, that C code will also include some C snippets hand-coded by the extension author/maintainer, e.g. via SWIG typemaps &c, so easing the "single codebase" approach may help there too). I don't think we want to go the route of code translators/generators for C-coded Python extensions (the way we do for Python code via 2to3), and the fewer #if's and #define's C extension authors/maintainers are required to devise (in order to support both 2.6 and 3.0), the likelier it is that we'll see 3.0 support in popular C-coded Python extensions sooner rather than later. 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] C-API status of Python 3?
> Why not also make unicode() the default type constructor and only > keep str() as alias to simplify porting (perhaps with a warning) ? > > The term "string" is just too overloaded with all kinds of > misinterpretations. The term "string" just refers to a string of > bytes - a variable length array so to speak. However, depending > on the application space, "string" is used as synonym for > "text string" just as well as "data string". > > Removing the term "string" altogether would make it easier for > people to understand that Py3k only has unicode (for text data) > and bytes (for binary data). I agree that "string" is very overloaded, but calling it "unicode" is sort of like calling integers "int32" -- that is, you're talking about the implementation rather than the type. In most programming languages that aren't at the machine level (like C is), "string" really is a sequence of text characters, not a "string of bytes", and that's probably the term that should be used for Python going forward, despite the legacy issues it involves. Personally, I feel that "string" (for text) and "bytes" (for binary data represented as a sequence of bytes) are appropriate terms for Python. Keep "unicode" for a release or two as an alias for "string". But isn't all this in a PEP somewhere already? 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] C-API status of Python 3?
On Sunday 02 March 2008, Alex Martelli wrote: > On Sun, Mar 2, 2008 at 10:39 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > > On 3/2/08, Christian Heimes <[EMAIL PROTECTED]> wrote: > > > Alex Martelli wrote: > > > > Yep, but please do keep the PyUnicode for str and PyString for bytes > > > > (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the > > > > task of porting existing extensions... the bytearray functions should > > > > no doubt be PyBytearray, though. > > > > > > Yeah, we've already planed to keep PyUnicode as prefix for str type > > > functions. It makes perfectly sense, not only from the historical point > > > of view. > > > > > > But for PyString I planed to rename the prefix to PyBytes. In my > > > opinion we are going to regret it, when we keep too many legacy names > > > from 2.x. In order to make the migration process easier I can add a > > > header file that provides PyString_* functions as aliases for PyBytes_* > > > > +1 on only doing this via a header that must be explicitly included by > > modules wanting the compatibility names. > > OK, as long as it's also supplied (and presumably empty) for 2.6 -- my > key concern is faciitating the maintenance of a single codebase for > C-coded Python extensions that can be compiled for both 2.6 and 3.0. > (I'm also thinking of SWIG and similar utilities, but those can > probably best be tweaked to emit rather different C code for the two > cases; still, that C code will also include some C snippets hand-coded > by the extension author/maintainer, e.g. via SWIG typemaps &c, so > easing the "single codebase" approach may help there too). > > I don't think we want to go the route of code translators/generators > for C-coded Python extensions (the way we do for Python code via > 2to3), and the fewer #if's and #define's C extension > authors/maintainers are required to devise (in order to support both > 2.6 and 3.0), the likelier it is that we'll see 3.0 support in popular > C-coded Python extensions sooner rather than later. Speaking for myself, this isn't going to make any difference as pre-2.6 versions of Python still need to be supported. More of a pain is if 2.6 introduces source level incompatibilities with 2.5 (as 2.5 did with 2.4). Phil ___ 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] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
On behalf of the Python development team and the Python community, I'm happy to announce the release candidates of Python 2.4.5 and 2.4.5. Both releases include only security fixes. Python 2.5 is the latest version of Python, we're making this release for people who are still running Python 2.3 or 2.4. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of bugs fixed; most of them prevent interpreter crashes (and now cause proper Python exceptions in cases where the interprerter may have crashed before). Assuming no major problems crop up, a final release of Python 2.4.4 will follow in about a week's time. For more information on Python 2.3.7 and 2.4.5, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.3.7 http://www.python.org/2.4.5 Highlights of the previous major Python releases are available from the Python 2.4 page, at http://www.python.org/2.3/highlights.html http://www.python.org/2.4/highlights.html Enjoy this release, Martin Martin v. Loewis [EMAIL PROTECTED] Python Release Manager (on behalf of the entire python-dev team) ___ 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] C-API status of Python 3?
Stefan Behnel wrote: > The release schedule in PEP 3000 says "August 2008" for 3.0 final, is that > still the current goal? Can I expect the C-API to stabilise by June, then? > That's where we are planning a Cython workshop with a couple of sprints. Py3k > support might be worth targeting - if we can rely on a fixed target by then. Yes, August 2008 is still our goal. I still think it's a realistic goal. The C API is mostly stabilized around May when we target the first beta. > I actually expect the string semantics to be amongst the harder changes (at > least, it's the most visible from a C-API point of view). > > However, names are not a big problem if you generate code anyway. Behaviour is > what matters most for Cython. And we're already trying to adapt Cython's > syntax to Py3k's, although that's not a requirement in all cases, as Cython > lives with a couple of differences already. Keeping old syntax around and > mapping it to the new C-API makes it easier to migrate existing Cython code. The semantics are easier in Python 3.x than in the 2.x series. Old style classes are gone, longs are gone and integers are PyLong based, the distinction between bytes and text is much easier ... 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] C-API status of Python 3?
M.-A. Lemburg wrote: > Why not also make unicode() the default type constructor and only > keep str() as alias to simplify porting (perhaps with a warning) ? -1 on making us type 7 characters instead of 3 all over the place. > The term "string" is just too overloaded with all kinds of > misinterpretations. The term "string" just refers to a string of > bytes - a variable length array so to speak. I disagree -- "string" has come to mean "string of characters" unless otherwise qualified. Using one to hold non-characters is just an aberration that was necessary in Python 2 because there wasn't much alternative. -- 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] C-API status of Python 3?
On 2008-03-02 20:39, Bill Janssen wrote: >> Why not also make unicode() the default type constructor and only >> keep str() as alias to simplify porting (perhaps with a warning) ? >> >> The term "string" is just too overloaded with all kinds of >> misinterpretations. The term "string" just refers to a string of >> bytes - a variable length array so to speak. However, depending >> on the application space, "string" is used as synonym for >> "text string" just as well as "data string". >> >> Removing the term "string" altogether would make it easier for >> people to understand that Py3k only has unicode (for text data) >> and bytes (for binary data). > > I agree that "string" is very overloaded, but calling it "unicode" is > sort of like calling integers "int32" -- that is, you're talking about > the implementation rather than the type. Hmm in that case, we'd have to call it "ucs2" or "ucs4" depending on how Python was compiled ;-) > In most programming > languages that aren't at the machine level (like C is), "string" > really is a sequence of text characters, not a "string of bytes", and > that's probably the term that should be used for Python going forward, > despite the legacy issues it involves. I'm not bound to "unicode" at all, just don't think using "string" for text data will really make people think twice often enough and then you end up having binary data in a "string" again - with the only difference that it's now using the Unicode type internally. My personal favorite is "text" for text data. > Personally, I feel that "string" (for text) and "bytes" (for binary > data represented as a sequence of bytes) are appropriate terms for > Python. Keep "unicode" for a release or two as an alias for "string". > But isn't all this in a PEP somewhere already? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 03 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] C-API status of Python 3?
On 2008-03-02 23:11, Greg Ewing wrote: > M.-A. Lemburg wrote: >> Why not also make unicode() the default type constructor and only >> keep str() as alias to simplify porting (perhaps with a warning) ? > > -1 on making us type 7 characters instead of > 3 all over the place. Oh well... how about "text()" ? >> The term "string" is just too overloaded with all kinds of >> misinterpretations. The term "string" just refers to a string of >> bytes - a variable length array so to speak. > > I disagree -- "string" has come to mean "string of > characters" unless otherwise qualified. Using one > to hold non-characters is just an aberration that > was necessary in Python 2 because there wasn't much > alternative. Buffer objects have been around for years and for exactly this purpose. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 03 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] Py3k and asyncore/asynchat
I've discussed a lot with Josiah via e-mail and I provided an updated version of the patch proposed in bug #1736190 including a fix for the two issues raised by me in the bug report. The update has been needed also because the original patch has been out-dated by some commits after r53734 involving the test suite and the documentation, which I both took off this patch. I also re-added simple_producer and fifo classes in asynchat.py since it seems they are needed for passing tests. The test suite has passed on Windows XP using Python 2.6 alpha 1. I have also successfully run the test suite of a project of mine based on asynchat which includes over 40 tests. ___ 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] Py3k and asyncore/asynchat
As far as I can tell, the asyncore.py, asynchat.py, and updated test_asyncore.py are good. I have been using earlier variants in my own projects (prior to their updating to pass the test suite) for quite a few months now. The updated modules provide better performance, features, and support for real-world async socket servers, never mind fixing more than a half dozen outstanding bugs. - Josiah On Sun, Mar 2, 2008 at 3:19 PM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > I've discussed a lot with Josiah via e-mail and I provided an updated > version of the patch proposed in bug #1736190 including a fix for the > two issues raised by me in the bug report. > The update has been needed also because the original patch has been > out-dated by some commits after r53734 involving the test suite > and the documentation, which I both took off this patch. > I also re-added simple_producer and fifo classes in asynchat.py since > it seems they are needed for passing tests. > > The test suite has passed on Windows XP using Python 2.6 alpha 1. > I have also successfully run the test suite of a project of mine based > on asynchat which includes over 40 tests. > ___ 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 XML Validator
I tested and tried a few XML validators but none of them is able to successfully validate a string of xml (not a file just a string) to programatically be able to validate messages of xml that flow in and out of the different systems. Teh validators I used were XSV, oNVDL and lxml, can we implement a pure python module for validating strings of xml using XML Schema (not DTD). lxml is good but not written in python and difficult to install and didn't work on MacOS X. XSV very poor documentation and only validates xml files not strings. oNVDL not writtem in python and only validates xml files not strings. ___ 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] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
On Mar 2, 2008, at 4:05 PM, Martin v. Löwis wrote: > Assuming no major problems crop up, a final release of Python 2.4.4 > will > follow in about a week's time. I do suppose you mean 2.4.5. 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2: gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused- madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include - DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function ‘posix_setpgrp’: ./Modules/posixmodule.c:3145: error: too few arguments to function ‘setpgrp’ make: *** [Modules/posixmodule.o] Error 1 I can only presume I'm doing something wrong at this point, since I don't consider myself a Mac OS X developer. -Fred -- Fred Drake ___ 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] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
On Mar 2, 2008, at 7:43 PM, Fred Drake wrote: > 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2: Neither does 2.3.7 now that I've tried that: gcc -u __dummy -u _PyMac_Error -framework System -framework CoreServices -framework Foundation -o python.exe \ Modules/python.o \ libpython2.3.a -ldl Undefined symbols: "__dummy", referenced from: ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [python.exe] Error 1 Of course, I wasn't using an earlier 2.3.x version on this box. I would really like to be able to use 2.4.5, since I've been using 2.4.4 for work for a while now. -Fred -- Fred Drake ___ 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] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
On Sun, Mar 2, 2008 at 4:52 PM, Fred Drake <[EMAIL PROTECTED]> wrote: > On Mar 2, 2008, at 7:43 PM, Fred Drake wrote: > > 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2: > > > Neither does 2.3.7 now that I've tried that: > > gcc -u __dummy -u _PyMac_Error -framework System -framework > CoreServices -framework Foundation -o python.exe \ > Modules/python.o \ > libpython2.3.a -ldl > Undefined symbols: >"__dummy", referenced from: > ld: symbol(s) not found > collect2: ld returned 1 exit status > make: *** [python.exe] Error 1 > > Of course, I wasn't using an earlier 2.3.x version on this box. I > would really like to be able to use 2.4.5, since I've been using 2.4.4 > for work for a while now. For me on OS X 10.5.2 (gcc 4.0.1) for 2.37 I am getting a ton of: sem_post: Bad file descriptor sem_init: Function not implemented sem_trywait: Bad file descriptor -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] C-API status of Python 3?
On Sun, Mar 2, 2008 at 3:26 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2008-03-02 23:11, Greg Ewing wrote: > > M.-A. Lemburg wrote: > >> Why not also make unicode() the default type constructor and only > >> keep str() as alias to simplify porting (perhaps with a warning) ? > > > > -1 on making us type 7 characters instead of > > 3 all over the place. > > Oh well... how about "text()" ? Sorry, this was discussed and decided long ago. I'm not going to change this now. The type is called string or some variation thereof in most other popular languages. > >> The term "string" is just too overloaded with all kinds of > >> misinterpretations. The term "string" just refers to a string of > >> bytes - a variable length array so to speak. > > > > I disagree -- "string" has come to mean "string of > > characters" unless otherwise qualified. Using one > > to hold non-characters is just an aberration that > > was necessary in Python 2 because there wasn't much > > alternative. Historically that's incorrect. In 1990, when Unicode hadn't even been invented, 'str' was very intentionally designed to hold text and data equally well. > Buffer objects have been around for years and for exactly > this purpose. No, buffer objects were not invented to *hold* binary data. The buffer API was invented to *reference* bytes that were owned by 3rd party C libraries. Its descendant in Py3k, 'memoryview' (see PEP 3118) has the same purpose without having the same bugs. For *holding* bytes in Py3k we'll use bytes (immutable) or bytearray (mutable). -- --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] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
"It has to do with the MACOSX_DEPLOYMENT_TARGET. If it's set to 10.4, the legacy version of setpgrp is used (with args), it it's 10.5, setpgrp expects no arguments. It seems configure won't detect the difference." http://bugs.python.org/issue1358 This issue was fixed for Python 2.5. As the issue notes, you can work around it with: ./configure MACOSX_DEPLOYMENT_TARGET=10.5 But it would be really nice if the configure fix for 2.5 was backported to 2.4.5 since Zope is still on 2.4 and Mac OS X skipped system builds for 2.4 going direct from 2.3 -> 2.5. ___ 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] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
On Mar 2, 2008, at 8:35 PM, Kevin Teague wrote: > This issue was fixed for Python 2.5. As the issue notes, you can > work around it with: > > ./configure MACOSX_DEPLOYMENT_TARGET=10.5 Indeed, that works wonderfully for me for 2.4.5. > But it would be really nice if the configure fix for 2.5 was > backported to 2.4.5 since Zope is still on 2.4 and Mac OS X skipped > system builds for 2.4 going direct from 2.3 -> 2.5. Yes, it would be very nice if this worked out of the box on Mac OS X 10.5.2. It's definitely a surprise for those of us who built our 2.4.4 on Mac OS X 10.4.x. -Fred -- Fred Drake ___ 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] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
>> Assuming no major problems crop up, a final release of Python 2.4.4 will >> follow in about a week's time. > > I do suppose you mean 2.4.5. Oops, yes. > 2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2: > > gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp > -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. > -I./Include -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o > Modules/posixmodule.o > ./Modules/posixmodule.c: In function ‘posix_setpgrp’: > ./Modules/posixmodule.c:3145: error: too few arguments to function > ‘setpgrp’ > make: *** [Modules/posixmodule.o] Error 1 > > I can only presume I'm doing something wrong at this point, since I > don't consider myself a Mac OS X developer. No. 2.4.5 just won't compile on OSX 10.5.2. This bug has been fixed for 2.5 (IIUC), but the fix was not backported (nor should it be, as it is not relevant for security). Use OS X 10.4 if you want to use Python 2.4. 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] [ANN] Python 2.3.7 and 2.4.5, release candidate 1
>> But it would be really nice if the configure fix for 2.5 was >> backported to 2.4.5 since Zope is still on 2.4 and Mac OS X skipped >> system builds for 2.4 going direct from 2.3 -> 2.5. > > > Yes, it would be very nice if this worked out of the box on Mac OS X > 10.5.2. It's definitely a surprise for those of us who built our 2.4.4 > on Mac OS X 10.4.x. I can put a notice in the release notes, but I definitely won't change it to work out of the box. If 2.4.4 compiled out of the box on this box, it would have been a regression and would have to be fixed. IIUC, 2.4.4 won't compile on 10.5, either, and Python 2.4.5 will have no code to port it to new platforms. 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
