Mailman 3 December 2010 - docs

[issue8040] It would be nice if documentation pages linked to other versions of the same document
by Michael Buckley Dec. 15, 2010

Dec. 15, 2010

Michael Buckley <newsletters(a)codefisher.org> added the comment: You might want to check out what Django does, as they have the working well. http://docs.djangoproject.com/en/dev/ ---------- nosy: +codefisher _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8040> _______________________________________

1 0

[issue10705] HTTPConnection.set_debuglevel has no information about level range
by J_Tom_Moon_79 Dec. 15, 2010

Dec. 15, 2010

New submission from J_Tom_Moon_79 <jtm.moon.forum.user+python(a)gmail.com>: Function HTTPConnection.set_debuglevel(level) There is no range of acceptable debug levels. What should be the difference in set_debuglevel(1) and set_debuglevel(1000)? If the documentation lists the levels this would save users from needing to do tedious trial-error experimentation. From http://docs.python.org/py3k/library/http.client.html#http.client.HTTPConnec… ---------- assignee: docs@python components: Documentation messages: 123974 nosy: JTMoon79, docs@python priority: normal severity: normal status: open title: HTTPConnection.set_debuglevel has no information about level range versions: Python 3.1 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10705> _______________________________________

2 5

[issue8040] It would be nice if documentation pages linked to other versions of the same document
by Daniel Stutzbach Dec. 14, 2010

Dec. 14, 2010

Changes by Daniel Stutzbach <stutzbach(a)google.com>: ---------- versions: -Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8040> _______________________________________

1 0

[issue6696] Profile objects should be documented
by R. David Murray Dec. 14, 2010

Dec. 14, 2010

Changes by R. David Murray <rdmurray(a)bitdance.com>: ---------- stage: -> needs patch type: -> behavior versions: +Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6696> _______________________________________

1 0

[issue10699] [patch] fix incorrect help doc with time.tzset
by Garrett Cooper Dec. 14, 2010

Dec. 14, 2010

New submission from Garrett Cooper <yanegomi(a)gmail.com>: The following patch fixes the help docstring as time.tzset when called doesn't require any arguments (as noted in the source and also in the library documentation). The patch produced was against trunk, but this appears to be an issue on release-maint26 and release-maint27 (and the patch applies cleanly) as the text is the same. ---------- assignee: docs@python components: Documentation files: fix-timemodule-helpdoc.patch keywords: patch messages: 123908 nosy: docs@python, yaneurabeya priority: normal severity: normal status: open title: [patch] fix incorrect help doc with time.tzset versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20033/fix-timemodule-helpdoc.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10699> _______________________________________

2 2

[issue10698] doctest load_tests() typo
by Andrew Dalke Dec. 13, 2010

Dec. 13, 2010

New submission from Andrew Dalke <dalke(a)dalkescientific.com>: doctest.html Section 24.2.5 "Unittest API" says: def load_tests(loader, tests, ignore): tests.addTests(doctest.DocTestSuite(my_module_with_doctests)) return test That last line should be "return tests" ---------- assignee: docs@python components: Documentation messages: 123904 nosy: dalke, docs@python priority: normal severity: normal status: open title: doctest load_tests() typo versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10698> _______________________________________

2 1

[issue10697] host and port attributes not documented well in function urllib.parse.urlparse and urlsplit
by JTMoon79 Dec. 13, 2010

Dec. 13, 2010

JTMoon79 <jtm.moon.forum.user+python(a)gmail.com> added the comment: Doh! I feel a bit silly. I didn't notice 'hostname' and 'port' in >>> dir(urllib.parse.urlparse(r'http://foo.bar.com:80/blarg?a=1&b=2')) [... 'count', 'fragment', 'geturl', 'hostname', 'index' , 'netloc', 'params', 'password', 'path', 'port', 'query', 'scheme', 'username'] I agree, some clarity in the documentation for these overlapping fields (<net_loc>,<port>,<hostname>) would help. -J_Tom_Moon_79 ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10697> _______________________________________

1 0

[issue10697] host and port attributes not documented well in function urllib.parse.urlparse and urlsplit
by Fred L. Drake, Jr. Dec. 13, 2010

Dec. 13, 2010

Changes by Fred L. Drake, Jr. <fdrake(a)acm.org>: ---------- versions: +Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10697> _______________________________________

1 0

[issue10697] host and port attributes not documented well in function urllib.parse.urlparse and urlsplit
by R. David Murray Dec. 13, 2010

Dec. 13, 2010

R. David Murray <rdmurray(a)bitdance.com> added the comment: The repr gives the primary components defined by the URL. The subfields are provided as attributes of the result. This is documented in the example at the top of the chapter, but it is not, IMO, well documented in the rest of the chapter. I'm not sure when this feature was introduced, so I'm leaving 3.1 in the versions for now. ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python, orsenthil, r.david.murray stage: -> needs patch title: port not split in function urllib.parse.urlparse -> host and port attributes not documented well in function urllib.parse.urlparse and urlsplit versions: +Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10697> _______________________________________

2 1

multiprocessing 'bug'
by Alex Leach Dec. 13, 2010

Dec. 13, 2010

Dear Python developers, I've been using the multiprocessing module for a month or two now and I love the speed improvements that come with it. However I find it quite hard to optimise memory usage amongst the processes. I've tried to avoid using the 'shared state' as much as possible, but every time I start a new process everything in the parent process's global memory gets duplicated for the child process, which is totally unnecessary (for me). I understand that this comes as a side-effect of using os.fork(), which I was totally unaware of until I read quite a nice article on the IBM website. When I first started using the multiprocessing module, I would start a process every time I needed to, which was inside the innermost loop. I later realised this is completely inefficient because of the time penalties associated with process creation, and the fact that my program accumulates data as it runs, so each time a new mult...Process() is started in this manner, it'll always use slightly more memory than the previous process; i.e. exactly as much memory as the parent process currently has. This still gave a remarkable performance improvement on just a single-thread. So now I initiate all the Processes as close to the start of the main program as possible. Still, the processes use a lot more memory than they require, and I'd just rather they didn't... This program I'm currently working on uses the parent process to create a list of worker Processes, as well as a separate mult...Process instance I use as a kind of database; it's the only part of the program that I allow to read from a >20GB text file, sending chunks from that via a mult..Pipe() to the main process and then down to one of the workers. I can't figure out which processes to start first though... Whichever process(es) is/are created first get copied into the global memory of the other process(es), which isn't ideal. As I currently subclass multiprocessing.Process, would it be advisable to add a section to the __init__ function to delete all of the global variables? Before I figured out why all the processes were using all this memory, I spent ages minimising the child processes' need for data needed by the parent process, ensuring any info that the children do need would be passed over in a pipe or queue. Deleting stuff from global memory doesn't seem like a recommendable way of doing things, as doesn't stop the memory duplication in the first place, and could be quite dangerous if I'm deleting subclasses of Process I've given __del__ functions to ensure that all pipes and queues get closed (this worked around an earlier problem of having too many open file handles). I guess the problem is that I've got nearly every function, class & Process written into the same .py file; using subprocess would get around this memory duplication problem, but that would require a lot of painstaking back-tracking and creating a load of extra .py files. But I also need to pass dictionaries around, so that wouldn't even work with the subprocess pipes. I'm using python v2.6.6 btw, on Ubuntu 10.10 server with KDE. Any advice with this would be greatly appreciated! And sorry about the lengthy email! Thanks for any help, and kind regards, Alex Leach

1 0