Mailman 3 December 2015 - docs

[issue15068] fileinput requires two EOF when reading stdin
by Kristján Valur Jónsson Dec. 7, 2015

Dec. 7, 2015

Changes by Kristján Valur Jónsson <sweskman(a)gmail.com>: ---------- nosy: -kristjan.jonsson _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15068> _______________________________________

1 0

[issue1753718] base64 "legacy" functions violate RFC 3548
by R. David Murray Dec. 6, 2015

Dec. 6, 2015

R. David Murray added the comment: See also the discussion in issue 25495. I will try to review both of these issues soon. ---------- nosy: +r.david.murray versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1753718> _______________________________________

1 0

[issue25808] The Python Tutorial 5.3. Tuples and Sequences
by Ben Schreib Dec. 5, 2015

Dec. 5, 2015

New submission from Ben Schreib: The example given in section 5.3 shows an output of "t[0] = 88888" but I believe it should be "t[0] = 12345" >>> t (12345, 54321, 'hello!') >>> # Tuples may be nested: ... u = t, (1, 2, 3, 4, 5) >>> u ((12345, 54321, 'hello!'), (1, 2, 3, 4, 5)) >>> # Tuples are immutable: ... t[0] = 88888 ---------- assignee: docs@python components: Documentation messages: 255962 nosy: Ben Schreib, docs@python priority: normal severity: normal status: open title: The Python Tutorial 5.3. Tuples and Sequences type: enhancement versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25808> _______________________________________

2 1

[issue1753718] base64 "legacy" functions violate RFC 3548
by Isobel Hooper Dec. 5, 2015

Dec. 5, 2015

Isobel Hooper added the comment: Attached patch fixes library/base64.rst as requested, and adds a mention of RFC 3548 into the b2a_base64() docs in library/binascii.rst. I'm not sure I've made the changes against the right version of the docs - I think this might be against the 3.3 docs. ---------- keywords: +patch nosy: +Isobel Hooper Added file: http://bugs.python.org/file41250/issue-1753718.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1753718> _______________________________________

1 0

[issue23936] Wrong references to deprecated find_module instead of find_spec
by Raúl Cumplido Dec. 4, 2015

Dec. 4, 2015

New submission from Raúl Cumplido: While taking a look on the import mechanisms I've seen in the documentation that find_module has been deprecated for find_spec, but on different parts of the documentation there are still references to find_module, as in the definition of sys.meta_path (https://docs.python.org/3/library/sys.html#sys.meta_path). Shouldn't it be (example on this case) a list of finder objects that have their find_spec() methods called, instead of find_module method? I've been taking a look on _bootstrap.py and I can see we call find_spec: for finder in sys.meta_path: with _ImportLockContext(): try: find_spec = finder.find_spec If you agree with me that this is wrong I'll submit a patch to fix it. ---------- assignee: docs@python components: Documentation messages: 240671 nosy: brett.cannon, docs@python, eric.snow, raulcd priority: normal severity: normal status: open title: Wrong references to deprecated find_module instead of find_spec versions: Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23936> _______________________________________

5 14

[issue25500] _find_and_load_unlocked doesn't always use __import__
by Sergei Lebedev Dec. 4, 2015

Dec. 4, 2015

New submission from Sergei Lebedev: According to the current import system documentation > When calling ``__import__()`` as part of an import statement, the import system first checks the module global namespace for a function by that name. If it is not found, then the standard builtin ``__import__()`` is called. However, one can easily verify this isn't (always) the case:: import sys assert "glob" not in sys.modules __import__ = print import glob # Doesn't print anything. I've traced the import statement from ``ceval.c`` to the frozen ``importlib._bootstrap`` and it seems the cause of the problem is in ``_find_and_load_unlocked``, which simply ignores the ``_import`` argument in the case above:: def _find_and_load_unlocked(name, import_): path = None # ... parent processing ... spec = _find_spec(name, path) if spec is None: raise ImportError(_ERR_MSG.format(name), name=name) else: # XXX import_ is not used. module = _SpecMethods(spec)._load_unlocked() # ... more parent processing ... return module I'm not sure if this is a bug in the documentation or implementation, so any feedback is appreciated. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 253635 nosy: docs@python, superbobry priority: normal severity: normal status: open title: _find_and_load_unlocked doesn't always use __import__ versions: Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25500> _______________________________________

