Mailman 3 August 2012 - docs

[issue10529] Write argparse i18n howto
by Éric Araujo 08 Nov '20

08 Nov '20

New submission from Éric Araujo <merwok(a)netwok.org>: argparse helpfully makes its messages with gettext.gettext. The docs should explain how to benefit from that in one’s program. ---------- assignee: docs@python components: Documentation messages: 122358 nosy: bethard, docs@python, eric.araujo priority: normal severity: normal stage: needs patch status: open title: Write argparse i18n howto type: feature request versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10529> _______________________________________

5 5

[issue14003] __self__ on built-in functions is not as documented
by Роман Донченко 08 Nov '20

08 Nov '20

New submission from Роман Донченко <DXDragon(a)yandex.ru>: The language reference says this in section 3.2: ~ Built-in functions A built-in function object is a wrapper around a C function. Examples of built-in functions are len() and math.sin() <...> Special read-only attributes: <...> __self__ is set to None (but see the next item) <...>. ~ That is not the case: ActivePython 3.2.2.3 (ActiveState Software Inc.) based on Python 3.2.2 (default, Sep 8 2011, 10:55:13) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> len.__self__ <module 'builtins' (built-in)> >>> open.__self__ <module 'io' (built-in)> >>> import math >>> math.sin.__self__ <module 'math' (built-in)> ---------- assignee: docs@python components: Documentation messages: 153287 nosy: SpecLad, docs@python priority: normal severity: normal status: open title: __self__ on built-in functions is not as documented type: behavior versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14003> _______________________________________

12 12

[issue15693] expose glossary link on hover
by Chris Jerdonek 07 Nov '20

07 Nov '20

New submission from Chris Jerdonek: It would be nice if hovering over the right side of the header to a glossary entry would expose a link in the same way that it does for function definitions, etc. http://docs.python.org/dev/glossary.html#glossary Otherwise, there doesn't seem to be a convenient way to get a direct link to a glossary entry. I'm not sure if this issue should also be filed with Sphinx. ---------- assignee: docs@python components: Documentation messages: 168388 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: expose glossary link on hover type: enhancement versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15693> _______________________________________

7 15

[issue11176] give more meaningful argument names in argparse documentation
by Steven Bethard 07 Nov '20

07 Nov '20

New submission from Steven Bethard <steven.bethard(a)gmail.com>: Suggestion from a personal email: I personally am not keen on the foo/bar/baz examples. I know that you're trying to be generic but IMO it would be much easier to understand if you used meaningful names. Also, I think that the very first example you give (which does use meaningful names:-) is too clever. I'd suggest using something simpler: in fact I'd use exactly the same example that optparse uses (--file && --quiet) since that is easy to understand and relate to straight away, and maybe add a --line option that takes a list of ints (ostensibly line numbers of lines to extract from the file) if you want to show that argparse leaves optparse in the dust. And you can always show how to get actual file objects later on. ---------- assignee: docs@python components: Documentation messages: 128302 nosy: bethard, docs@python priority: normal severity: normal stage: needs patch status: open title: give more meaningful argument names in argparse documentation type: feature request versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11176> _______________________________________

13 23

[issue12436] Provide reference to detailed installation instructions
by Nick Coghlan 07 Nov '20

07 Nov '20

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: The Boston Python Workshop folks have some detailed step-by-step instructions on getting Python up and running ([1]). Given that this can be a pain point for new users (primarily on Windows), it may be good to reference these instructions from the official docs. (Alternatively, we could use them as the basis for a "HOWTO" in the official docs and update release.py to adjust the relevant links. That's a lot more work than just adding a link, though) [1] http://openhatch.org/wiki/Boston_Python_Workshop_3/Friday ---------- assignee: docs@python components: Documentation messages: 139381 nosy: docs@python, ncoghlan priority: normal severity: normal status: open title: Provide reference to detailed installation instructions _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12436> _______________________________________

10 28

[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2
by Sven Marnach 06 Nov '20

06 Nov '20

New submission from Sven Marnach <sven(a)marnach.net>: The sidebar on http://docs.python.org/release/3.1.3/ names 3.2 as the development version of Python, while the link points to 3.3. The sidebar on http://docs.python.org/py3k/ links to 3.1 as the "stable version" -- obviously a relict from the time when 3.2 was in development. (This could be fixed in Doc/tools/sphinxext/indexsidebar.html of the respective branches.) ---------- assignee: docs@python components: Documentation messages: 145084 nosy: docs@python, smarnach priority: normal severity: normal status: open title: Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2 versions: Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13122> _______________________________________

8 13

[issue11346] Generator object should be mentioned in gc module document
by Atsuo Ishimoto 06 Nov '20

06 Nov '20

New submission from Atsuo Ishimoto <ishimoto(a)gembook.org>: In the gc.garbage of the library ref of gc module, ... this list contains only objects with __del__() methods. This is not true, since gc.garbage will contain generator object with try-finally block. ---------- assignee: docs@python components: Documentation messages: 129631 nosy: docs@python, ishimoto priority: normal severity: normal status: open title: Generator object should be mentioned in gc module document _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11346> _______________________________________

4 4

[issue14379] Several traceback docs improvements
by anatoly techtonik 05 Nov '20

05 Nov '20

New submission from anatoly techtonik <techtonik(a)gmail.com>: Some notes about current `traceback` documentation: http://docs.python.org/library/traceback.html 1. It needs a mentioning that traceback module works with traceback objects and frame objects 2. Functions that work with frames should probably be grouped together 3. Docs for frame function should include info about where to get frames (e.g. http://docs.python.org/library/inspect.html#the-interpreter-stack) 4. There is no traceback object description, which should be at http://docs.python.org/library/sys.html#sys.exc_info ---------- assignee: docs@python components: Documentation messages: 156486 nosy: docs@python, techtonik priority: normal severity: normal status: open title: Several traceback docs improvements _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14379> _______________________________________

4 4

[issue9499] Python C/API Execution namespace undocumented. (patch included)
by Campbell Barton 02 Nov '20

02 Nov '20

New submission from Campbell Barton <ideasman42(a)gmail.com>: Some parts of the python api expect __main__ module dictionary to be the namespace when executing a script, this is true when running a python script from the python binary but NOT true when running a compiled script from the C/API which can lead to bugs which are not easy to solve unless the C/API author knows this. ---------- assignee: docs@python components: Documentation files: doc_py3_main_mod.diff keywords: patch messages: 112706 nosy: docs@python, ideasman42 priority: normal severity: normal status: open title: Python C/API Execution namespace undocumented. (patch included) type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file18357/doc_py3_main_mod.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue9499> _______________________________________

3 4

[issue14219] start the Class tutorial in a more gentle manner
by Tshepang Lekhonkhobe 01 Nov '20

01 Nov '20

New submission from Tshepang Lekhonkhobe <tshepang(a)gmail.com>: Looking at Doc/tutorial/classes, the section "Python Scopes and Namespaces" is full of heavy/deep information. I expect that people who would be able to properly digest that info are people who are already advanced at Python, and therefore maybe it should be moved to some cookbook (or language reference). I would prefer something gentler, since the tutorial is for Python newbies who aren't necessarily conversant with OO concepts. There can of course be links to heavier material for deeper understanding. ---------- assignee: docs@python components: Documentation messages: 155065 nosy: docs@python, tshepang priority: normal severity: normal status: open title: start the Class tutorial in a more gentle manner type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14219> _______________________________________

4 5