[Python-Dev] the release gods are angry at python
The next releases of 2.6/3.0 are planned for April 2, just over a week from now. There is much work that needs to be done. The buildbots are in a pretty sad state and the gods are seeing too much red. http://www.python.org/dev/buildbot/stable/ http://www.python.org/dev/buildbot/all/ See my other mail that discusses the stable buildbots. The criteria for release is that all the stable buildbots are passing all the tests. So we really gotta get these green before Barry notices. You don't want to see Barry angry. You wouldn't like him when he's angry. I propose a code chill for new features. Changes to doc and tests can continue as usual. However, only submit a new feature *after* you fix a broken test first. If we have to get draconian, we can start breaking fingers when you break a test just like we do at work. :-) Specifically tests that need some TLC are: * test_winsound - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0 * test_threading - test_no_refcycle_through_target - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0 * test_socket deadlocks and times out - http://www.python.org/dev/buildbot/stable/x86%20W2k8%20trunk/builds/210/step-test/0 * test_ssl deadlocks and times out - http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0 * test_xmlrpc transient socket errors - http://www.python.org/dev/buildbot/stable/g4%20osx.4%20trunk/builds/3101/step-test/0 * test_mailbox - http://www.python.org/dev/buildbot/stable/x86%20XP-3%203.0/builds/723/step-test/0 * test_asynchat - http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/2756/step-test/0 Hopefully test_timeout is fixed, but that might be flaky too. There have been other tests that have also been flaky like test_asynchat, test_smtplib, test_ssl, test_urllib2net, test_urllibnet, test_xmlrpc_net and some of the tests that use networking. These all need to be fixed so the tests are 100% reliable and only fail when there is a real error. There are currently no release blocker issues: http://bugs.python.org/issue?%40columns=title%40columns=id%40sort=activitypriority=1%40group=prioritystatus=1%40action=search There are 48 critical issues: http://bugs.python.org/issue?%40columns=title%40columns=id%40sort=activitypriority=2%40group=prioritystatus=1%40action=search If you believe any issue should block the release, set the priority to release blocker and assign it to me (nnorwitz). Many of the critical issues are those that require 2to3 fixers. These can be checked in as they are written. Be sure to test them thoroughly and try to think of all the conditions that could possibly cause the fixer to fail or do the wrong thing. Right now, I don't know of any reason to hold up the release other than the failing tests. 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
[Python-Dev] stable buildbots
We need to get the tests for Python to be more stable so we can push out solid releases. In order to achieve this result, we need tests that are *100% reliable* and fail _only when there is a problem with Python_. While we aren't nearly as close to that goal as we need to be, we have to work towards it. The buildbots that have been more reliable are separated onto their own page: http://www.python.org/dev/buildbot/stable/ This is the page that should be tracked by most people. This is the page we will use to determine if Python is ready for release. All green means the release is ready to ship. This page should *always* show all green. Any change that causes any buildbot to fail, should be immediately reverted. When you commit code, make sure to refresh the stable buildbot page to ensure you haven't broken anything. The stable buildbots need to represent all major platforms, at least Windows, Mac OSX, and Linux. All of those are currently represented on the page along with several others. Unfortunately some of the tests, particularly on Windows, are not passing. We need to get these in better shape. Please help out. See my other mail for details or use the link above to find the current set of problems. As we fix more tests and more platforms become stable, I will add them to the stable page. This requires restarting the server, so I plan to do this during quiet times when all the buildbot slaves are idle. 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
Re: [Python-Dev] Decimal(unicode)
Greg Ewing wrote: I thought Decimal was going to be replaced by a C implementation soon anyway. If so, is it worth going to much trouble over this? I believe that was found to be more trouble than it was worth. So the optimisations focused on various ways of making the Python implementation more efficient. One of those ways was to store the mantissa as a string in order to gain the benefit of the fast str-int and int-str conversions. The 3.0 version no longer has that benefit, and it shows. It looks like it may be necessary to switch to a custom object for the mantissa storage in order to get those fast conversions back. 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] Decimal(unicode)
Martin v. Löwis wrote: For binary representations, we already have the struct module to handle the parsing, but for byte sequences with embedded ASCII digits it's reasonably common practice to use strings along with the respective type constructors. Sure, but why can't you write foo = int(bar[start:stop].decode(ascii)) then? Explicit is better than implicit. Yeah, this thread has convinced me that it would be better to start rejecting bytes in int() and float() as well rather than implicitly assuming an ASCII encoding. If we decide the fast path for ASCII is still important (e.g. to solve 3.0's current speed problems in decimal), then it would be better to add separate methods to int to expose the old 2.x str-int and int-str optimisations (e.g. an int.from_ascii class method and an int.to_ascii instance method). 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] Py3k and asyncore/asynchat
On Tue, Mar 25, 2008 at 11:26 PM, Neal Norwitz [EMAIL PROTECTED] wrote: Any reason this was sent just to me and not the list? Because gmail only replies to the sender by default. I need to remember to cc python-dev when I reply (I used the same email client for 8 1/2 years, remembering the quirks of gmail may take some time). On Tue, Mar 25, 2008 at 10:34 PM, Josiah Carlson [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2008 at 9:00 PM, Neal Norwitz [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 10:09 AM, Giampaolo Rodola' [EMAIL PROTECTED] wrote: On 14 Feb, 16:36, Giampaolo Rodola' [EMAIL PROTECTED] wrote: Ok, I'll try to take a look at all asyncore/chat reports and try to summarize them by splitting patches which solve bugs and patches which add enhancements or functionalities. === Patches for existing issues === - 1736190 which includes fixes for the following issues among other improvements: - 1063924 (asyncore should handle ECONNRESET in send()) - 1736101 (asyncore should handle ECONNABORTED in recv()) - 760475 (handle_error() should call handle_close() instead of close()) - 1740572 (refill_buffer() should call handle_close() rather than close()) - 777588 (wrong connection refused behavior on Windows) - 889153 (wrong connect() behavior) - 953599 (asyncore misses socket closes when poll is used) - 1025525 (asyncore.file_dispatcher should not take fd as argument) - 1519 (async_chat.__init__() and asyncore.dispatcher.__init__ parameters inconsistency) - 1541 (Bad OOB data management when using asyncore with select.poll()) - 2073 (asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)) === Open issues with no patches (need review) === - 658749 (asyncore connect() and winsock errors) - 1161031 (neverending warnings from asyncore) === Enhancements new features === - 1641 (add delayed calls feature) - 1563 (conversion to py3k and some other changes) That's a lot of patches. My immediate concern is that test_asynchat is very flaky and fails often. Sometimes it causes other tests to fail. Is there a patch that addresses this? If you need examples, just look through the buildbot mails that mention test_asynchat in: http://mail.python.org/pipermail/python-checkins/ No, it's one patch. All of the fixes were performed mostly by myself last spring, tested and verified in personal servers, then re-used by Giampaolo in his async ftp server (which pointed out a few small bugs, which have been fixed). Some platforms have more problems than others, but almost all platforms have failed test_asynchat at one point or another. Certainly that is the case. And according to my reading of a few buildbot failures, aside from someone breaking asyncore itself, the failures seem to stem from the test being unable to create a port to listen on in order to test the server/client functionality. This is a buildbot configuration issue (per host), not an asyncore issue. That was the case a long time (~3? months) ago, but hasn't been the case recently. See my recent message about the release. I'll look for it tomorrow. For reference, searches of 'site:mail.python.org test_asynchat failure buildbot' only seem to produce the socket listen error. If there is a better incantation to get google to produce the proper errors (and/or a link), I would appreciate the help. Please break up the patches into 2 sets and prioritize the patches with the set. Set #1: Patches that have a test and doc updates if required Set #2: Patches that don't have a test or doc updates as required For the patches that fall into Set #1, list them in priority order. Top priority would be a problem that fixes failures seen in the buildbots. Next priority would go to the patches that solve more serious problems. Post the results here. I will try to look at them. For every patch you list, make sure that it conforms to the proper style (e.g, PEP 8) and is essentially perfect and ready for inclusion. This means that there is a single file to download that contains all the modifications. The changes are appropriately commented, lines are less than 80 characters, etc. One of the modifications should be an entry in Misc/NEWS. I lied earlier; really there are two patches. The first is a patch to asyncore.py and asynchat.py . It addresses those bugs that Giampaolo has listed, it is tested, and works. The second patch is to update the documentation to mention the sample methods in asynchat for use as
Re: [Python-Dev] Decimal(unicode)
On 2008-03-26 07:11, Martin v. Löwis wrote: For binary representations, we already have the struct module to handle the parsing, but for byte sequences with embedded ASCII digits it's reasonably common practice to use strings along with the respective type constructors. Sure, but why can't you write foo = int(bar[start:stop].decode(ascii)) then? Explicit is better than implicit. Agreed. The whole purpose of Unicode is to store text. Data from a file isn't text per-se. You have to tell Python that a particular set of bytes is to be interpreted as text and that only works by explicitly converting the bytes to text. Numbers or digits aren't any different in this context. b1234 is just a sequence of bytes and could well represent the binary encoding of an integer, the start of a base64 encoded image, an SSH key or an audio file. Don't get fooled by the looks of b1234. It's really just a shorter way of writing 0x31 0x32 0x33 0x34. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 26 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] stable buildbots
2008/3/26, Neal Norwitz [EMAIL PROTECTED]: We need to get the tests for Python to be more stable so we can push out solid releases. In order to achieve this result, we need tests that are *100% reliable* and fail _only when there is a problem with +1 Python_. While we aren't nearly as close to that goal as we need to be, we have to work towards it. The buildbots that have been more reliable are separated onto their own page: http://www.python.org/dev/buildbot/stable/ This is for trunk or 3k? Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Backport of bytearray type and io module
Guido van Rossum schrieb: I'm okay with bytearray not being subclassable in 2.6 as a temporary measure. I wouldn't want that to leak into 3.0 though, and I'd rather have it subclassable in 2.6 as well. I wonder why it doesn't work in 2.6 but does work in 3.0? This fix for the issue was easy once I noticed the cause of the problem Modified: python/branches/trunk-bytearray/Objects/typeobject.c == --- python/branches/trunk-bytearray/Objects/typeobject.c(original) +++ python/branches/trunk-bytearray/Objects/typeobject.cWed Mar 26 13:20:46 2008 @@ -3762,6 +3762,8 @@ COPYBUF(bf_getwritebuffer); COPYBUF(bf_getsegcount); COPYBUF(bf_getcharbuffer); + COPYBUF(bf_getbuffer); + COPYBUF(bf_releasebuffer); } basebase = base-tp_base; 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] Backport of bytearray type and io module
Facundo Batista schrieb: So, now the byte object behaves equal in 2.6 and 3.0, right? Thanks! Correct! The bytearray type and the new IO system are now backported to Python 2.6. 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] Backport of bytearray type and io module
2008/3/26, Christian Heimes [EMAIL PROTECTED]: Correct! The bytearray type and the new IO system are now backported to Python 2.6. Thank you very much for this effort! Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Decimal(unicode)
On Wed, Mar 26, 2008 at 2:57 AM, Nick Coghlan [EMAIL PROTECTED] wrote: Greg Ewing wrote: I thought Decimal was going to be replaced by a C implementation soon anyway. If so, is it worth going to much trouble over this? I believe that was found to be more trouble than it was worth. So the optimisations focused on various ways of making the Python implementation more efficient. I think it's still worth considering a hybrid implementation of Decimal: C code for the basic integer arithmetic (that is, supply a long int replacement whose underlying implementation works in base a power of 10), and Python for all the complicated logic (dealing with flags, special values, etc.). This will speed things up in the usual cases, and also give everything the right asymptotics for those few people using Decimal to do really high precision arithmetic. (Right now, addition of two Decimals takes quadratic time.) The decimal long integer implementation is already in the sandbox, so this probably isn't as much work as it sounds. I won't have time for it until May, though. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
2008/3/26, Mark Dickinson [EMAIL PROTECTED]: I think it's still worth considering a hybrid implementation of Decimal: C code for the basic integer arithmetic (that is, supply a long int replacement whose underlying implementation works in base a power of 10), and Python for all the complicated logic (dealing I think that this is the way to go, also. -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Decimal(unicode)
Mark Dickinson wrote: On Wed, Mar 26, 2008 at 2:57 AM, Nick Coghlan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Greg Ewing wrote: I thought Decimal was going to be replaced by a C implementation soon anyway. If so, is it worth going to much trouble over this? I believe that was found to be more trouble than it was worth. So the optimisations focused on various ways of making the Python implementation more efficient. I think it's still worth considering a hybrid implementation of Decimal: C code for the basic integer arithmetic (that is, supply a long int replacement whose underlying implementation works in base a power of 10), and Python for all the complicated logic (dealing with flags, special values, etc.). This will speed things up in the usual cases, and also give everything the right asymptotics for those few people using Decimal to do really high precision arithmetic. (Right now, addition of two Decimals takes quadratic time.) The decimal long integer implementation is already in the sandbox, so this probably isn't as much work as it sounds. Ah, I didn't know that - I guess you're talking about extracting the integer arithmetic section from the decimal-c implementation? In that case, yes, using a custom type for the guts of the mantissa arithmetic instead of trying to get reasonable speed out of a mixture of builtin types would be a very good thing (and would obviously eliminate the current performance problems in the Py3k version of decimal). Do you think it would be feasible to get this done for the first beta at the beginning of June? (I did have a look at _decimal.c in the sandbox to see how much help I could offer, but I have to confess my eyes started to glaze over a bit ;) Or would it be better to pursue a simple C object that just stored a sequence of integers and provided methods for fast conversion to/from a long for 2.6/3.0 and defer the arithmetic-in-C to 3.1? 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] the release gods are angry at python
Georg Brandl schrieb: Perhaps make it an optional resource? In the py3k branch I've assigned the audio resource to the winsound tests. Only regrtest.py -uall or -uaudio runs the winsound test. Reason: the test sound was freaking out my poor cat. :/ 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] the release gods are angry at python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2008, at 2:21 AM, Neal Norwitz wrote: The next releases of 2.6/3.0 are planned for April 2, just over a week from now. There is much work that needs to be done. The buildbots are in a pretty sad state and the gods are seeing too much red. http://www.python.org/dev/buildbot/stable/ http://www.python.org/dev/buildbot/all/ See my other mail that discusses the stable buildbots. The criteria for release is that all the stable buildbots are passing all the tests. So we really gotta get these green before Barry notices. You don't want to see Barry angry. You wouldn't like him when he's angry. Of course, most people don't like me when I'm /not/ angry either! :) Thanks for being the Bad Cop on this Neal. Please folks, please help make these buildbots go green! I think we should all be disappointed if the releases have to slip because our stable buildbots are red. Neal and I will have free rein to back out changes if that turns them green so if your code changes cause a failure, and you want your changes to stay in, please spend some time fixing them. I propose a code chill for new features. Changes to doc and tests can continue as usual. However, only submit a new feature *after* you fix a broken test first. +1 - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR+pt4XEjvBPtnXfVAQKHQwP/WXCoUtJY7nq3xFExs5RCCEeWFceSBRJR XBjymIVVODaWyhzh2obCuD/reHiEHneVWBzrS+kuQPEdigR6R4wJIyLQNqol5bfD auDJzUAa4vrMjfJtf2+i3/GRaHPHzgwPfgyj1t5rlyE/3pLbSh+d4+qhtH8Hq0MY ExF6WVIWRDc= =FP2J -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] stable buildbots
On Wed, Mar 26, 2008 at 9:04 AM, Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2008, at 8:14 AM, Facundo Batista wrote: 2008/3/26, Neal Norwitz [EMAIL PROTECTED]: We need to get the tests for Python to be more stable so we can push out solid releases. In order to achieve this result, we need tests that are *100% reliable* and fail _only when there is a problem with +1 Python_. While we aren't nearly as close to that goal as we need to be, we have to work towards it. The buildbots that have been more reliable are separated onto their own page: http://www.python.org/dev/buildbot/stable/ This is for trunk or 3k? The page has stable buildbots for trunk, 2.5, and 3.0. I'm thinking that we should remove the 2.5 buildbots from the stable page. Neal, if you agree, can you do that? I'm fine with removing 2.5, but I'm not sure if it's easy. HINT HINT. If everyone else fixes the broken and flaky tests, I'll have more than enough time to fix this. 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
Re: [Python-Dev] Backport of bytearray type and io module
Yay indeed! Of course the new I/O module will undergo changes (Ping is working on it still I believe). Try to keep an eye on it so the improvements can be backported. On Wed, Mar 26, 2008 at 6:00 AM, Facundo Batista [EMAIL PROTECTED] wrote: 2008/3/26, Christian Heimes [EMAIL PROTECTED]: Correct! The bytearray type and the new IO system are now backported to Python 2.6. Thank you very much for this effort! Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ -- --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] Backport of bytearray type and io module
Guido van Rossum schrieb: Yay indeed! Of course the new I/O module will undergo changes (Ping is working on it still I believe). Try to keep an eye on it so the improvements can be backported. Could somebody (perhaps me *g*) create a 3to2 fixer that removes the function annotations? IIRC I only had to remove the annotations from the io module and add a from __future__ import print_function to get it working correctly. 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] how to easily consume just the parts of eggs that are good for you
Folks: Here is a simple proposal: make the standard Python import mechanism notice eggs on the PYTHONPATH and insert them (into the *same* location) on the sys.path. This eliminates the #1 problem with eggs -- that they don't easily work when installing them into places other than your site-packages and that if you allow any of them to be installed on your system then they take precedence over your non-egg packages even you explicitly put those other packages earlier in your PYTHONPATH. (That latter behavior is very disagreeable to more than a few prorgammers.) This also preserves most of the value of eggs for many use cases. This is backward-compatible with most current use cases that rely on eggs. This is very likely forward-compatible with new schemes that are currently being cooked up and will be deployed in the future. Regards, Zooko ___ 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] how to easily consume just the parts of eggs that are good for you
Has somebody made a list of the problems with eggs? Because I use them all the time and hasn't encountered any problems whatsoever, myself... :) So I am a bit surprised at the various discussions about them. ___ 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-3000] the release gods are angry at python
On Wed, Mar 26, 2008 at 1:21 AM, Neal Norwitz [EMAIL PROTECTED] wrote: The next releases of 2.6/3.0 are planned for April 2, just over a week from now. There is much work that needs to be done. The buildbots are in a pretty sad state and the gods are seeing too much red. http://www.python.org/dev/buildbot/stable/ http://www.python.org/dev/buildbot/all/ See my other mail that discusses the stable buildbots. The criteria for release is that all the stable buildbots are passing all the tests. So we really gotta get these green before Barry notices. You don't want to see Barry angry. You wouldn't like him when he's angry. I propose a code chill for new features. Changes to doc and tests can continue as usual. However, only submit a new feature *after* you fix a broken test first. If we have to get draconian, we can start breaking fingers when you break a test just like we do at work. :-) Specifically tests that need some TLC are: * test_winsound - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0 * test_threading - test_no_refcycle_through_target - http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0 * test_socket deadlocks and times out - http://www.python.org/dev/buildbot/stable/x86%20W2k8%20trunk/builds/210/step-test/0 * test_ssl deadlocks and times out - http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0 * test_xmlrpc transient socket errors - http://www.python.org/dev/buildbot/stable/g4%20osx.4%20trunk/builds/3101/step-test/0 * test_mailbox - http://www.python.org/dev/buildbot/stable/x86%20XP-3%203.0/builds/723/step-test/0 * test_asynchat - http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/2756/step-test/0 Hopefully test_timeout is fixed, but that might be flaky too. There have been other tests that have also been flaky like test_asynchat, test_smtplib, test_ssl, test_urllib2net, test_urllibnet, test_xmlrpc_net and some of the tests that use networking. These all need to be fixed so the tests are 100% reliable and only fail when there is a real error. There are currently no release blocker issues: http://bugs.python.org/issue?%40columns=title%40columns=id%40sort=activitypriority=1%40group=prioritystatus=1%40action=search There are 48 critical issues: http://bugs.python.org/issue?%40columns=title%40columns=id%40sort=activitypriority=2%40group=prioritystatus=1%40action=search If you believe any issue should block the release, set the priority to release blocker and assign it to me (nnorwitz). Many of the critical issues are those that require 2to3 fixers. These can be checked in as they are written. Be sure to test them thoroughly and try to think of all the conditions that could possibly cause the fixer to fail or do the wrong thing. There are also some backporting issues in that pile. Should those hold up betas? (when we get there) Right now, I don't know of any reason to hold up the release other than the failing tests. n ___ Python-3000 mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com -- 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] httplib c. timeouts and global state
[This message will not be threaded properly since I wasn't subscribed at the time the original was sent] [John] What I found in the archive is this thread (sorry for the non-python.org URL): http://www.gossamer-threads.com/lists/python/dev/555039?do=post_view_threaded#555039 In that discussion, this issue is raised, but I don't see any resolution that answers the objection made in issue 2451. Anyway, apologies in advance if there was a decision here that takes account of the above objection. The solution to the problem John descibes WAS decided back at the time of discussion of the contribution, but for some reason, that solution never made into contribution that was committed. http://www.gossamer-threads.com/lists/python/dev/555108?do=post_view_threaded#555108 http://www.gossamer-threads.com/lists/python/dev/555110?do=post_view_threaded#555110 The solution is simple, as described on the bug that John created for this issue. http://bugs.python.org/issue2451 Alan. ___ 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-3000] the release gods are angry at python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2008, at 5:10 PM, Benjamin Peterson wrote: There are also some backporting issues in that pile. Should those hold up betas? (when we get there) Yes, but I would simply release the monthly alpha and push the beta back a month. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR+q/dXEjvBPtnXfVAQJYJAP9En+87NRtSOKcnEB4Om/BYE+Jw7KZ08JI HY1MGAHleya8MHIgaEkaQf142pzfHKWxWZLNWD5UShHPlarwfvIxHdT07q5ozGda l4J95FU2EaLMGxN+5HvxlY+pdXAiVcNAnO12TO1Gqahf9Mmk1eXkKM0p6vBPJHqZ vtekrWIzeck= =3v/o -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] Decimal(unicode)
Nick Coghlan wrote: Greg Ewing wrote: I thought Decimal was going to be replaced by a C implementation soon anyway. I believe that was found to be more trouble than it was worth. That's very disappointing. Was there any discussion of the problems that killed it? I don't remember seeing any showstoppers being mentioned. -- 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] Decimal(unicode)
Nick Coghlan wrote: Yeah, this thread has convinced me that it would be better to start rejecting bytes in int() and float() as well rather than implicitly assuming an ASCII encoding. I had another thought -- would it be feasible to have some kind of wrapper object that would make a byte array containing ascii chars look like a string? Then cases like this could be handled without having to copy the data. -- 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] Decimal(unicode)
Greg Ewing wrote: Nick Coghlan wrote: Greg Ewing wrote: I thought Decimal was going to be replaced by a C implementation soon anyway. I believe that was found to be more trouble than it was worth. That's very disappointing. Was there any discussion of the problems that killed it? I don't remember seeing any showstoppers being mentioned. I believe the list of incompatibilities and kludges and the subsequent comments in the following file give the gist of the problems: http://svn.python.org/projects/sandbox/trunk/decimal-c/_decimal.c Basically, while it makes a lot of sense to move the *arithmetic* to C (as Mark mentioned in his other post), there's a lot of ancillary stuff related to flags and exceptions and context handling that is much easier to handle in Python. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how to easily consume just the parts of eggs that are good for you
zooko wrote:
Folks:
Here is a simple proposal: make the standard Python import
mechanism notice eggs on the PYTHONPATH and insert them (into the
*same* location) on the sys.path.
This eliminates the #1 problem with eggs -- that they don't easily
work when installing them into places other than your site-packages
and that if you allow any of them to be installed on your system then
they take precedence over your non-egg packages even you explicitly
put those other packages earlier in your PYTHONPATH. (That latter
behavior is very disagreeable to more than a few prorgammers.)
Sorry if I'm out of the loop and there's some subtlety here that I'm
disregarding, but it doesn't appear that either of the issues you mention is a
actually problem with eggs. These are instead problems with how eggs get
installed by easy_install (which uses a .pth file to extend sys.path). It's
reasonable to put eggs on the PYTHONPATH manually (e.g.
sys.path.append('/path/to/some.egg')) instead of using easy_install to install
them.
I don't think there would be any benefit to changing Python's import machinery
to deal with them; they are essentially just directories (or zipfiles) that
contain packages.
- C
___
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
