Mailman 3 January 2020 - docs

[issue16575] ctypes: unions as arguments
by Vinay Sajip 12 Jan '20

12 Jan '20

Vinay Sajip <vinay_sajip(a)yahoo.co.uk> added the comment: New changeset c12440c371025bea9c3bfb94945f006c486c2c01 by Vinay Sajip in branch 'master': bpo-16575: Disabled checks for union types being passed by value. (GH-17960) https://github.com/python/cpython/commit/c12440c371025bea9c3bfb94945f006c48… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16575> _______________________________________

1 0

[issue16575] ctypes: unions as arguments
by Vinay Sajip 12 Jan '20

12 Jan '20

Change by Vinay Sajip <vinay_sajip(a)yahoo.co.uk>: ---------- pull_requests: +17368 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17960 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16575> _______________________________________

1 0

[issue16575] ctypes: unions as arguments
by Vinay Sajip 12 Jan '20

12 Jan '20

Vinay Sajip <vinay_sajip(a)yahoo.co.uk> added the comment: It seems that notwithstanding the issues identified in the original bug report, calls by value of structs containing unions are being used out there in the wild. Examples: The comtypes library (Windows): https://github.com/python/cpython/pull/16799#issuecomment-573318591 The ctypesgen library, which is used by other projects across platforms: https://github.com/davidjamesca/ctypesgen/issues/77 Linux examples: https://github.com/waveform80/picamera/issues/604 https://github.com/hcpl/xkbgroup/issues/15 https://github.com/enkore/i3pystatus/issues/771 So, it would seem that the simplest course of action is to disable the checks for now. The checks will be commented out and this issue and the related issue bpo-16576 will be reopened. ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue16575> _______________________________________

1 0

[issue23139] syntax diagram after EBNF description?
by Friedrich Spee von Langenfeld 12 Jan '20

12 Jan '20

New submission from Friedrich Spee von Langenfeld: In our full grammar specification (10th chapter of the language reference, https://docs.python.org/3/reference/grammar.html), the grammar of Python is comprehensively notated. What would you think of adding a picture with an equivalent syntax diagram (e. g. produced with the help of http://www.bottlecaps.de/rr/ui) to open a new way of understanding for readers? ---------- assignee: docs@python components: Documentation messages: 233236 nosy: Friedrich.Spee.von.Langenfeld, docs@python priority: normal severity: normal status: open title: syntax diagram after EBNF description? _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23139> _______________________________________

2 1

[issue13305] datetime.strftime("%Y") not consistent for years < 1000
by STINNER Victor 10 Jan '20

10 Jan '20

STINNER Victor <vstinner(a)python.org> added the comment: > I'd like for Python to provide a portable implementation of strftime instead of just documenting that the version isn't portable. If someone wants to do that, I suggest to first start with a project on PyPI. It sounds like a tricky project. Date, time, locales and localization are hard problems! ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue13305> _______________________________________

1 0

[issue13305] datetime.strftime("%Y") not consistent for years < 1000
by Jason R. Coombs 10 Jan '20

10 Jan '20

Jason R. Coombs <jaraco(a)jaraco.com> added the comment: In issue39103, I filed a bug relating to this issue. I'd like for Python to provide a portable implementation of strftime instead of just documenting that the version isn't portable. Given that this ticket assigned to 'docs' suggests that a portable version is out of the question. Can we expand the scope of this issue to actually providing a portable version? ---------- nosy: +jaraco _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue13305> _______________________________________

1 0

[issue15718] Possible OverflowError in __len__ method undocumented (when called via len() function)
by Rostyslav Dzinko 10 Jan '20

10 Jan '20

New submission from Rostyslav Dzinko: I've encountered that OverflowError which can happen in __len__ method is still undocumented, though one issue on this problem: http://bugs.python.org/issue12159 ended up with "need to be documented" comment. Link to documentation: http://docs.python.org/reference/datamodel.html#object.__len__ I think it must be clarified that __len__ return value is constrained to upper boundary (Py_ssize_t c type) when you plan to call it via len() built-in function. ---------- assignee: docs@python components: Documentation messages: 168439 nosy: Rostyslav.Dzinko, docs@python priority: normal severity: normal status: open title: Possible OverflowError in __len__ method undocumented (when called via len() function) versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15718> _______________________________________

7 18

[issue39282] python-config --embed documentation
by Milo D Kerr 10 Jan '20

10 Jan '20

Change by Milo D Kerr <dyamikerr(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python type: -> enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39282> _______________________________________

1 0

Bug in math Library
by PARTH DESAI 09 Jan '20

09 Jan '20

Respected Sir/Ma'am; I am Parth Desai, CSE engineer , from Nirma university. This mail was written to draw your attention to a very obvious bug in the math library in python. There are 7 indefinite form in Calculus. For eg. 0^inf , inf^inf, inf ^ 0 etc, The answer according to conventional mathematics should be "indefinite" or "Nan"(according to python). However, Python calculates these indefinite forms and returns false answers which would technically be very harmful for data analysts worldwide. Attached with this mail are screenshots of a few of them. This mistake was found with the help of my friend Chirag Patadiya, CSE engineer, from Nirma university. Please take this into consideration and respond accordingly. Thank you. P.S. infinity^(-infinity) should also be undefined.

2 2

[issue39161] Py_NewInterpreter docs need updating for multi-phase initialization
by Nick Coghlan 09 Jan '20

09 Jan '20

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: The Py_NewInterpreter docs only cover the behaviour of extension modules that use single-phase initialization: https://docs.python.org/3/c-api/init.html#c.Py_NewInterpreter Multi-phase initialization allows each subinterpreter to get its own copy of extension modules as well, with only C/C++ level static and global variables being shared. ---------- assignee: docs@python components: Documentation messages: 359019 nosy: docs@python, ncoghlan, petr.viktorin priority: normal severity: normal stage: needs patch status: open title: Py_NewInterpreter docs need updating for multi-phase initialization type: enhancement versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39161> _______________________________________

3 6

docs January 2020