Mailman 3 January 2011 - docs

[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
by Brian Curtin 17 Jan '11

17 Jan '11

Changes by Brian Curtin <curtin(a)acm.org>: ---------- type: crash -> behavior _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10921> _______________________________________

1 0

[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
by Joe Peterson 17 Jan '11

17 Jan '11

Changes by Joe Peterson <joe(a)skyrush.com>: ---------- components: +Documentation _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10921> _______________________________________

1 0

[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
by Joe Peterson 17 Jan '11

17 Jan '11

Changes by Joe Peterson <joe(a)skyrush.com>: ---------- components: -Documentation _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10921> _______________________________________

1 0

[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
by Joe Peterson 17 Jan '11

17 Jan '11

Changes by Joe Peterson <joe(a)skyrush.com>: Removed file: http://bugs.python.org/file20419/imaplib_Internaldate2tuple.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10921> _______________________________________

1 0

[issue10921] imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly
by Joe Peterson 17 Jan '11

17 Jan '11

Joe Peterson <joe(a)skyrush.com> added the comment: Regarding problem #4, it actually appears that returning local time is the right thing to do, since it matches the behavior of Time2Internaldate(). Returning UTC, as the doc states, would potentially break IMAP append() that can include an internaldate possibly returned from Internaldate2tuple() in typical usage (like when copying messages). In this case, the doc is wrong on Internaldate2tuple(). I have attached a new patch to both the code and doc that replaces the old patch. I now return localtime rather than gmtime, but other than that, the DST fix remains the same and now handles the cases near DST changes correctly. Ultimately, it might be desirable to be able always stay in UTC, so perhaps adding UTC variants of both Internaldate2tuple() and Time2Internaldate() (and a UTC option to append()) would be a good enhancement for later. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python title: imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly, and outputs localtime (not UTC) -> imaplib: Internaldate2tuple() crashes, does not handle negative TZ offsets, does not handle DST correctly Added file: http://bugs.python.org/file20420/imaplib_Internaldate2tuple.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10921> _______________________________________

1 0

[issue10917] PEP 333 link to CGI specification is broken
by anatoly techtonik 16 Jan '11

16 Jan '11

New submission from anatoly techtonik <techtonik(a)gmail.com>: http://www.python.org/dev/peps/pep-0333/#id7 Link to CGI spec is broken. ---------- assignee: docs@python components: Documentation messages: 126361 nosy: docs@python, techtonik priority: normal severity: normal status: open title: PEP 333 link to CGI specification is broken versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10917> _______________________________________

3 7

Section 2.1.2 tutorial question
by Will Flanagan 14 Jan '11

14 Jan '11

Hi, I am reading the second page of your tutorial: http://docs.python.org/tutorial/interpreter.html When we arrive at this example in section 2.1.2, it is not clear how to get to the secondary prompt: >>> the_world_is_flat = 1 >>> if the_world_is_flat: ... print "Be careful not to fall off!" ... Be careful not to fall off! If I type "if the_world_is_flat:" and hit enter, an error is generated. How do I get to the secondary prompt for the next line of the example? I am this doing this tutorial with a bash shell. Many thanks in advance, Will

2 2

[issue6771] Curses.wrapper: documentation/implementation error
by Radiant 14 Jan '11

14 Jan '11

Radiant <abbconsulting(a)gmail.com> added the comment: Adding version=3.2 and component=Documentation. ---------- assignee: -> docs@python components: +Documentation nosy: +Radiant, docs@python versions: +Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6771> _______________________________________

1 0

[issue10904] PYTHONIOENCODING is not in manpage
by Peter Kleiweg 14 Jan '11

14 Jan '11

New submission from Peter Kleiweg <pkleiweg(a)xs4all.nl>: The environment variable PYTHONIOENCODING should be documented in de manpage ---------- assignee: docs@python components: Documentation, IO messages: 126252 nosy: docs@python, pebbe priority: normal severity: normal status: open title: PYTHONIOENCODING is not in manpage versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10904> _______________________________________

2 3

two spaces after a period
by Eli Bendersky 14 Jan '11

14 Jan '11

An interesting article that was posted on Hacker News today: http://www.slate.com/id/2281146/pagenum/all/ Inside it links to a Q&A of the esteemed Chicago Manual of Style: http://www.chicagomanualofstyle.org/CMS_FAQ/OneSpaceorTwo/OneSpaceorTwo03.h… Looks relevant to the way our .rst files are usually written :-) Eli

3 2