4 6

[issue25039] Docs: Link to Stackless Python in Design and History FAQ section is broken
by Camilla Montonen Dec. 4, 2015

Dec. 4, 2015

New submission from Camilla Montonen: The link to Stackless Python here https://docs.python.org/2/faq/design.html#can-t-you-emulate-threads-in-the-… is broken. I get an "Internal Server Error" when trying to access it. ---------- assignee: docs@python components: Documentation messages: 250297 nosy: Winterflower, docs@python priority: normal severity: normal status: open title: Docs: Link to Stackless Python in Design and History FAQ section is broken versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25039> _______________________________________

4 4

Re: [docs] Wrong references to deprecated find_module instead of find_spec (issue 23936)
by takowl＠gmail.com Dec. 4, 2015

Dec. 4, 2015

http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst File Doc/glossary.rst (right): http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode313 Doc/glossary.rst:313: :meth:`find_loader` or :meth:`find_module`. On 2015/12/04 19:09:25, brett.cannon wrote: > I would drop the method specifications and let people read the details from the > more concrete finder types. Done. http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode315 Doc/glossary.rst:315: Since Python 3.3, there are two types of finder: :term:`meta path finders On 2015/12/04 19:09:25, brett.cannon wrote: > "two types of finders" To my mind, either could be correct, but 'two types of finder' reads much more comfortably. It may be one of those differences between English dialects. http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode316 Doc/glossary.rst:316: <meta path finder>` and :term:`path entry finders <path entry finder>`. On 2015/12/04 19:09:25, brett.cannon wrote: > "meta path finders for use with sys.meta_path and path entry finders for use > with sys.path. Done. http://bugs.python.org/review/23936/

1 0

Re: [docs] Wrong references to deprecated find_module instead of find_spec (issue 23936)
by brett＠python.org Dec. 4, 2015

Dec. 4, 2015

Overall LGTM, just some tweaks the "finder" entry to make it fairly generic and push details down to the more concrete meta path and path entry finder entries. http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst File Doc/glossary.rst (right): http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode313 Doc/glossary.rst:313: :meth:`find_loader` or :meth:`find_module`. I would drop the method specifications and let people read the details from the more concrete finder types. http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode315 Doc/glossary.rst:315: Since Python 3.3, there are two types of finder: :term:`meta path finders "two types of finders" http://bugs.python.org/review/23936/diff/16105/Doc/glossary.rst#newcode316 Doc/glossary.rst:316: <meta path finder>` and :term:`path entry finders <path entry finder>`. "meta path finders for use with sys.meta_path and path entry finders for use with sys.path. http://bugs.python.org/review/23936/

1 0

Inconsistent macro documentation
by Arthur Kristmann Dec. 4, 2015

Dec. 4, 2015

Hello everyone, I'm using the Python C API to make our library available to Python. It's working well, but I found a some inconsistencies in the documentation of macro definitions. To use the DateTime Objects the documentations states that I need to invoke the macro "PyDateTime_IMPORT" to initialise the datetime module. (https://docs.python.org/3.4/c-api/datetime.html) I got an error for a missing semicolon and I fix this by adding a semicolon at the end of the macro "PyDateTime_IMPORT;". Other macros from the same API such as "Py_BEGIN_ALLOW_THREADS" don't need to be close with an semicolon. (https://docs.python.org/3/c-api/init.html#c.Py_BEGIN_ALLOW_THREADS) At the end of the day it's not a big deal if you know it, but then I would expect that it's documented. It's actually good to not use default semicolons, because macros like "PyDateTime_GET_YEAR(o)" feels more like a function that needs to be closed at the end. But in this case it would be nice, if you would add semicolons in the documentation when it's needed like in the datetime section. Thanks for your time. Best regard, Arthur

1 0