Re: [Python-Dev] SSH access against buildbot boxes
On Sun, Nov 7, 2010 at 3:53 AM, Giampaolo Rodolà wrote: > In such cases I would find more easy to be able to connect to the > machine and test myself rather than create a separate branch, commit, > schedule a buildbot run, wait for it to complete and see whether > everything is "green". > > On the other side I perfectly understand how opening up blanket ssh > access is not something everyone is comfortable with doing. > AFAICR there was someone who was setting up an evironment to solve > exactly this problem but I'm not sure whether this is already usable. Dealing with exactly this problem is one of the goals of the Snakebite project. As far as I know, the folks behind that project are still working on it - I've cc'ed Trent Nelson to see if he can provide any additional info on the topic. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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-3 transition in Arch Linux
On Sat, Nov 6, 2010 at 11:41 PM, "Martin v. Löwis" wrote: > Instead, I recall that a decision was made (and I'm not sure whether > with consensus or not) that "make install" would install > /usr/bin/python3, for the time being. Period. Indeed, that's my recollection as well. Whether python3 ever inherits the python symlink at some point in the future is a different question that has never really been discussed (and probably makes more sense at the distro level at this point in time - "python = Python 2.x, python3 = Python 3.x" will likely stand as python-dev's consensus recommendation for quite some time to come). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot
On Saturday 06 November 2010 22:36:44 you wrote: > I couldn't find the matching failures that you're talking about, but > then I figured out you mean the FreeBSD7 (7.2) buildbot, not the > FreeBSD (6.4) buildbot Search "test_concurrent_futures" in: http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%207.2%203.x/builds/1154/steps/test/logs/stdio I specified "x86 FreeBSD 7.2 3.x" in the email title. > (...) > I noticed that the failures seem to always be on a semaphore call. > Some quick googling found a few references that seems to imply that > the number of posix semaphores are very limited (like 30), and can't > be changed without recompiling the kernel from source. So that's not > so big a threshold for the tests to have perhaps started crossing > since issue7272 was fixed. Certainly seems more likely than 3000+ > files or 1500+ processes. Nice catch. The problem is the total number of semaphores: I reproduced the bug in my FreeBSD 8 VM. The first test fails at the creation of the 31th semaphore. The first failing test if test_all_completed. And it looks like this test doesn't destroy the semaphore at exit: my counter (based on __init__/__del__) is still at 15 when exiting the test! > I wonder if it's possible to deduce if this started recently or not? > The web buildbot interface doesn't go back that far, and an additional > complexity is that the FreeBSD builds tend to have various errors > somewhat consistently over time, but perhaps there are server logs we > can grep for this particular error? No idea. > Not sure if the best approach at this point is to see if the tests can > use fewer semaphores, skip these tests under FreeBSD 7 like 6, or if > it's important enough to compile a new kernel with a higher semaphore > limit. You wrote that the "POSIX" semaphore are very limited. Do it mean that there is another kind of semaphore will an higher limit? I don't think that skipping the test is a good idea: it looks like a real bug in (a limitation of) the ProcessPoolExecutor implementation on FreeBSD. Eg. test_map fails on FreeBSD 7.2 with ProcessPoolExecutorTest which uses self.executor = futures.ProcessPoolExecutor(max_workers=1): only one worker process! It looks like it is possible to tune semaphore limits on FreeBSD, without recompiling the kernel, by using boot loader option (kern.ipc.sem* options). But ask the FreeBSD user to tune its boot loader options to use the concurrent.futures module is not pratical :-) Victor ___ 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] SSH access against buildbot boxes
Giampaolo Rodolà writes: > In such cases I would find more easy to be able to connect to the > machine and test myself rather than create a separate branch, commit, > schedule a buildbot run, wait for it to complete and see whether > everything is "green". I agree with both Stephen and Martin's prior responses. For me, I'm happy to arrange for individual access on a case by case basis, but am less comfortable leaving access enabled permanently. I've arranged access to both my Windows and FreeBSD buildbots in the past, and while I suspect my OSX Tiger buildbot may be a little less interesting than the other OSX boxes, the offer remains open for any of my buildbots. -- David ___ 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] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot
On Sat, Nov 6, 2010 at 7:19 AM, Victor Stinner > > I noticed "OSError: [Errno 23] Too many open files in system" errors on your > FreeBSD buildbot. I would like to know if you configured a limit on the open > files or maybe of child processes on this buildbot or not, or if it is a > failure in Python? > > The first error always occurs in the first test of test_concurrent_futures. > It's > maybe because this test uses a lot of open files or processes? I couldn't find the matching failures that you're talking about, but then I figured out you mean the FreeBSD7 (7.2) buildbot, not the FreeBSD (6.4) buildbot I haven't configured any specific limits with respect to open files. On both FreeBSD buildbots, kern.maxfiles is 3600 and kern.maxfilesperproc is 3060. Both have limits of 1530 processes. The latter also agrees with the maximum descriptors as shown by limit. In regards to R. David Murray's response, the buildbots are VMs with limited memory, so the dynamic calculation he references for descriptors is much lower than his system. Looks like the reason FreeBSD is ok, and FreeBSD7 is because the relevant tests don't run due to lack of POSIX semaphore support. I manually enabled their use on FreeBSD7 a while back (11/2009, issue7272) since they aren't on by default. I'd be surprised if at least test_multiprocessing didn't pass at that point (since that's what the issue was for) but even it seems to be generating the open files error now. The buildbots haven't changed, but I suppose the tests might just have grown in the number of files they need over time. I noticed that the failures seem to always be on a semaphore call. Some quick googling found a few references that seems to imply that the number of posix semaphores are very limited (like 30), and can't be changed without recompiling the kernel from source. So that's not so big a threshold for the tests to have perhaps started crossing since issue7272 was fixed. Certainly seems more likely than 3000+ files or 1500+ processes. I wonder if it's possible to deduce if this started recently or not? The web buildbot interface doesn't go back that far, and an additional complexity is that the FreeBSD builds tend to have various errors somewhat consistently over time, but perhaps there are server logs we can grep for this particular error? Not sure if the best approach at this point is to see if the tests can use fewer semaphores, skip these tests under FreeBSD 7 like 6, or if it's important enough to compile a new kernel with a higher semaphore limit. -- David ___ 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] SSH access against buildbot boxes
On 11/6/10 10:53 AM, Giampaolo Rodolà wrote: > Personally, I would find this particularly useful for OSX since it's > one of the few OSes I can't manage to virtualize and which often > causes me problems. Although I said this on IRC, I'll repeat the offer to the list for those not present -- I'm operating the Leopard and Snow Leopard buildslaves, and although I try to be proactive watching for failures, if someone wants to test something out before committing they can poke me and I'd be happy to help. I can either run a test or two and report back to you, or if you need it I can open up SSH or even VNC access on a temporary/as-needed basis. Heck, if you're doing some longer-term work that is more then just debugging a certain issue and would need access over a longer period of time, I can probably work something out for you. I'm just not comfortable opening up such access except on a person-by-person/case-by-case basis. I idle on #python-dev as "ixokai" -- you can ping me there and I generally wake up rather promptly. That, or email works too. -- Stephen Hansen ... Also: Ixokai ... Mail: me+python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital 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] [Python-checkins] r86170 - in python/branches/py3k: Doc/library/stdtypes.rst Lib/test/test_unicode.py Misc/NEWS Objects/stringlib/string_format.h Objects/unicodeobject.c
On 11/6/10 6:43 AM, Eric Smith wrote: On 11/6/10 1:16 AM, Ezio Melotti wrote: str.format_map> I've addressed all of these issues, although if anyone has suggestions for the docstrings or documentation they'd be appreciated. Thanks again. -- Eric. ___ 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] Summary of Python tracker Issues
Current status from the tracker... don't care: 22134 not closed: 2491 not selected: 1 open: 2451 languishing: 25 pending: 39 closed: 19604 That gives us... 2451 open 1 not selected 39 pending 25 languishing 2516 Total open 2451 open 39 languishing Should be 39 pending here, not languishing. --Ron 1 not selected 2491 total "not closed" 19604 closed 2491 not closed 39 pending - 22134 Total issues ___ 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] SSH access against buildbot boxes
> sorry in advance if this sounds a little indiscreet, but I think it > would be great if we'd have SSH access against some of the computers > used to host buildbots. The only way this can work is on a bilateral basis. If you need shell access to one of the build slaves, contact the slave operator. 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] Summary of Python tracker Issues
On 11/06/2010 12:01 PM, Terry Reedy wrote: On 11/6/2010 11:42 AM, R. David Murray wrote: On Sat, 06 Nov 2010 15:38:22 +0100, Georg Brandl wrote: Am 06.11.2010 05:44, schrieb Ezio Melotti: Hi, On 05/11/2010 19.08, Python tracker wrote: ACTIVITY SUMMARY (2010-10-29 - 2010-11-05) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 2514 (+17) This seems wrong. A default search for open issues returns 2452 and it was about the same yesterday just a few hours after the report. closed 19597 (+78) total 22111 (+95) as suggested in recent mails[0][1] I changed these values to represent the deltas with the previous week. Now let's try to keep the "open" delta negative ;) Since there were more issues closed than opened I think it really was. Anyway, we are down 300 from the 2750 peak. Current status from the tracker... don't care: 22134 not closed: 2491 not selected: 1 open:2451 languishing: 25 pending: 39 closed: 19604 That gives us... 2451 open 1 not selected 39 pending 25 languishing 2516 Total open 2451 open 39 languishing 1 not selected 2491 total "not closed" 19604 closed 2491 not closed 39 pending - 22134 Total issues My guess as to how this got this way, is that different fields were merged at some time where the meanings didn't quite match up. It would be nicer if... closed + not_closed = total issues closed + open + not_selected = total issues Pending and languishing should be keywords or sub categories of open. Cheers, Ron ___ 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] SSH access against buildbot boxes
Hi, sorry in advance if this sounds a little indiscreet, but I think it would be great if we'd have SSH access against some of the computers used to host buildbots. Personally, I would find this particularly useful for OSX since it's one of the few OSes I can't manage to virtualize and which often causes me problems. Some examples: http://bugs.python.org/issue10340 http://bugs.python.org/issue8490 (this one also involves Solaris) In such cases I would find more easy to be able to connect to the machine and test myself rather than create a separate branch, commit, schedule a buildbot run, wait for it to complete and see whether everything is "green". On the other side I perfectly understand how opening up blanket ssh access is not something everyone is comfortable with doing. AFAICR there was someone who was setting up an evironment to solve exactly this problem but I'm not sure whether this is already usable. Best regards, --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ ___ 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] Summary of Python tracker Issues
On 06/11/2010 19.01, Terry Reedy wrote: On 11/6/2010 11:42 AM, R. David Murray wrote: On Sat, 06 Nov 2010 15:38:22 +0100, Georg Brandl wrote: Am 06.11.2010 05:44, schrieb Ezio Melotti: Hi, On 05/11/2010 19.08, Python tracker wrote: ACTIVITY SUMMARY (2010-10-29 - 2010-11-05) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2514 (+17) This seems wrong. A default search for open issues returns 2452 and it was about the same yesterday just a few hours after the report. That's because the "open" count includes about 25 languishing and 39 pending issues (technically they are still open). closed 19597 (+78) total 22111 (+95) as suggested in recent mails[0][1] I changed these values to represent the deltas with the previous week. Now let's try to keep the "open" delta negative ;) Since there were more issues closed than opened I think it really was. Anyway, we are down 300 from the 2750 peak. That is a worthy goal, however the difference between the "open" and "closed" deltas is already quite an achievement and shows that our triage works. Yes, even if having a negative delta would be best, having the "closed" delta higher than then "open" one is still very good. So congrats to everyone who worked and works to make this possible. Agreed. We did have negative open deltas for several weeks running in October. Kudos to everyone involved, and lets do it some more :) I'm looking forward to making a non-trivial dent in the open count during the bug weekend on the 20th/21st. Best Regards, Ezio Melotti ___ 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-checkins] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py
On 11/6/2010 12:33 PM, "Martin v. Löwis" wrote: This was a private function used on an unsupported platform, this should do no harm. We’ve been bitten by “should do no harm” before though, so I am ready to revert this change (and learn from this :) Do as you like. I won't insist on it being reverted. It's rather a matter of agreeing when moving forward: IMO, mere style changes, code cleanup etc shouldn't be applied to the bug fix branches, as their only purpose is to provide bug fixes for existing users. The omission of the deletion from the 5/5 revision was a bug in that revision. If the removal of OS9 support was documented (announced), which I presume it was, then one could consider any visible trace remaining to be a bug. Perhaps the policy on code cleanup should be a bit more liberal for 2.7 *because* it will be maintained for several years and *because* there is no newer 2.x branch to apply changes to. If I were going to maintain 2.7 for several years, I would want to have the benefit of gradual improvements that make maintainance easier. Applying such a cleanup to 3.1, say, is less necessary because a) the code will soon be end-of-lifed and not maintained much and b) it can be applied to the newer (3.2) branch and benefit that and all future releases thereafter. -- Terry Jan Reedy ___ 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] Summary of Python tracker Issues
On 11/6/2010 11:42 AM, R. David Murray wrote: On Sat, 06 Nov 2010 15:38:22 +0100, Georg Brandl wrote: Am 06.11.2010 05:44, schrieb Ezio Melotti: Hi, On 05/11/2010 19.08, Python tracker wrote: ACTIVITY SUMMARY (2010-10-29 - 2010-11-05) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2514 (+17) This seems wrong. A default search for open issues returns 2452 and it was about the same yesterday just a few hours after the report. closed 19597 (+78) total 22111 (+95) as suggested in recent mails[0][1] I changed these values to represent the deltas with the previous week. Now let's try to keep the "open" delta negative ;) Since there were more issues closed than opened I think it really was. Anyway, we are down 300 from the 2750 peak. That is a worthy goal, however the difference between the "open" and "closed" deltas is already quite an achievement and shows that our triage works. Agreed. We did have negative open deltas for several weeks running in October. Kudos to everyone involved, and lets do it some more :) I'm looking forward to making a non-trivial dent in the open count during the bug weekend on the 20th/21st. -- Terry Jan Reedy ___ 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-3 transition in Arch Linux
On 11/6/2010 8:53 AM, Laurens Van Houtven wrote: Experience teaches us that people do speak up more than they tend to keep schtum. We do get feedback on most things, including the "NO ARCH" rule. It strikes me as reasonable to warn people that they would be wasting their time typing out a multiline question about problems with the new Arch distro. They can always ask briefly 'Why NO ARCH' and get back 'Beyond our knowledge' (or a longer pasted response). -- Terry Jan Reedy ___ 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-checkins] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py
> This was a private function used on an unsupported platform, this should > do no harm. We’ve been bitten by “should do no harm” before though, so > I am ready to revert this change (and learn from this :) Do as you like. I won't insist on it being reverted. It's rather a matter of agreeing when moving forward: IMO, mere style changes, code cleanup etc shouldn't be applied to the bug fix branches, as their only purpose is to provide bug fixes for existing users. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py
> I'm skeptical that this change should be carried out, then. Yes, I asked myself the same question. I had done the svnmerge from py3k, and when I saw that only one change was left, I wondered whether I should commit or revert. > It's easy to argue that this can't possibly hurt (but I can certainly > come up with code that will break under that change); however, I fail > to see what good it does. This was a private function used on an unsupported platform, this should do no harm. We’ve been bitten by “should do no harm” before though, so I am ready to revert this change (and learn from this :) Regards ___ 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-checkins] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py
> Remove one trace of Mac OS 9 support (#7908 follow-up) > > This was overlooked in r80804. This change is not really a bug fix, I'm skeptical that this change should be carried out, then. It's easy to argue that this can't possibly hurt (but I can certainly come up with code that will break under that change); however, I fail to see what good it does. 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] Summary of Python tracker Issues
On Sat, 06 Nov 2010 15:38:22 +0100, Georg Brandl wrote: > Am 06.11.2010 05:44, schrieb Ezio Melotti: > > Hi, > > > > On 05/11/2010 19.08, Python tracker wrote: > >> ACTIVITY SUMMARY (2010-10-29 - 2010-11-05) > >> Python tracker at http://bugs.python.org/ > >> > >> To view or respond to any of the issues listed below, click on the issue. > >> Do NOT respond to this message. > >> > >> Issues counts and deltas: > >>open2514 (+17) > >>closed 19597 (+78) > >>total 22111 (+95) > > > > as suggested in recent mails[0][1] I changed these values to represent > > the deltas with the previous week. > > Now let's try to keep the "open" delta negative ;) > > That is a worthy goal, however the difference between the "open" and "closed" > deltas is already quite an achievement and shows that our triage works. Agreed. We did have negative open deltas for several weeks running in October. Kudos to everyone involved, and lets do it some more :) I'm looking forward to making a non-trivial dent in the open count during the bug weekend on the 20th/21st. -- R. David Murray www.bitdance.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] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot
On Sat, 06 Nov 2010 12:31:39 +0100, Martin wrote: > Am 06.11.2010 12:19, schrieb Victor Stinner: > > Hi, > > > > I noticed "OSError: [Errno 23] Too many open files in system" errors on > > your > > FreeBSD buildbot. I would like to know if you configured a limit on the > > open > > files or maybe of child processes on this buildbot or not, or if it is a > > failure in Python? > > Before David responds: feel free to put temporarily a "limits -a" > command into the build process, or some such. You might also want to check the value of sysctl kern.maxfiles. On the FreeBSD (6.3) systems to which I have access the default value for kern.maxfiles appears to be 12328, but that information is of limited utility since its value is set based on kern.maxusers, which in turn is set at boot time based primarily on the available system memory (see: http://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html) The systems I got the above number from have 1GB of memory. -- R. David Murray www.bitdance.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] Summary of Python tracker Issues
Am 06.11.2010 05:44, schrieb Ezio Melotti: > Hi, > > On 05/11/2010 19.08, Python tracker wrote: >> ACTIVITY SUMMARY (2010-10-29 - 2010-11-05) >> Python tracker at http://bugs.python.org/ >> >> To view or respond to any of the issues listed below, click on the issue. >> Do NOT respond to this message. >> >> Issues counts and deltas: >>open2514 (+17) >>closed 19597 (+78) >>total 22111 (+95) > > as suggested in recent mails[0][1] I changed these values to represent > the deltas with the previous week. > Now let's try to keep the "open" delta negative ;) That is a worthy goal, however the difference between the "open" and "closed" deltas is already quite an achievement and shows that our triage works. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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-3 transition in Arch Linux
> But the previous consensus (at least, as I, and presumably many other > people understood it) was that python2 would remain the owner of the > name "/usr/bin/python" for the indefinite future, and python3 would > be invoked with /usr/bin/python3. Can you cite references for that (not that other people agree, but that this was consensus)? I couldn't find any summary report of the 2009 language summit, and, despite having been present there, I don't recall that aspect even being discussed. Instead, I recall that a decision was made (and I'm not sure whether with consensus or not) that "make install" would install /usr/bin/python3, for the time being. Period. So I don't recall a decision that there shouldn't be a python2 binary, nor a decision that anything is done indefinitely (it may be that the decision was actually just about 3.1 - changing it again for 3.2 would require another decision, but certainly can't be ruled out categorically). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
I'm sorry you feel that way. Experience teaches us that people do speak up more than they tend to keep schtum. We do get feedback on most things, including the "NO ARCH" rule. At least so far, responses have not been anywhere near what you'd expect if you'd tell people to "RTFM n00b" (in terms of defensiveness and verbal hostility, at least). From the things I've seen (and I've asked other regulars, they seem to agree), the related interactions have been short, clear, and cordial. The first is important to #python because it keeps the signal to noise ratio high. The second is important to the person with the broken package, so they know what to do to fix it and how to get it fixed for other people as well. The last part is important to everyone. As usual, any and all policy is up for debate, but I really see too much result (not just for #python, but for the people with the broken package as well) and too little badness to consider taking it down right now. I believe I speak for all of the ops and regulars in #python when I say that. Even Allan himself has said that he agrees with the rule, and yes: I do honestly believe that right now, it is the best thing we can actually *do*. That doesn't mean it has to be the best thing bar none: like with software projects, "patches welcome", if you have any suggestions for improving this, we're all ears. However, I've already said: this is temporary, it's going down as soon as we stop getting feedback on it. (Checking if that has occurred or not is in my tickler file for next Friday.) It has already been pointed out in this thread that Arch is a distro with a target audience of above average knowledge. Yes, the rule does expect people to understand the difference between an Arch-specific problem and something that's likely to be unrelated.to whatever distro it is you're running. Even the people who do feel instantly offended and just leave without asking questions, hey, at least they're likely to go to Arch-specific spots next for support, and that's the right place (FWIW I do not believe this to be a significant amount of people). Also, sometimes pointing people to the FM is just the only reasonable thing left to do. If you've got recent-ish logs (24h) I can give you a recent prime example of that. I do doubt that anyone used terminology like 'RTFM n00b'. If you think 'NO ARCH' is the same kind of language, well, we'll just have to agree to disagree there. I could see how someone would think that, but IRC typically forces people to be more brief, and a lot of people understandably mistake that for being blunt or even downright rude. That's an unfortunate side effect of the medium that pretty much every large channel I know of has had to deal with in some way. cheers lvh ___ 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] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot
Am 06.11.2010 12:19, schrieb Victor Stinner: > Hi, > > I noticed "OSError: [Errno 23] Too many open files in system" errors on your > FreeBSD buildbot. I would like to know if you configured a limit on the open > files or maybe of child processes on this buildbot or not, or if it is a > failure in Python? Before David responds: feel free to put temporarily a "limits -a" command into the build process, or some such. 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] "Too many open files" errors on "x86 FreeBSD 7.2 3.x" buildbot
Hi, I noticed "OSError: [Errno 23] Too many open files in system" errors on your FreeBSD buildbot. I would like to know if you configured a limit on the open files or maybe of child processes on this buildbot or not, or if it is a failure in Python? The first error always occurs in the first test of test_concurrent_futures. It's maybe because this test uses a lot of open files or processes? Victor ___ 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-checkins] r86170 - in python/branches/py3k: Doc/library/stdtypes.rst Lib/test/test_unicode.py Misc/NEWS Objects/stringlib/string_format.h Objects/unicodeobject.c
On 11/6/10 1:16 AM, Ezio Melotti wrote:
+.. method:: str.format_map(mapping)
+
+ Similar to ``str.forrmat(**mapping)``, except that ``mapping`` is
+ used directly and not copied to a :class:`dict` . This is useful
+ if for example ``mapping`` is a dict subclass.
Including the "__missing__" example might be better. From the
description, it's not clear why str.format(**dict_subclass) wouldn't
work and that the previous line refers to the fact that ** converts the
mapping in a plain dict, thus making __missing__ and other things unusable.
I agree, but I was hesitant to add a long example. But thinking about it
some more I think I'll add it.
+
+ self.assertEqual('{foo._x}'.format_map({'foo': C(20)}), '20')
+
The classes D-H seem unused, did you forget to add some tests or am I
missing something?
It was a big copy job from the other tests. I'll review them all.
+PyDoc_STRVAR(format_map__doc__,
+ "S.format_map(mapping) -> str\n\
+\n\
+");
+
Wouldn't a more verbose docstring be better? (str.format seems to lack
one too)
Undoubtedly true. Any suggestions? How about (for .format): "Returns S
formatted with substitutions from args and kwargs."
I also see that __format__'s docstring is similarly terse.
Thanks for reviewing!
--
Eric.
___
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
