Mailman 3 September 2006 - Python-Dev

Re: [Python-Dev] python, lipo and the future?
by howarth＠bromo.msbb.uc.edu 17 Sep '06

17 Sep '06

Martin, I believe if you use the Xcode project management the Universal binary creation is automated. Currently they support the i386/ppc binaries but once Leopard comes out you will see i386/x86_64/ppc/ppc64 binaries for shared libraries. Jack

2 1

Grammar change in classdef
by Fabio Zadrozny 17 Sep '06

17 Sep '06

I've been porting the grammar for pydev to version 2.5 and I've seen that you can now declare a class in the format: class B():pass (without the testlist) -- from the grammar: classdef: 'class' NAME ['(' [testlist] ')'] ':' suite I think that this change should be presented at http://docs.python.org/dev/whatsnew/whatsnew25.html I'm saying that because I've only stumbled upon it by accident -- and I wasn't able to find any explanation on the reason or semantics of the change... Thanks, Fabio

7 11

Thank you all
by Dan Eloff 15 Sep '06

15 Sep '06

I was just browsing what's new in Python 2.5 at http://docs.python.org/dev/whatsnew/ As I was reading I found myself thinking how almost every improvement made a programming task I commonly bump into a little easier. Take the with statement, or the new partition method for strings, or the defaultdict (which I think was previously available, but I only now realized what it does), or the unified try/except/finally, or the conditional expression, etc Then I remembered my reaction was much like that when python 2.4 was released, and before that when Python 2.3 was released. Every time a new version of python rolls around, my life gets a little easier. I just want to say thank you, very much, from the bottom of my heart, to everyone here who chooses to spend some of their free time working on improving Python. Whether it be fixing bugs, writing documentation, optimizing things, or adding new/updating modules or features, I want you all to know I really appreciate your efforts. Your hard work has long ago made Python into my favourite programming language, and the gap only continues to grow. I think most people here and on comp.lang.python feel the same way. It's just too often that people (me) will find the 1% of things that aren't quite right and will focus on that, rather than look at the 99% of things that are done very well. So now, while I'm thinking about it, I want to take the opportunity to say thank you for the 99% of Python that all of you have done such a good job on. -Dan

2 1

fun threading problem
by Neal Norwitz 14 Sep '06

14 Sep '06

On everyones favorite platform (HP-UX), the following code consistently fails: ### from thread import start_new_thread, allocate_lock from time import sleep def bootstrap(): from os import fork ; fork() allocate_lock().acquire() start_new_thread(bootstrap, ()) sleep(.1) ### The error is: Fatal Python error: Invalid thread state for this thread This code was whittled down from test_socketserver which fails in the same way. It doesn't matter what value is passed to sleep as long as it's greater than 0. I also tried changing the sleep to a while 1: pass and the same problem occurred. So there isn't a huge interaction of APIs, only: fork, allocate_lock.acquire and start_new_thread. HP-UX seems to be more sensitive to various threading issues. In Modules/_test_capimodule.c, I had to make this modification: Index: Modules/_testcapimodule.c =================================================================== --- Modules/_testcapimodule.c (revision 51875) +++ Modules/_testcapimodule.c (working copy) @@ -665,6 +665,9 @@ PyThread_acquire_lock(thread_done, 1); /* wait for thread to finish */ Py_END_ALLOW_THREADS + /* Release lock we acquired above. This is required on HP-UX. */ + PyThread_release_lock(thread_done); + PyThread_free_lock(thread_done); Py_RETURN_NONE; } Without that patch, there would be this error: sem_destroy: Device busy sem_init: Device busy Fatal Python error: UNREF invalid object ABORT instruction (core dumped) Anyone have any ideas? n

2 2

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 14 Sep '06

14 Sep '06

