Mailman 3 November 2018 - docs

[issue15034] tutorial should use best practices in user defined execeptions section
by R. David Murray 11 Nov '20

11 Nov '20

New submission from R. David Murray <rdmurray(a)bitdance.com>: And I wish I knew what those were. ---------- assignee: docs@python components: Documentation messages: 162513 nosy: docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: tutorial should use best practices in user defined execeptions section type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15034> _______________________________________

11 16

[issue34365] datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses"
by Kevin Norris 10 Nov '20

10 Nov '20

New submission from Kevin Norris <nykevin.norris(a)gmail.com>: The 3.x datetime documentation contains the following footnote: > In other words, date1 < date2 if and only if date1.toordinal() < date2.toordinal(). In order to stop comparison from falling back to the default scheme of comparing object addresses, date comparison normally raises TypeError if the other comparand isn’t also a date object. However, NotImplemented is returned instead if the other comparand has a timetuple() attribute. This hook gives other kinds of date objects a chance at implementing mixed-type comparison. If not, when a date object is compared to an object of a different type, TypeError is raised unless the comparison is == or !=. The latter cases return False or True, respectively. But in 3.x, comparison no longer falls back to comparing object addresses. Also, some of the comments on issue 8005 seem to suggest that this footnote is not actually true in 3.x (aside from the first sentence, of course). But regardless, the footnote should not refer to a long dead interpreter behavior as if it were still around. ---------- assignee: docs@python components: Documentation messages: 323314 nosy: Kevin.Norris, docs@python priority: normal severity: normal status: open title: datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses" versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34365> _______________________________________

7 12

[issue25006] List pybind11 binding generator
by Wenzel Jakob 08 Nov '20

08 Nov '20

New submission from Wenzel Jakob: Hi, over the last few months, I've been developing a library ("pybind11") for creating Python bindings of C++ code. It is similar in spirit to Boost.Python but uses a very different minimalist approach. It would be fantastic to get this library listed here: https://docs.python.org/3/faq/extending.html The purpose of this ticket is that somebody with permissions might add it to this page. pybind11 is here: https://github.com/wjakob/pybind11 Please let me know if you need any additional information. Thank you, Wenzel ---------- assignee: docs@python components: Documentation messages: 249865 nosy: docs@python, wenzel priority: normal severity: normal status: open title: List pybind11 binding generator type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25006> _______________________________________

3 6

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

07 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 Роман Донченко 07 Nov '20

07 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

[issue25821] Documentation for threading.enumerate / threading.Thread.is_alive is contradictory.
by Anthony Green 07 Nov '20

07 Nov '20

New submission from Anthony Green: The documentation at https://docs.python.org/3/library/threading.html#threading.Thread.is_alive relates: > The module function enumerate() returns a list of all alive threads. The documentation at https://docs.python.org/3/library/threading.html#threading.enumerate relates: > Return a list of all Thread objects currently alive. The list includes daemonic threads, dummy thread objects created by current_thread(), and the main thread. This is a contradiction, since if the main thread has stopped, is_alive(main_thread) will return False, but it will still be included in the list returned by threading.enumerate. Note that this is not a TOCTTOU issue. The issue is that enumerate actually includes "all alive threads, plus one [or more? I can't tell from the code] other[s]." ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25821> _______________________________________

2 3

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

06 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

[issue16834] ioctl mutate_flag behavior in regard to the buffer size limit
by Yuval Weinbaum 06 Nov '20

06 Nov '20

New submission from Yuval Weinbaum: In fcntl module, the documentation states the following regarding the mutate_flag in ioctl method: *** If it is false, the buffer’s mutability is ignored and behaviour is as for a read-only buffer, except that the 1024 byte limit mentioned above is avoided – so long as the buffer you pass is as least as long as what the operating system wants to put there, things should work. *** However, looking at the code (fcntlmodule.c) it seems that the 1024 bytes limitation is avoided when the mutate_flag is set to True (the opposite of what is stated in the doc). ---------- assignee: docs@python components: Documentation messages: 178732 nosy: Yuval.Weinbaum, docs@python priority: normal severity: normal status: open title: ioctl mutate_flag behavior in regard to the buffer size limit versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16834> _______________________________________

4 4

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

06 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 06 Nov '20

06 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