Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet
On Thu, Dec 20, 2012 at 09:33:27AM -0800, Brian Curtin wrote: Last week in Raymond's dictionary thread, the topic of ARM came up, along with the relative lack of build slave coverage. Today Trent Nelson received the PandaBoard purchased by the PSF, and a Raspberry Pi should be coming shortly as well. http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html Thanks to the PSF for purchasing and thanks to Trent for offering to host them in Snakebite! The installation of Ubuntu on the Pandaboard went smoothly. However, it crashes after about an hour. Console output: http://trent.snakebite.net/pandaboard-crash.txt Any ARM wizards out there with suggestions? Trent. ___ 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] PandaBoard, Raspberry Pi coming to Buildbot fleet
On Fri, Jan 04, 2013 at 02:48:00AM -0800, Trent Nelson wrote: On Thu, Dec 20, 2012 at 09:33:27AM -0800, Brian Curtin wrote: Last week in Raymond's dictionary thread, the topic of ARM came up, along with the relative lack of build slave coverage. Today Trent Nelson received the PandaBoard purchased by the PSF, and a Raspberry Pi should be coming shortly as well. http://blog.python.org/2012/12/pandaboard-raspberry-pi-coming-to.html Thanks to the PSF for purchasing and thanks to Trent for offering to host them in Snakebite! The installation of Ubuntu on the Pandaboard went smoothly. However, it crashes after about an hour. Console output: http://trent.snakebite.net/pandaboard-crash.txt Any ARM wizards out there with suggestions? Forgot to mention, it's accessible via the p1 alias from the Snakebite menu. Until it crashes, anyway :-) If anyone wants root access to poke around, let me know. Trent. ___ 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] PandaBoard, Raspberry Pi coming to Buildbot fleet
2013/1/4 Trent Nelson tr...@snakebite.org: The installation of Ubuntu on the Pandaboard went smoothly. However, it crashes after about an hour. Console output: http://trent.snakebite.net/pandaboard-crash.txt Any ARM wizards out there with suggestions? The bug was already reported to Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux-meta-ti-omap4/+bug/1012735 The issue contains a workaround. 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] PandaBoard, Raspberry Pi coming to Buildbot fleet
On Fri, Jan 04, 2013 at 05:06:22AM -0800, Victor Stinner wrote: 2013/1/4 Trent Nelson tr...@snakebite.org: The installation of Ubuntu on the Pandaboard went smoothly. However, it crashes after about an hour. Console output: http://trent.snakebite.net/pandaboard-crash.txt Any ARM wizards out there with suggestions? The bug was already reported to Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux-meta-ti-omap4/+bug/1012735 Ah! Thanks. The issue contains a workaround. [root@manganese/ttypts/0(~)#] echo performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor [root@manganese/ttypts/0(~)#] echo performance /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor Doesn't get more Linuxy than that :P Trent. ___ 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] PandaBoard, Raspberry Pi coming to Buildbot fleet
Le Fri, 4 Jan 2013 08:35:58 -0500, Trent Nelson tr...@snakebite.org a écrit : On Fri, Jan 04, 2013 at 05:06:22AM -0800, Victor Stinner wrote: 2013/1/4 Trent Nelson tr...@snakebite.org: The installation of Ubuntu on the Pandaboard went smoothly. However, it crashes after about an hour. Console output: http://trent.snakebite.net/pandaboard-crash.txt Any ARM wizards out there with suggestions? The bug was already reported to Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux-meta-ti-omap4/+bug/1012735 Ah! Thanks. The issue contains a workaround. [root@manganese/ttypts/0(~)#] echo performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor [root@manganese/ttypts/0(~)#] echo performance /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor Doesn't get more Linuxy than that :P You could probably have written: cpu-freq-set -rg performance Regards 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
[Python-Dev] Please review simple patch for IDLE documentation last updated 11/28/2012
Greetings, I submitted a simple patch for updates to IDLE's documentation http://bugs.python.org/issue5066 and it has not been reviewed by an official Python developer. Since it is now been over 1month since last update can somebody please review and or commit? I did get some comments from another contributor and updated the patch based on those comments. The original bug was opened in 2009 and the IDLE documentation is out of date with undocumented menu options and inconsistencies between the help file and the HTML documentation. I hate to be pushy but I would like to see some progress made on IDLE. Thanks for the support. Sent from my iPad___ 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] Please review simple patch for IDLE documentation last updated 11/28/2012
On Fri, 04 Jan 2013 10:04:14 -0500, Todd V Rovito rovit...@gmail.com wrote: I submitted a simple patch for updates to IDLE's documentation http://bugs.python.org/issue5066 and it has not been reviewed by an official Python developer. Since it is now been over 1month since last update can somebody please review and or commit? I did get some comments from another contributor and updated the patch based on those comments. The original bug was opened in 2009 and the IDLE documentation is out of date with undocumented menu options and inconsistencies between the help file and the HTML documentation. I hate to be pushy but I would like to see some progress made on IDLE. Thanks for the support. IMO it isn't pushy to ask about an issue that seems ready but on which no action has been taken for an extended period. It could be that the nosy committers have just forgotten about it. In the future, it best way to approach this situation (patch that seems ready but no action has been taken) is to ping the issue first, and if you don't get a response after a few days, to post here as you did. --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] Please review simple patch for IDLE documentation last updated 11/28/2012
On Jan 4, 2013, at 10:23 AM, R. David Murray rdmur...@bitdance.com wrote: On Fri, 04 Jan 2013 10:04:14 -0500, Todd V Rovito rovit...@gmail.com wrote: I submitted a simple patch for updates to IDLE's documentation http://bugs.python.org/issue5066 and it has not been reviewed by an official Python developer. Since it is now been over 1month since last update can somebody please review and or commit? I did get some comments from another contributor and updated the patch based on those comments. The original bug was opened in 2009 and the IDLE documentation is out of date with undocumented menu options and inconsistencies between the help file and the HTML documentation. I hate to be pushy but I would like to see some progress made on IDLE. Thanks for the support. IMO it isn't pushy to ask about an issue that seems ready but on which no action has been taken for an extended period. It could be that the nosy committers have just forgotten about it. In the future, it best way to approach this situation (patch that seems ready but no action has been taken) is to ping the issue first, and if you don't get a response after a few days, to post here as you did. Good suggestion I will ping the bug report! FYIthe excellent developer's guide http://docs.python.org/devguide/patch.html#reviewing states Getting your patch reviewed requires a reviewer to have the spare time and motivation to look at your patch (we cannot force anyone to review patches). If your patch has not received any notice from reviewers (i.e., no comment made) after a substantial amount of time then you may email python-dev@python.org asking for someone to take a look at your patch. The Developer's guide does not mention pinging the patch maybe that is common sense so it doesn't need to be documented but I had assumed somebody was watching bugs that had patches applied but no commits. ___ 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] Please review simple patch for IDLE documentation last updated 11/28/2012
On Fri, 04 Jan 2013 10:40:10 -0500, Todd V Rovito rovit...@gmail.com wrote: On Jan 4, 2013, at 10:23 AM, R. David Murray rdmur...@bitdance.com wrote: On Fri, 04 Jan 2013 10:04:14 -0500, Todd V Rovito rovit...@gmail.com wrote: I submitted a simple patch for updates to IDLE's documentation http://bugs.python.org/issue5066 and it has not been reviewed by an official Python developer. Since it is now been over 1month since last update can somebody please review and or commit? I did get some comments from another contributor and updated the patch based on those comments. The original bug was opened in 2009 and the IDLE documentation is out of date with undocumented menu options and inconsistencies between the help file and the HTML documentation. I hate to be pushy but I would like to see some progress made on IDLE. Thanks for the support. IMO it isn't pushy to ask about an issue that seems ready but on which no action has been taken for an extended period. It could be that the nosy committers have just forgotten about it. In the future, it best way to approach this situation (patch that seems ready but no action has been taken) is to ping the issue first, and if you don't get a response after a few days, to post here as you did. Good suggestion I will ping the bug report! FYIthe excellent developer's guide http://docs.python.org/devguide/patch.html#reviewing states Getting your patch reviewed requires a reviewer to have the spare time and motivation to look at your patch (we cannot force anyone to review patches). If your patch has not received any notice from reviewers (i.e., no comment made) after a substantial amount of time then you may email python-dev@python.org asking for someone to take a look at your patch. The Developer's guide does not mention pinging the patch maybe that is common sense so it doesn't need to be documented but I had assumed somebody was watching bugs that had patches applied but no commits. Adding that to the developers guide sounds like a good idea. You could open a new issue in the tracker with that suggestion :). No, we have no automated monitoring of anything in the bug tracker (other than the weekly issues summary). It is all up to whatever some volunteer chooses to spend time doing. If someone *did* want to take on that role, that would be fantastic. (To automate such monitoring we would need some sort of 'commit ready' flag in the tracker and a protocol for when it gets set...which might not be a bad idea, but would need to be discussed) --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] Please review simple patch for IDLE documentation last updated 11/28/2012
On 04.01.13 18:51, R. David Murray wrote: (To automate such monitoring we would need some sort of 'commit ready' flag in the tracker and a protocol for when it gets set...which might not be a bad idea, but would need to be discussed) Is not commit review stage purposed for this? ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-12-28 - 2013-01-04)
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:
open3817 (-17)
closed 24823 (+78)
total 28640 (+61)
Open issues with patches: 1667
Issues opened (44)
==
#8952: Doc/c-api/arg.rst: fix documentation of number formats
http://bugs.python.org/issue8952 reopened by georg.brandl
#16748: Make CPython test package discoverable
http://bugs.python.org/issue16748 reopened by serhiy.storchaka
#16803: Make test_importlib run tests under both _frozen_importlib and
http://bugs.python.org/issue16803 opened by brett.cannon
#16804: python3 -S -m site fails
http://bugs.python.org/issue16804 opened by pitrou
#16805: when building docs on Debian 7 -- ERROR: Error in note dire
http://bugs.python.org/issue16805 opened by tshepang
#16806: col_offset is -1 and lineno is wrong for multiline string expr
http://bugs.python.org/issue16806 opened by carsten.kl...@axn-software.de
#16807: argparse group nesting lost on inheritance
http://bugs.python.org/issue16807 opened by Dougal.Sutherland
#16808: inspect.stack() should return list of named tuples
http://bugs.python.org/issue16808 opened by danielsh
#16809: Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works)
http://bugs.python.org/issue16809 opened by serwy
#16811: email.message.Message flatten dies of list index out of range
http://bugs.python.org/issue16811 opened by HJarausch
#16812: os.symlink can return wrong FileExistsError/WindowsError infor
http://bugs.python.org/issue16812 opened by IAmTheClaw
#16817: test___all__ affects other tests by doing too much importing
http://bugs.python.org/issue16817 opened by eli.bendersky
#16821: bundlebuilder broken in 2.7
http://bugs.python.org/issue16821 opened by barry-scott
#16822: execv (et al.) should invoke atexit handlers before executing
http://bugs.python.org/issue16822 opened by nedbat
#16823: Python crashes on running tkinter code with threads
http://bugs.python.org/issue16823 opened by Sarbjit.singh
#16826: Don't check for PYTHONCASEOK if interpreter started with -E
http://bugs.python.org/issue16826 opened by brett.cannon
#16827: Remove the relatively advanced content from section 2 in tutor
http://bugs.python.org/issue16827 opened by ramchandra.apte
#16829: IDLE on POSIX can't print filenames with spaces
http://bugs.python.org/issue16829 opened by Rod.Nayfield
#16830: Add skip_host and skip_accept_encoding to httplib/http.client
http://bugs.python.org/issue16830 opened by kanzure
#16831: Better docs for ABCMeta.__subclasshook__
http://bugs.python.org/issue16831 opened by ncoghlan
#16832: Expose cache validity checking support in ABCMeta
http://bugs.python.org/issue16832 opened by ncoghlan
#16834: ioctl mutate_flag behavior in regard to the buffer size limit
http://bugs.python.org/issue16834 opened by Yuval.Weinbaum
#16835: Update PEP 399 to allow for test discovery
http://bugs.python.org/issue16835 opened by brett.cannon
#16836: configure script disables support for IPv6 on a system where I
http://bugs.python.org/issue16836 opened by schmir
#16837: Number ABC can be instantiated
http://bugs.python.org/issue16837 opened by belopolsky
#16840: Tkinter doesn't support large integers
http://bugs.python.org/issue16840 opened by serhiy.storchaka
#16842: Allow to override a function signature for pydoc with a docstr
http://bugs.python.org/issue16842 opened by serhiy.storchaka
#16843: sporadic test_sched failure
http://bugs.python.org/issue16843 opened by pitrou
#16845: warnings.simplefilter should validate input
http://bugs.python.org/issue16845 opened by seberg
#16846: relative import solution
http://bugs.python.org/issue16846 opened by Fixpythonbugs
#16848: Mac OS X: python-config --ldflags and location of Python.frame
http://bugs.python.org/issue16848 opened by samueljohn
#16849: Element.{get,iter} doesn't handle keyword arguments when using
http://bugs.python.org/issue16849 opened by kushou
#16850: Atomic open + close-and-exec
http://bugs.python.org/issue16850 opened by haypo
#16851: ismethod and isfunction methods error
http://bugs.python.org/issue16851 opened by wdanilo
#16852: Fix test discovery for test_genericpath.py
http://bugs.python.org/issue16852 opened by zach.ware
#16853: add a Selector to the select module
http://bugs.python.org/issue16853 opened by neologix
#16854: usage() is not defined in Lib/test/regrtest.py
http://bugs.python.org/issue16854 opened by serhiy.storchaka
#16855: traceback module leaves off module name in last line of format
http://bugs.python.org/issue16855 opened by waltermundt
#16858: tarfile silently hides errors
http://bugs.python.org/issue16858 opened by mmarkk
#16859: tarfile.TarInfo.fromtarfile does not check read() return value
http://bugs.python.org/issue16859 opened by mmarkk
#16860: Use O_CLOEXEC in the tempfile module
Re: [Python-Dev] Please review simple patch for IDLE documentation last updated 11/28/2012
On Fri, 04 Jan 2013 18:56:22 +0200, Serhiy Storchaka storch...@gmail.com wrote: On 04.01.13 18:51, R. David Murray wrote: (To automate such monitoring we would need some sort of 'commit ready' flag in the tracker and a protocol for when it gets set...which might not be a bad idea, but would need to be discussed) Is not commit review stage purposed for this? Not currently. But we could potentially re-purpose it for that. Currently it is supposed to mean that we are in an RC stage, one committer has signed off on the patch, and we need a second signoff before committing. I don't think we actually work that way any more now that we have switched to hg. Instead what we have been doing is committing as per normal, and then the release manager's decision on whether or not merge the fix into his release clone takes the place of the second review. --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] Range information in the AST -- once more
2012/12/27 Sven Brauch svenbra...@googlemail.com: 2012/12/27 Guido van Rossum gu...@python.org: So just submit a patch to the tracker... --Guido On Thursday, December 27, 2012, Sven Brauch wrote: 2012/12/27 Nick Coghlan ncogh...@gmail.com: It certainly sounds like its worth considering for 3.4. It's a new feature, though, so it unfortunately wouldn't be possible to backport it to any earlier releases. Yes, that is understandable. It wouldn't be much of a problem tough, my whole project is pretty bleeding-edge anyways, and depending on python = 3.4 wouldn't hurt. For me it would only be important to have an acceptable solution for this long-term. Greetings, Sven ___ 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) I submitted a patch to the tracker, see http://bugs.python.org/issue16795. The patch only contains the very minimum set of changes which are necessary. There's still a few things you'll need to work around when writing a static language analyzer, but none of them is too much work, so I didn't include them for now in order to keep things compact. Thanks and best regards, Sven Ping! Nobody complained since I proposed the patch a week ago, just some people added themselves to the notify list. What do you think? Cheers, Sven ___ 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] Please review simple patch for IDLE documentation last updated 11/28/2012
On Jan 4, 2013, at 11:51 AM, R. David Murray rdmur...@bitdance.com wrote: On Fri, 04 Jan 2013 10:40:10 -0500, Todd V Rovito rovit...@gmail.com wrote: On Jan 4, 2013, at 10:23 AM, R. David Murray rdmur...@bitdance.com wrote: On Fri, 04 Jan 2013 10:04:14 -0500, Todd V Rovito rovit...@gmail.com wrote: I submitted a simple patch for updates to IDLE's documentation http://bugs.python.org/issue5066 and it has not been reviewed by an official Python developer. Since it is now been over 1month since last update can somebody please review and or commit? I did get some comments from another contributor and updated the patch based on those comments. The original bug was opened in 2009 and the IDLE documentation is out of date with undocumented menu options and inconsistencies between the help file and the HTML documentation. I hate to be pushy but I would like to see some progress made on IDLE. Thanks for the support. IMO it isn't pushy to ask about an issue that seems ready but on which no action has been taken for an extended period. It could be that the nosy committers have just forgotten about it. In the future, it best way to approach this situation (patch that seems ready but no action has been taken) is to ping the issue first, and if you don't get a response after a few days, to post here as you did. Good suggestion I will ping the bug report! FYIthe excellent developer's guide http://docs.python.org/devguide/patch.html#reviewing states Getting your patch reviewed requires a reviewer to have the spare time and motivation to look at your patch (we cannot force anyone to review patches). If your patch has not received any notice from reviewers (i.e., no comment made) after a substantial amount of time then you may email python-dev@python.org asking for someone to take a look at your patch. The Developer's guide does not mention pinging the patch maybe that is common sense so it doesn't need to be documented but I had assumed somebody was watching bugs that had patches applied but no commits. Adding that to the developers guide sounds like a good idea. You could open a new issue in the tracker with that suggestion :). Thanks I will add an issue to the tracker and will even submit a patch. ___ 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-ideas] PEP 3156 - Asynchronous IO Support Rebooted
On Fri, Jan 4, 2013 at 2:38 PM, Dustin Mitchell djmit...@gmail.com wrote: As the maintainer of a pretty large, complex app written in Twisted, I think this is great. I look forward to a future of being able to select from a broad library of async tools, and being able to write tools that can be used outside of Twisted. Thanks. Me too. :-) Buildbot began, lo these many years ago, doing a lot of things in memory on on local disk, neither of which require asynchronous IO. So a lot of API methods did not originally return Deferreds. Those methods are then used by other methods, many of which also do not return Deferreds. Now, we want to use a database backend, and parallelize some of the operations, meaning that the methods need to return a Deferred. Unfortunately, that requires a complete tree traversal of all of the methods and methods that call them, rewriting them to take and return Deferreds. There's no halfway solution. This is a little easier with generators (@inlineCallbacks), since the syntax doesn't change much, but it's a significant change to the API (in fact, this is a large part of the reason for the big rewrite for Buildbot-0.9.x). I bring all this up to say, this PEP will introduce a new kind of method signature into standard Python, one which the caller must know, and the use of which changes the signature of the caller. That can cause sweeping changes, and debugging those changes can be tricky. Yes, and this is the biggest unproven point of the PEP. (The rest is all backed by a decade or more of experience.) Two things can help: First, `yield from somemeth()` should work fine even if `somemeth` is not a coroutine function, and authors of async tools should be encouraged to use this form to assist future-compatibility. Second, `somemeth()` without a yield should fail loudly if `somemeth` is a coroutine function. Otherwise, the effects can be pretty confusing. That would be nice. But the way yield from and generators work, that's hard to accomplish without further changes to the language -- and I don't want to have to change the language again (at least not immediately -- maybe in a few releases, after we've learned what the real issues are). The best I can do for the first requirement is to define @coroutine in a way that if the decorated function isn't a generator, it is wrapped in one. For the second requirement, if you call somemeth() and ignore the result, nothing happens at all -- this is indeed infuriating but I see no way to change this.(*) If you use the result, well, Futures have different attributes than most other objects so hopefully you'll get a loud AttributeError or TypeError soon, but of course if you pass it into something else which uses it, it may still be difficult to track. Hopefully these error messages provide a hint: f.foo Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'Future' object has no attribute 'foo' f() Traceback (most recent call last): File stdin, line 1, in module TypeError: 'Future' object is not callable (*) There's a heavy gun we might use, but I would make this optional, as a heavy duty debugging mode only. @coroutine could wrap generators in a lightweight object with a __del__ method and an __iter__ method. If __del__ is called before __iter__ is ever called, it could raise an exception or log a warning. But this probably adds too much overhead to have it always enabled. In http://code.google.com/p/uthreads, I accomplished the latter by taking advantage of garbage collection: if the generator is garbage collected before it's begun, then it's probably not been yielded. This is a bit gross, but good enough as a debugging technique. Eh, yeah, what I said. :-) On the topic of debugging, I also took pains to make sure that tracebacks looked reasonable, filtering out scheduler code[1]. I haven't looked closely at Tulip to see if that's a problem. Most of the noise in the tracebacks came from the lack of 'yield from', so it may not be an issue at all. One of the great advantages of using yield from is that the tracebacks automatically look nice. Dustin [1] http://code.google.com/p/uthreads/source/browse/trunk/uthreads/core.py#253 -- --Guido van Rossum (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] [Python-ideas] PEP 3156 - Asynchronous IO Support Rebooted
As the maintainer of a pretty large, complex app written in Twisted, I think this is great. I look forward to a future of being able to select from a broad library of async tools, and being able to write tools that can be used outside of Twisted. Buildbot began, lo these many years ago, doing a lot of things in memory on on local disk, neither of which require asynchronous IO. So a lot of API methods did not originally return Deferreds. Those methods are then used by other methods, many of which also do not return Deferreds. Now, we want to use a database backend, and parallelize some of the operations, meaning that the methods need to return a Deferred. Unfortunately, that requires a complete tree traversal of all of the methods and methods that call them, rewriting them to take and return Deferreds. There's no halfway solution. This is a little easier with generators (@inlineCallbacks), since the syntax doesn't change much, but it's a significant change to the API (in fact, this is a large part of the reason for the big rewrite for Buildbot-0.9.x). I bring all this up to say, this PEP will introduce a new kind of method signature into standard Python, one which the caller must know, and the use of which changes the signature of the caller. That can cause sweeping changes, and debugging those changes can be tricky. Two things can help: First, `yield from somemeth()` should work fine even if `somemeth` is not a coroutine function, and authors of async tools should be encouraged to use this form to assist future-compatibility. Second, `somemeth()` without a yield should fail loudly if `somemeth` is a coroutine function. Otherwise, the effects can be pretty confusing. In http://code.google.com/p/uthreads, I accomplished the latter by taking advantage of garbage collection: if the generator is garbage collected before it's begun, then it's probably not been yielded. This is a bit gross, but good enough as a debugging technique. On the topic of debugging, I also took pains to make sure that tracebacks looked reasonable, filtering out scheduler code[1]. I haven't looked closely at Tulip to see if that's a problem. Most of the noise in the tracebacks came from the lack of 'yield from', so it may not be an issue at all. Dustin [1] http://code.google.com/p/uthreads/source/browse/trunk/uthreads/core.py#253 ___ 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] test failed: test_urlwithfrag
Dear python team,I never used python before and installed it today the first time, so I have no idea what to do about this failure: ./python -m test -v test_urlwithfrag== CPython 3.3.0 (default, Jan 4 2013, 23:08:00) [GCC 4.6.3]== Linux-3.2.0-35-generic-pae-i686-with-debian-wheezy-sid little-endian== /home/me/Programme/Python/Python-3.3.0/build/test_python_30744Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)[1/1] test_urlwithfragtest test_urlwithfrag crashed -- Traceback (most recent call last): File /home/me/Programme/Python/Python-3.3.0/Lib/test/regrtest.py, line 1213, in runtest_inner the_package = __import__(abstest, globals(), locals(), [])ImportError: No module named test.test_urlwithfrag1 test failed: test_urlwithfragIf you need more information, please tell me. It would be very great if you could help me. Thank you in advance.Elli Meisner ___ 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] More compact dictionaries with faster iteration
On Thu, 3 Jan 2013 12:22:27 +0200 Maciej Fijalkowski fij...@gmail.com wrote: Hello everyone. Thanks raymond for writing down a pure python version ;-) I did an initial port to RPython for experiments. The results (on large dicts only) are inconclusive - it's either a bit faster or a bit slower, depending what exactly you do. There is a possibility I messed something up too (there is a branch rdict-experiments in PyPy, in a very sorry state though). But what about the memory consumption? This seems to be the main point of Raymond's proposal. Regards 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] PEP 3156 - Asynchronous IO Support Rebooted
On Mon, Dec 24, 2012 at 2:58 PM, Glyph gl...@twistedmatrix.com wrote:
In my humble (but entirely, verifiably correct) opinion, thinking of this as
a default is propagating a design error in the BSD sockets API. Datagram
and stream sockets have radically different semantics. In Twisted,
dataReceived and datagramReceived are different methods for a good
reason. Again, it's very very easy to fall into the trap of thinking that a
TCP segment is a datagram and writing all your application code as if it
were. After all, it probably works over localhost most of the time! This
difference in semantics mirrored by a difference in method naming has helped
quite a few people grok the distinction between streaming and datagrams over
the years; I think it would be a good idea if Tulip followed suit.
Suppose PEP 3156 / Tulip uses data_received() for streams and
datagram_received() for datagram protocols (which seems reasonable
enough), what API should a datagram transport have for sending
datagrams? write_datagram() and write_datagram_list()?
(Given that the transport and protocol classes are different for
datagrams, I suppose the create*() methods should also be different,
rather than just having a type={SOCK_STREAM,SOCK_DATAGRAM} flag. But I
can figure that out for myself. The naming and exact APIs for the
client and server transport creation methods are in flux anyway.)
--
--Guido van Rossum (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] test failed: test_urlwithfrag
On 1/4/2013 5:59 PM, Elli Lola wrote: Dear python team, I never used python before and installed it today the first time, so I have no idea what to do about this failure: This current-version usage question should have been directed to python-list. pydev is only for discussion of future versions. (And if you are in doubt, start with python-list.) However, $ ./python -m test -v test_urlwithfrag There is no such module in the test package. Hence ImportError: No module named 'test.test_urlwithfrag' Believe error messages. Look in Lib/test/test_* for the test modules you can run. I tried (interactively, much easier on windows) import test.test_urllib as t; t.test_main() import test.test_urllib_response as t; t.test_main() import test.test_urllib2 as t; t.test_main() and they all work. The other test_urllib* modules are test_urllibnet test_urllib2net test_urllib2_localnet If you get a failure from actually running a test, post on python-list, with the headers you did post here, and ask if it seems to be a problem with your build or python itself. You can also check the tracker to see if it is an already known failure. python-list people are generally very helpful with this sort of thing. -- 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] test failed: test_urlwithfrag
Yes, this is question is for python-li...@python.org On Fri, Jan 4, 2013 at 2:59 PM, Elli Lola lampenregensch...@web.de wrote: $ ./python -m test -v test_urlwithfrag Where did you get this command from? It looks to me to me that more than one person is trying the exact same command experiencing the same failure (expected result). Perhaps the source which is advertising this is misleading? Thanks, Senthil ___ 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] PEP 3156 - Asynchronous IO Support Rebooted
On Fri, Jan 4, 2013 at 8:19 PM, Glyph gl...@twistedmatrix.com wrote: On Jan 4, 2013, at 3:56 PM, Guido van Rossum gu...@python.org wrote: On Mon, Dec 24, 2012 at 2:58 PM, Glyph gl...@twistedmatrix.com wrote: In my humble (but entirely, verifiably correct) opinion, thinking of this as a default is propagating a design error in the BSD sockets API. Datagram and stream sockets have radically different semantics. In Twisted, dataReceived and datagramReceived are different methods for a good reason. Again, it's very very easy to fall into the trap of thinking that a TCP segment is a datagram and writing all your application code as if it were. After all, it probably works over localhost most of the time! This difference in semantics mirrored by a difference in method naming has helped quite a few people grok the distinction between streaming and datagrams over the years; I think it would be a good idea if Tulip followed suit. Suppose PEP 3156 / Tulip uses data_received() for streams and datagram_received() for datagram protocols (which seems reasonable enough), what API should a datagram transport have for sending datagrams? write_datagram() and write_datagram_list()? Twisted just have a different method called write() which has a different signature (data, address). Probably write_datagram is better. Why write_datagram_list though? Twisted's writeSequence is there to provide the (eventual) opportunity to optimize by writev; since datagrams are always sent one at a time anyway, write_datagram_list would seem to be a very minor optimization. That makes sense (you can see I haven't tried to use UDP in a long time :-). Should write_datagram() perhaps return a future? Or is there still a use case for buffering datagrams? -- --Guido van Rossum (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] PEP 3156 - Asynchronous IO Support Rebooted
On Jan 4, 2013, at 8:51 PM, Guido van Rossum gu...@python.org wrote: On Fri, Jan 4, 2013 at 8:19 PM, Glyph gl...@twistedmatrix.com wrote: On Jan 4, 2013, at 3:56 PM, Guido van Rossum gu...@python.org wrote: On Mon, Dec 24, 2012 at 2:58 PM, Glyph gl...@twistedmatrix.com wrote: In my humble (but entirely, verifiably correct) opinion, thinking of this as a default is propagating a design error in the BSD sockets API. Datagram and stream sockets have radically different semantics. In Twisted, dataReceived and datagramReceived are different methods for a good reason. Again, it's very very easy to fall into the trap of thinking that a TCP segment is a datagram and writing all your application code as if it were. After all, it probably works over localhost most of the time! This difference in semantics mirrored by a difference in method naming has helped quite a few people grok the distinction between streaming and datagrams over the years; I think it would be a good idea if Tulip followed suit. Suppose PEP 3156 / Tulip uses data_received() for streams and datagram_received() for datagram protocols (which seems reasonable enough), what API should a datagram transport have for sending datagrams? write_datagram() and write_datagram_list()? Twisted just have a different method called write() which has a different signature (data, address). Probably write_datagram is better. Why write_datagram_list though? Twisted's writeSequence is there to provide the (eventual) opportunity to optimize by writev; since datagrams are always sent one at a time anyway, write_datagram_list would seem to be a very minor optimization. That makes sense (you can see I haven't tried to use UDP in a long time :-). Should write_datagram() perhaps return a future? Or is there still a use case for buffering datagrams? There's not much value in returning a future even if you don't buffer. UDP packets can be dropped, and there's no acknowledgement from the remote end either when they're received or when they're dropped. You can get a couple hints from ICMP, but you can't rely on it, because lots of networks just dumbly filter it. Personally I think its flow control should work the same way as a TCP stream just for symmetry, but the only time that this becomes important in an application is when you're actually saturating your entire outbound network, and you need to notice and slow down. Returning a future would let you do this too, but might mislead users into thinking that once write_datagram completes, the datagram is sent and the other side has it, which is another pernicious idea it's hard to disabuse people of. -glyph ___ 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
