Re: [Python-Dev] No email about buildbot failures for 3.1?
Brett Cannon wrote: I just realized that I had not received any emails on python-checkins about the buildbot failures I accidentally caused. And then I noticed that I had not gotten any emails for py3k in a while. Did that get switched off on purpose? No, it did not get switched off at all. I don't know what's happening. 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] No email about buildbot failures for 3.1?
Brett Cannon wrote: I just realized that I had not received any emails on python-checkins about the buildbot failures I accidentally caused. And then I noticed that I had not gotten any emails for py3k in a while. Did that get switched off on purpose? I'm not even sure that anything changed at all. Buildbot sent a failure message for the 3.0 branch as late as today: http://mail.python.org/pipermail/python-checkins/2009-January/077320.html 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] bundlebuilder broken in 2.6
On 17 Jan 2009, at 20:08, Ned Deily wrote: In article 7043cb7c-18f4-4e16-ae0c-cda6ba311...@barrys-emacs.org, Barry Scott ba...@barrys-emacs.org wrote: It seems that the packaging of Mac Python 2.6 is missing at least one file that is critical to the operation of bundlebuilder.py. I've logged the issue as http://bugs.python.org/issue4937. I've noted a workaround in the tracker: just copy the file from an older version of Python. It's a simple xml plist and I don't think its contents are all that critical anyway. I figured the contents are not not important as the files from 2.5 and 2.4 talk of alpha this that and the other. While the build should be fixed for 2.6+ (I'll send a patch), note that bundlebuilder is gone in 3.0. What is the replacement for bundlebuilder for 3.0? Lack of bundlebuilder becomes a serious porting problem for me. I deliver pysvn WOrkbench as a bundle to simplify installation by my users. Barry ___ 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] Strategies for debugging buildbot failures?
This is probably a stupid question, but here goes: Can anyone suggest good strategies for debugging buildbot test failures, for problems that aren't reproducible locally? There have been various times in the past that I've wanted to be able to do this. Right now, I'm thinking particularly of the 'Unknown signal 32' failure that's been occurring on the gentoo x86 buildbots for 3.0 and 3.x since pre- 3.0 alpha days. I recently noticed an apparent pattern to these failures: (failure occurs at the first test that involves threads, after test_os has been run), but am unsure how to proceed from there. Is it acceptable to commit a change (to the trunk or py3k, not to the release branches) solely for the purpose of getting more information about a failure? I don't see a lot of this kind of activity going on in the checkin messages, so I'm not sure whether this is okay or not. If I did this, the commit message would clearly indicate that the checkin was meant to be temporary, and give an expected time to reversion. Alternatively, is it reasonable to create a new branch solely for the purpose of tracking down one particular problem? Again, I don't see this sort of thing happening, but it seems like an attractive strategy, since it allows one to test one particular buildbot (via the form for requesting a build) without messing up anything else. What do others do to debug these failures? Mark (P.S. After a bit of Googling, I suspect the 'Unknown signal 32' failure of being related to the LinuxThreads library, and probably not Python's fault. But it would still be good to understand why it occurs with 3.x but not 2.x, and whether there's an easy workaround.) ___ 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] Strategies for debugging buildbot failures?
Mark Dickinson wrote: This is probably a stupid question, but here goes: Can anyone suggest good strategies for debugging buildbot test failures, for problems that aren't reproducible locally? There have been various times in the past that I've wanted to be able to do this. Right now, I'm thinking particularly of the 'Unknown signal 32' failure that's been occurring on the gentoo x86 buildbots for 3.0 and 3.x since pre- 3.0 alpha days. I recently noticed an apparent pattern to these failures: (failure occurs at the first test that involves threads, after test_os has been run), but am unsure how to proceed from there. Is it acceptable to commit a change (to the trunk or py3k, not to the release branches) solely for the purpose of getting more information about a failure? I don't see a lot of this kind of activity going on in the checkin messages, so I'm not sure whether this is okay or not. If I did this, the commit message would clearly indicate that the checkin was meant to be temporary, and give an expected time to reversion. At Resolver Systems we regularly extend the test framework purely to provide more diagnostic information in the event of test failures. We do a lot of functional testing through the UI, which is particularly prone to intermittent and hard to diagnose failures. It can be built in in a way that doesn't affect the test run unless the test fails - and so there is no reason not to make the changes permanent unless they are particularly intrusive. Michael Foord Alternatively, is it reasonable to create a new branch solely for the purpose of tracking down one particular problem? Again, I don't see this sort of thing happening, but it seems like an attractive strategy, since it allows one to test one particular buildbot (via the form for requesting a build) without messing up anything else. What do others do to debug these failures? Mark (P.S. After a bit of Googling, I suspect the 'Unknown signal 32' failure of being related to the LinuxThreads library, and probably not Python's fault. But it would still be good to understand why it occurs with 3.x but not 2.x, and whether there's an easy workaround.) ___ 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 -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] Strategies for debugging buildbot failures?
Is it acceptable to commit a change (to the trunk or py3k, not to the release branches) solely for the purpose of getting more information about a failure? [...] Alternatively, is it reasonable to create a new branch solely for the purpose of tracking down one particular problem? Either is ok. Committing to the trunk is more noisy, so I would prefer creation of a branch. Again, I don't see this sort of thing happening, but it seems like an attractive strategy, since it allows one to test one particular buildbot (via the form for requesting a build) without messing up anything else. Buildbot also supports submission of patches directly to the slaves. This is currently not activated, and clearly requires some authentication/authorization; if you want to use that, I'd be happy to experiment with setting it up, though. What do others do to debug these failures? In the past, for the really difficult problems, we arranged to have the developers get access to the buildbot slaves. Feel free to contact the owner of the slave if you want that; let me know if I should introduce you. 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
[Python-Dev] Single Sign-On for *.python.org
Hello, Should we open a ticket to make a single sign-on service for *.python.org sites? There are at least 3 logins there may be more, for example if we are going to make some online content edition/comment system for docs. These are: bugs.python.org wiki.python.org pypi.python.org History ~ Some months ago I filled a proposal to make an OpenID service for http://bugs.python.org http://bugs.python.org/issue2837 Because it was the only python.org service I used, I did not realize that *.python.org is bunch of separate services with their own authorization, but with the common template. So I was bounced to make an OpenID for roundup. Unfortunately, the sole openidenabled library failed to communicate with some Blogger servers, and due to the lack of support from the developer I was unable to continue my work. But OpenID is just convenience feature. Now that I have three accounts for python.org I fail to sync passwords between them if one of them is reset. I know about remember me buttons and the likes, but it is not always possible to work from personal station. So, the question is - should we open a ticket for Single Sign-On system for *.python.org or it bugs only me? WBR, -- --anatoly t. ___ 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] Single Sign-On for *.python.org
anatoly techtonik wrote: Hello, Should we open a ticket to make a single sign-on service for *.python.org sites? There are at least 3 logins there may be more, for example if we are going to make some online content edition/comment system for docs. These are: bugs.python.org wiki.python.org pypi.python.org History ~ Some months ago I filled a proposal to make an OpenID service for http://bugs.python.org http://bugs.python.org/issue2837 Because it was the only python.org service I used, I did not realize that *.python.org is bunch of separate services with their own authorization, but with the common template. So I was bounced to make an OpenID for roundup. Unfortunately, the sole openidenabled library failed to communicate with some Blogger servers, and due to the lack of support from the developer I was unable to continue my work. But OpenID is just convenience feature. Now that I have three accounts for python.org I fail to sync passwords between them if one of them is reset. I know about remember me buttons and the likes, but it is not always possible to work from personal station. So, the question is - should we open a ticket for Single Sign-On system for *.python.org or it bugs only me? No. Aside from the hassle of three, the registration process for the wiki is a bit broken, so if it would were obsoleted, that would be great. ___ 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] Single Sign-On for *.python.org
I would like to see that kind of coherence. I think anything that gets in the way of someone getting in is in danger of holding someone off from contributing something, be it wiki edits, bug reports, or packages. One might also ask about the mailman lists here. On Sun, Jan 18, 2009 at 2:21 PM, anatoly techtonik techto...@gmail.com wrote: Hello, Should we open a ticket to make a single sign-on service for *.python.org sites? There are at least 3 logins there may be more, for example if we are going to make some online content edition/comment system for docs. These are: bugs.python.org wiki.python.org pypi.python.org History ~ Some months ago I filled a proposal to make an OpenID service for http://bugs.python.org http://bugs.python.org/issue2837 Because it was the only python.org service I used, I did not realize that *.python.org is bunch of separate services with their own authorization, but with the common template. So I was bounced to make an OpenID for roundup. Unfortunately, the sole openidenabled library failed to communicate with some Blogger servers, and due to the lack of support from the developer I was unable to continue my work. But OpenID is just convenience feature. Now that I have three accounts for python.org I fail to sync passwords between them if one of them is reset. I know about remember me buttons and the likes, but it is not always possible to work from personal station. So, the question is - should we open a ticket for Single Sign-On system for *.python.org or it bugs only me? WBR, -- --anatoly t. ___ 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/ironfroggy%40gmail.com -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy ___ 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] Single Sign-On for *.python.org
So, the question is - should we open a ticket for Single Sign-On system for *.python.org or it bugs only me? Submission of tickets is futile. Code talks. 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
[Python-Dev] Help! Vista symlinks and IDLE
Apparently, if you install Python into a localized version of \Program Files on Vista (such as \Programas, or \Programmer), IDLE fails to start; see http://bugs.python.org/3881 Apparently, Tcl cannot properly initialize on such a system, and apparently, this is related to these folders being symlinks. It would be good if anybody who has access to such a system can diagnose what the specific problem is, how to reproduce it on a system that has the English version of Vista installed, and preferably, how to solve the problem. 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] No email about buildbot failures for 3.1?
On Sun, Jan 18, 2009 at 01:53, Martin v. Löwis mar...@v.loewis.de wrote: Brett Cannon wrote: I just realized that I had not received any emails on python-checkins about the buildbot failures I accidentally caused. And then I noticed that I had not gotten any emails for py3k in a while. Did that get switched off on purpose? I'm not even sure that anything changed at all. Buildbot sent a failure message for the 3.0 branch as late as today: http://mail.python.org/pipermail/python-checkins/2009-January/077320.html All I know is that I checked in a test that failed on all case-sensitive file system for py3k (3.1) and there does not appear to be a single email about it. And the buildbots very clearly had the chance to fail. -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] No email about buildbot failures for 3.1?
All I know is that I checked in a test that failed on all case-sensitive file system for py3k (3.1) and there does not appear to be a single email about it. And the buildbots very clearly had the chance to fail. What is the specific checkin? What specific builds failed? 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] No email about buildbot failures for 3.1?
On Sun, Jan 18, 2009 at 14:22, Martin v. Löwis mar...@v.loewis.de wrote: All I know is that I checked in a test that failed on all case-sensitive file system for py3k (3.1) and there does not appear to be a single email about it. And the buildbots very clearly had the chance to fail. What is the specific checkin? What specific builds failed? How about one that just happened: http://www.python.org/dev/buildbot/3.x.stable/sparc%20solaris10%20gcc%203.x/builds/126 . If you look at the python-checkins for the revision (http://mail.python.org/pipermail/python-checkins/2009-January/077369.html) at the index, there is no email about the buildbot failure. -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] Single Sign-On for *.python.org
Martin v. Löwis wrote: So, the question is - should we open a ticket for Single Sign-On system for *.python.org or it bugs only me? Submission of tickets is futile. Code talks. And don't forget that while a common authentication base is fine, you need to ensure that various services can be separately authorized - someone may have permission to log in to one server but not others? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] Help! Vista symlinks and IDLE
I'm glad someone sent this out... I was having this EXACT problem today I've got it installed on my wife's computer and I'm certain that it worked when I first installed 3.0a but it stopped working (I didn't update Python but my wife has done several Vista security updates)... Hopefully, that will help in the bug tracking for this. On Sun, Jan 18, 2009 at 5:02 PM, Martin v. Löwis mar...@v.loewis.dewrote: Apparently, if you install Python into a localized version of \Program Files on Vista (such as \Programas, or \Programmer), IDLE fails to start; see http://bugs.python.org/3881 Apparently, Tcl cannot properly initialize on such a system, and apparently, this is related to these folders being symlinks. It would be good if anybody who has access to such a system can diagnose what the specific problem is, how to reproduce it on a system that has the English version of Vista installed, and preferably, how to solve the problem. 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/hall.jeff%40gmail.com -- Haikus are easy Most make very little sense Refrigerator ___ 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] No email about buildbot failures for 3.1?
What is the specific checkin? What specific builds failed?
How about one that just happened:
http://www.python.org/dev/buildbot/3.x.stable/sparc%20solaris10%20gcc%203.x/builds/126
. If you look at the python-checkins for the revision
(http://mail.python.org/pipermail/python-checkins/2009-January/077369.html)
at the index, there is no email about the buildbot failure.
In that case, no mail was sent because this builder had a failed build
prior to this build already:
http://www.python.org/dev/buildbot/3.x.stable/sparc solaris10 gcc
3.x/builds/125
The MailNotifier is currently configured to send mail only when the
slave transitions from passed to failed ('problem'), not while it stays
in failed. That could be changed, of course (to either 'failing':
send mail for all failed builds, or 'all': send mail for all builds).
However, this has been the configuration since buildbot was first
installed, so its not a recent configuration change.
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] No email about buildbot failures for 3.1?
On Sun, Jan 18, 2009 at 14:49, Martin v. Löwis mar...@v.loewis.de wrote:
What is the specific checkin? What specific builds failed?
How about one that just happened:
http://www.python.org/dev/buildbot/3.x.stable/sparc%20solaris10%20gcc%203.x/builds/126
. If you look at the python-checkins for the revision
(http://mail.python.org/pipermail/python-checkins/2009-January/077369.html)
at the index, there is no email about the buildbot failure.
In that case, no mail was sent because this builder had a failed build
prior to this build already:
http://www.python.org/dev/buildbot/3.x.stable/sparc solaris10 gcc
3.x/builds/125
The MailNotifier is currently configured to send mail only when the
slave transitions from passed to failed ('problem'), not while it stays
in failed. That could be changed, of course (to either 'failing':
send mail for all failed builds, or 'all': send mail for all builds).
However, this has been the configuration since buildbot was first
installed, so its not a recent configuration change.
Ah, OK. Thanks for the clarification, Martin. Guess 3.1 has just been
failing for a while then.
-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] Support for the Haiku OS
The config.guess/.sub files in python/trunk/Modules/_ctypes/libffi are from , which is just before Haiku was finally added to the offical versions from gnulib. http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD So we just get fresh copies, perhaps it's time to update the version included with python? I built 2.7 on Haiku, but am getting failures in the regression tests. Many of them are in math related tests, failing in the 15th decimal place on test_decimal and a few others like that, I posted a ticket on Haiku's trac for that as it might be related to Haiku's built in math lib? (libm is built into Haiku's libroot.so) http://dev.haiku-os.org/ticket/3308 -scottmc ___ 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] __del__ and tp_dealloc in the IO lib
Dear python-dev, The Python implementation of IOBase, the base class for everything IO, has the (strange) idea to define a __del__ method. It is probably meant to avoid code duplication, so that users subclassing IOBase automatically get the close-on-destruct behaviour. (there is an even stranger test in test_io which involves overriding the __del__ method in a class derived from FileIO...) However, it has the drawback that all IO objects inherit a __del__ method, meaning problems when collecting reference cycles (the __del__ may not get called if caught in a reference cycle, defeating the whole point). While rewriting the IO stack in C, we have tried to keep this behaviour, but it seems better to just do it in the tp_dealloc function, and kill the __del__ (actually, we *already* do it in tp_dealloc, because __del__ / tp_del behaviour for C types is shady). Subclassing IOBase in Python would keep the tp_dealloc and therefore the close-on-destruct behaviour, without the problems of a __del__ method. (the implementation has to take a few precautions, first revive the object, then check its closed attribute/property - ignoring errors -, and if closed ended False then call the close() method) What do you think? Antoine. ___ 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] __del__ and tp_dealloc in the IO lib
On Sun, Jan 18, 2009 at 15:03, Antoine Pitrou solip...@pitrou.net wrote: Dear python-dev, The Python implementation of IOBase, the base class for everything IO, has the (strange) idea to define a __del__ method. It is probably meant to avoid code duplication, so that users subclassing IOBase automatically get the close-on-destruct behaviour. (there is an even stranger test in test_io which involves overriding the __del__ method in a class derived from FileIO...) However, it has the drawback that all IO objects inherit a __del__ method, meaning problems when collecting reference cycles (the __del__ may not get called if caught in a reference cycle, defeating the whole point). While rewriting the IO stack in C, we have tried to keep this behaviour, but it seems better to just do it in the tp_dealloc function, and kill the __del__ (actually, we *already* do it in tp_dealloc, because __del__ / tp_del behaviour for C types is shady). Subclassing IOBase in Python would keep the tp_dealloc and therefore the close-on-destruct behaviour, without the problems of a __del__ method. (the implementation has to take a few precautions, first revive the object, then check its closed attribute/property - ignoring errors -, and if closed ended False then call the close() method) What do you think? Fine by me. People should be using the context manager for guaranteed file closure anyway IMO. -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] __del__ and tp_dealloc in the IO lib
Brett Cannon schrieb: Fine by me. People should be using the context manager for guaranteed file closure anyway IMO. You make a very good point! Perhaps we should stop promising that files get closed as soon as possible and encourage people in using the with statement. 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] Strategies for debugging buildbot failures?
Mark Is it acceptable to commit a change (to the trunk or py3k, not to Mark the release branches) solely for the purpose of getting more Mark information about a failure? I think it would be kind of nice if you could force a buildbot to use a specific branch. You could then check your diagnostic changes in on a branch meant just for that purpose. Once you're done with your changes you could simply delete the branch. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Strategies for debugging buildbot failures?
On Sun, Jan 18, 2009 at 6:25 PM, s...@pobox.com wrote: Mark Is it acceptable to commit a change (to the trunk or py3k, not to Mark the release branches) solely for the purpose of getting more Mark information about a failure? I think it would be kind of nice if you could force a buildbot to use a specific branch. You could then check your diagnostic changes in on a branch meant just for that purpose. Once you're done with your changes you could simply delete the branch. You can already do that. Just click on the name of the buildbot, and then enter the branch you want it to test. -- Regards, Benjamin ___ 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] Single Sign-On for *.python.org
Calvin Spealman ironfro...@gmail.com writes: I would like to see that kind of coherence. I think anything that gets in the way of someone getting in is in danger of holding someone off from contributing something, be it wiki edits, bug reports, or packages. One might also ask about the mailman lists here. The inability to authenticate using one of my OpenIDs is a major factor keeping me from bothering to submit bug reports and edit wiki pages. I've also had fruitless discussions about adding OpenID authentication to Roundup. Gmane allows me to use NNTP without requiring authentication to participate in the discussion forums. -- \ “The truth is the most valuable thing we have. Let us economize | `\ it.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney ___ 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] bundlebuilder broken in 2.6
In article cd894749-4b8c-4ece-8743-414852edf...@barrys-emacs.org, Barry Scott ba...@barrys-emacs.org wrote: What is the replacement for bundlebuilder for 3.0? Lack of bundlebuilder becomes a serious porting problem for me. I deliver pysvn WOrkbench as a bundle to simplify installation by my users. Most people are using py2app these days to produce OSX application bundles for 2.x and the hope is for 3.0, as well. The pythonmac-sig forum is probably the best place to ask about experiences so far. Be aware that py2app hasn't been re-packaged recently so it's better to get it directly from its svn repository: http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html http://dir.gmane.org/gmane.comp.python.apple or http://mail.python.org/mailman/listinfo/pythonmac-sig -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __del__ and tp_dealloc in the IO lib
+1 on getting rid of the IOBase __del__ in the C rewrite in favor of tp_dealloc. On Sun, Jan 18, 2009 at 11:53 PM, Christian Heimes li...@cheimes.de wrote: Brett Cannon schrieb: Fine by me. People should be using the context manager for guaranteed file closure anyway IMO. Yes they should. (how I really really wish i didn't have to use 2.4 anymore ;) But lets at least be clear that is never acceptable for a python implementation to leak file descriptors/handles (or other system resources), they should be closed and released whenever the particular GC implementation gets around to it. You make a very good point! Perhaps we should stop promising that files get closed as soon as possible and encourage people in using the with statement. Christian eegads, do we actually -promise- that somewhere? If so I'll happily go update those docs with a caveat. I regularly point out in code reviews that the very convenient and common idiom of open(name, 'w').write(data) doesn't guarantee when the file will be closed; its up to the GC implementation details. Good code should never depend on the GC for a timely release of scarce external resources (file descriptors/handles). ___ 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] __del__ and tp_dealloc in the IO lib
On Sun, Jan 18, 2009 at 5:38 PM, Gregory P. Smith g...@krypto.org wrote: +1 on getting rid of the IOBase __del__ in the C rewrite in favor of tp_dealloc. On Sun, Jan 18, 2009 at 11:53 PM, Christian Heimes li...@cheimes.de wrote: Brett Cannon schrieb: Fine by me. People should be using the context manager for guaranteed file closure anyway IMO. Yes they should. (how I really really wish i didn't have to use 2.4 anymore ;) Come on, the open-try-use-finally-close idiom isn't *that* bad... But lets at least be clear that is never acceptable for a python implementation to leak file descriptors/handles (or other system resources), they should be closed and released whenever the particular GC implementation gets around to it. I would like to make a stronger promise. I think that for files open for *writing*, all data written to the file should be flushed to disk before the fd is closed. This is the real reason for having the __del__: closing the fd is done by the C implementation of FileIO, but since (until the rewrite in C) the buffer management is all in Python (both the binary I/O buffer and the additional text I/O buffer), I felt the downside of having a __del__ method was preferable over the possibility of output files not being flushed (which is always nightmarish to debug). Of course, once both layers of buffering are implemented in C, the need for __del__ to do this goes away, and I would be fine with doing it all in tp_alloc. You make a very good point! Perhaps we should stop promising that files get closed as soon as possible and encourage people in using the with statement. Christian eegads, do we actually -promise- that somewhere? If so I'll happily go update those docs with a caveat. I don't think we've promised that ever since the days when JPython (with a P!) was young... I regularly point out in code reviews that the very convenient and common idiom of open(name, 'w').write(data) doesn't guarantee when the file will be closed; its up to the GC implementation details. Good code should never depend on the GC for a timely release of scarce external resources (file descriptors/handles). And buffer flushing. While I don't want to guarantee that the buffer is flushed ASAP, I do want to continue promising that it is flushed before the object is GC'ed and before the fd is closed. -- --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] Single Sign-On for *.python.org
I've also had fruitless discussions about adding OpenID authentication to Roundup. Did you offer patches to roundup during these discussions? 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] Single Sign-On for *.python.org
Martin v. Löwis mar...@v.loewis.de writes: I've also had fruitless discussions about adding OpenID authentication to Roundup. Did you offer patches to roundup during these discussions? I grabbed the source code, but got lost trying to figure out how Roundup does authentication internally. So, no patches were forthcoming from me on that. -- \ “An eye for an eye would make the whole world blind.” —Mahatma | `\Gandhi | _o__) | Ben Finney ___ 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] __del__ and tp_dealloc in the IO lib
On Sun, Jan 18, 2009 at 9:32 PM, Guido van Rossum gu...@python.org wrote: On Sun, Jan 18, 2009 at 5:38 PM, Gregory P. Smith g...@krypto.org wrote: +1 on getting rid of the IOBase __del__ in the C rewrite in favor of tp_dealloc. On Sun, Jan 18, 2009 at 11:53 PM, Christian Heimes li...@cheimes.de wrote: Brett Cannon schrieb: Fine by me. People should be using the context manager for guaranteed file closure anyway IMO. Yes they should. (how I really really wish i didn't have to use 2.4 anymore ;) Come on, the open-try-use-finally-close idiom isn't *that* bad... But lets at least be clear that is never acceptable for a python implementation to leak file descriptors/handles (or other system resources), they should be closed and released whenever the particular GC implementation gets around to it. I would like to make a stronger promise. I think that for files open for *writing*, all data written to the file should be flushed to disk before the fd is closed. This is the real reason for having the __del__: closing the fd is done by the C implementation of FileIO, but since (until the rewrite in C) the buffer management is all in Python (both the binary I/O buffer and the additional text I/O buffer), I felt the downside of having a __del__ method was preferable over the possibility of output files not being flushed (which is always nightmarish to debug). Of course, once both layers of buffering are implemented in C, the need for __del__ to do this goes away, and I would be fine with doing it all in tp_alloc. You make a very good point! Perhaps we should stop promising that files get closed as soon as possible and encourage people in using the with statement. Christian eegads, do we actually -promise- that somewhere? If so I'll happily go update those docs with a caveat. I don't think we've promised that ever since the days when JPython (with a P!) was young... I regularly point out in code reviews that the very convenient and common idiom of open(name, 'w').write(data) doesn't guarantee when the file will be closed; its up to the GC implementation details. Good code should never depend on the GC for a timely release of scarce external resources (file descriptors/handles). And buffer flushing. While I don't want to guarantee that the buffer is flushed ASAP, I do want to continue promising that it is flushed before the object is GC'ed and before the fd is closed. Could we add a warning if the file has not been explicitly flushed? Consider removing the implicit flush later, if there's a sufficient implementation benefit to it. -- Adam Olsen, aka Rhamphoryncus ___ 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