Patch / Bug Summary ___________________ Patches : 416 open ( +3) / 3408 closed ( +1) / 3824 total ( +4) Bugs : 898 open ( +1) / 6180 closed (+13) / 7078 total (+14) RFE : 234 open ( +0) / 238 closed ( +0) / 472 total ( +0) New / Reopened Patches ______________________ email parser incorrectly breaks headers with a CRLF at 8192 (2006-09-10) http://python.org/sf/1555570 opened by Tony Meyer datetime's strftime limits strings to 127 chars (2006-09-12) http://python.org/sf/1557390 opened by Eric V. Smith Add RLIMIT_SBSIZE to resource module (2006-09-12) http://python.org/sf/1557515 opened by Eric Huss missing imports ctypes in documentation examples (2006-09-13) http://python.org/sf/1557890 opened by Daniele Varrazzo Patches Closed ______________ UserDict New Style (2006-09-08) http://python.org/sf/1555097 closed by rhettinger New / Reopened Bugs ___________________ Bug in the match function (2006-09-09) CLOSED http://python.org/sf/1555496 opened by wojtekwu Please include pliblist for all plattforms (2006-09-09) http://python.org/sf/1555501 opened by Guido Guenther sgmllib should allow angle brackets in quoted values (2006-06-11) http://python.org/sf/1504333 reopened by nnorwitz Move fpectl elsewhere in library reference (2006-09-11) http://python.org/sf/1556261 opened by Michael Hoffman datetime's strftime limits strings to 127 chars (2006-09-11) http://python.org/sf/1556784 opened by Eric V. Smith datetime's strftime limits strings to 127 chars (2006-09-12) CLOSED http://python.org/sf/1557037 opened by Eric V. Smith typo in encoding name in email package (2006-09-12) http://python.org/sf/1556895 opened by Guillaume Rousse 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc (2006-09-12) http://python.org/sf/1557490 opened by Tony Bigbee xlc 6 does not like bufferobject.c line22 (2006-09-13) http://python.org/sf/1557983 opened by prueba uno apache2 - mod_python - python2.4 core dump (2006-09-14) CLOSED http://python.org/sf/1558223 opened by ThurnerRupert Tru64 make install failure (2006-09-14) http://python.org/sf/1558802 opened by Ralf W. Grosse-Kunstleve 2.5c2 macosx installer aborts during "GUI Applications" (2006-09-14) http://python.org/sf/1558983 opened by Evan Bugs Closed ___________ datetime.datetime.now() mangles tzinfo (2006-09-06) http://python.org/sf/1553577 closed by nnorwitz __unicode__ breaks for exception class objects (2006-09-03) http://python.org/sf/1551432 closed by bcannon Bug in the match function (2006-09-09) http://python.org/sf/1555496 closed by tim_one Recently introduced sgmllib regexp bug hangs Python (2006-08-16) http://python.org/sf/1541697 closed by nnorwitz logging.handlers.RotatingFileHandler - inconsistent mode (2006-09-06) http://python.org/sf/1553496 closed by vsajip datetime's strftime limits strings to 127 chars (2006-09-12) http://python.org/sf/1557037 closed by ericvsmith apache2 - mod_python - python2.4 core dump (2006-09-13) http://python.org/sf/1558223 closed by nnorwitz

1 0

release is done, but release25-maint branch remains near-frozen
by Anthony Baxter 13 Sep '06

13 Sep '06

Ok - we're looking at a final release in 7 days time. I really, really, really don't want to have to cut an rc3, so unless it's a seriously critical brown-paper-bag bug, let's hold off on the checkins. Documentation, I don't mind so much - particularly any formatting errors. -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

.pyc file has different result for value "1.79769313486232e+308" than .py file
by Dino Viehland 13 Sep '06

13 Sep '06

We've noticed a strange occurance on Python 2.4.3 w/ the floating point value 1.79769313486232e+308 and how it interacts w/ a .pyc. Given x.py: def foo(): print str(1.79769313486232e+308) print str(1.79769313486232e+308) == "1.#INF" The 1st time you run this you get the correct value, but if you reload the module after a .pyc is created then you get different results (and the generated byte code appears to have changed). Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import x >>> import dis >>> dis.dis(x.foo) 2 0 LOAD_GLOBAL 0 (str) 3 LOAD_CONST 1 (1.#INF) 6 CALL_FUNCTION 1 9 PRINT_ITEM 10 PRINT_NEWLINE 3 11 LOAD_GLOBAL 0 (str) 14 LOAD_CONST 1 (1.#INF) 17 CALL_FUNCTION 1 20 LOAD_CONST 2 ('1.#INF') 23 COMPARE_OP 2 (==) 26 PRINT_ITEM 27 PRINT_NEWLINE 28 LOAD_CONST 0 (None) 31 RETURN_VALUE >>> reload(x) <module 'x' from 'x.pyc'> >>> dis.dis(x.foo) 2 0 LOAD_GLOBAL 0 (str) 3 LOAD_CONST 1 (1.0) 6 CALL_FUNCTION 1 9 PRINT_ITEM 10 PRINT_NEWLINE 3 11 LOAD_GLOBAL 0 (str) 14 LOAD_CONST 1 (1.0) 17 CALL_FUNCTION 1 20 LOAD_CONST 2 ('1.#INF') 23 COMPARE_OP 2 (==) 26 PRINT_ITEM 27 PRINT_NEWLINE 28 LOAD_CONST 0 (None) 31 RETURN_VALUE >>> ^Z

