Mailman 3 November 2011 - docs

[issue11261] urlopen breaks when data parameter is used.
by Ezio Melotti Nov. 15, 2011

Nov. 15, 2011

Changes by Ezio Melotti <ezio.melotti(a)gmail.com>: ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11261> _______________________________________

1 0

[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
by Terry J. Reedy Nov. 14, 2011

Nov. 14, 2011

Terry J. Reedy <tjreedy(a)udel.edu> added the comment: I agree with Eric both as to placement (first paragraph) and wording (with explanation). I don't have time to review otherwise at the moment. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13249> _______________________________________

1 0

[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
by Roy Smith Nov. 14, 2011

Nov. 14, 2011

Roy Smith <roy(a)panix.com> added the comment: Before I build another patch, would you be OK with leaving it as a note, but adding the "due to the number of arguments" language? There's a lot of text here, and people tend to just zoom in on the bits and pieces they need right now. I think there is value in making this stand out as a note. If you feel strongly this should not be a note, let me know and I'll change it. ---------- _______________________________________ Python tracker … [View More]

1 0

[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
by Éric Araujo Nov. 14, 2011

Nov. 14, 2011

Éric Araujo <merwok(a)netwok.org> added the comment: I would not use a note directive. Notes and warnings distract and sometimes scare readers. For a simple coding recommendation like this, I think a regular paragraph would suffice. To make sure it’s not lost after pages of options description, maybe it could be put right after the signature? Also, it would be nice to explicit the why of this recommendation (e.g. “due to the number of arguments, it is recommended to always use … [View More]

1 0

[issue13239] Remove <> operator from Grammar/Grammar
by Eli Bendersky Nov. 14, 2011

Nov. 14, 2011

New submission from Eli Bendersky <eliben(a)gmail.com>: Operator <> was removed in Python 3, but still appears in Grammar/Grammar (and hence in Doc/reference/grammar.rst) Reported by Alexander Ivanyuta on the docs mailing list ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 146070 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: Remove <> operator from Grammar/Grammar versions: Python 3.2, Python 3.… [View More]

8 16

[issue12875] backport re.compile flags default value documentation
by Eli Bendersky Nov. 13, 2011

Nov. 13, 2011

New submission from Eli Bendersky <eliben(a)gmail.com>: In the 2.7 docs, re.compile has this signature: re.compile(pattern[, flags]) >From here it isn't clear what the default value of 'flags' is, to be able to write code like this: re.compile(pattern, re.I if options['ignore_case'] else <WHAT??>) Of course, looking at the source shows immediately that the default flag value is 0 (which is kind-of implied by the flags being a bit-OR of flags, but not mentioned explicitly)… [View More]

7 21

[issue13387] suggest assertIs(type(obj), cls) for exact type checking
by Florent Xicluna Nov. 12, 2011

Nov. 12, 2011

Florent Xicluna <florent.xicluna(a)gmail.com> added the comment: > +1 on a doc addition (I can even volunteer a patch) I agree we can highlight the difference between assertIs(type(obj), cls) and assertIsInstance(obj, cls) in the documentation. Let's forget this patch and keep it simple. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python stage: -> needs patch title: add exact_type argument to assertIsInstance -> suggest assertIs(type(obj), … [View More]

1 0

[issue12767] document threading.Condition.notify
by Eli Bendersky Nov. 12, 2011

Nov. 12, 2011

New submission from Eli Bendersky <eliben(a)gmail.com>: User report (Jiachang Xu) from the docs mailing list: The theading.Condition.notify method has a parameter - n, which isn't documented in the the documentation of the threading module. 1. The parameter should be documented 2. notify() is mentioned multiple times in the docs of threading - perhaps the parameter should be mentioned in more than one place as well 3. The parameter should also be documented in the doc-string of notify … [View More]

6 12

[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
by Roy Smith Nov. 12, 2011

Nov. 12, 2011

Roy Smith <roy(a)panix.com> added the comment: New patch uploaded. The added recommendation is around line 161 (look for 'Recommended usage is to only use keyword arguments') ---------- Added file: http://bugs.python.org/file23667/Issue13249-2.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13249> _______________________________________

1 0

[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
by Éric Araujo Nov. 12, 2011

Nov. 12, 2011

Éric Araujo <merwok(a)netwok.org> added the comment: Thanks, I’ve made some comments on Rietveld. > Added a recommendation to only use keywords, which seems sane given > the number of arguments. I looked for that but couldn’t find it. ---------- nosy: +eric.araujo _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13249> _______________________________________

1 0