2 3

RELEASED Python 2.5 (release candidate 2)
by Anthony Baxter 13 Sep '06

13 Sep '06

On behalf of the Python development team and the Python community, I'm happy to announce the second RELEASE CANDIDATE of Python 2.5. After the first release candidate a number of new bugfixes have been applied to the Python 2.5 code. In the interests of making 2.5 the best release possible, we've decided to put out a second (and hopefully last) release candidate. We plan for a 2.5 final in a week's time. This is not yet the final release - it is not suitable for production use. It is being released to solicit feedback and hopefully expose bugs, as well as allowing you to determine how changes in 2.5 might impact you. As a release candidate, this is one of your last chances to test the new code in 2.5 before the final release. *Please* try this release out and let us know about any problems you find. In particular, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows and Universal Mac OSX installers) are available from the 2.5 website: http://www.python.org/2.5/ As of this release, Python 2.5 is now in *feature freeze*. Unless absolutely necessary, no functionality changes will be made between now and the final release of Python 2.5. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New modules added include hashlib, ElementTree, sqlite3, wsgiref, uuid and ctypes. In addition, a new profiling module "cProfile" was added. Enjoy this new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

1 0

Subversion 1.4
by "Martin v. Löwis" 12 Sep '06

12 Sep '06

As many of you probably know: Subversion 1.4 has been released. It is safe to upgrade to this version, even if the repository server (for us svn.python.org) stays at an older version: they can interoperate just fine. There is one major pitfall: Subversion 1.4 changes the format of the working copy file structure (.svn/format goes from 4 to 8). This new format is more efficient: for a Python checkout, it saves about 15MiB (out of 125 MiB). Also, several operations (e.g. svn status) are faster. Subversion performs a silent upgrade of the existing repository on the first operation (I believe on the first modifying operation). However, this new format is not compatible with older clients; you need 1.4 clients to access an upgraded working copy. So if you use the same working copy with different clients (e.g. command line and turtoise, or from different systems through NFS), you either need to upgrade all clients, or else you should stay away from 1.4. Alternatively, you can have different checkouts for 1.3 and 1.4 clients, of course. Just in case you didn't know. Regards, Martin

1 0

datetime's strftime implementation: by design or bug
by Eric V. Smith 12 Sep '06

12 Sep '06

[I hope this belongs on python-dev, since it's about the design of something. But if not, let me know and I'll post to c.l.py.] I'm willing to file a bug report and patch on this, but I'd like to know if it's by design or not. In datetimemodule.c, the function wrap_strftime() insists that the length of a format string be <= 127 chars, by forcing the length into a char. This seems like a bug to me. wrap_strftime() calls time's strftime(), which doesn't have this limitation because it uses size_t. >>> import datetime >>> datetime.datetime.now().strftime('x'*128) Traceback (most recent call last): File "<stdin>", line 1, in ? MemoryError >>> import datetime >>> datetime.datetime.now().strftime('x'*256) in wrap_strftime totalnew=1 Traceback (most recent call last): File "<stdin>", line 1, in <module> SystemError: Objects/stringobject.c:4077: bad argument to internal function >>> import time >>> time.strftime('x'*128) 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' But before I write this up, I'd like to know if anyone knows if this is by design or not. This is reproducible on Windows 2.4.3, and Linux 2.3.3 and 2.5c1. Thanks. Eric.

3 3