[issue31224] Missing definition of frozen module
New submission from Marco Buttu: In the doc there are several hints [*] to frozen modules, but there is no definition of them. Do you think we should add a "frozen module" definition to the glossary? * Doc/library/importlib.rst, Doc/library/imp.rst, Doc/reference/import.rst, ... -- assignee: docs@python components: Documentation messages: 300405 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Missing definition of frozen module type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31021] Clarify programming faq.
Marco Buttu added the comment: Terry thanks for opening this issue. The title of the FAQ makes me think that the section wants to clarify why -22 // 10 returns -3. I am a bit confused, maybe because -22//10 == -3 does not surprise me, and so I do not understand the point :( This seems to me a section about the module rather than floor division. If the section wants to clarify the floor division behavior in Python, IMHO at the beginning of the section we have to explain why -22//10 == -3 may surprise the reader (it is not clear to me, so maybe it could not surprise other readers too), and then the reasons that justify why to have -22//10 == -3. -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30951] Documentation error in inspect module
Marco Buttu added the comment: Or maybe: "tuple of names of global variables used in the bytecode" -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30217] Missing entry for the tilde (~) operator in the Index
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +2192 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30217] Missing entry for the tilde (~) operator in the Index
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +2191 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30217] Missing entry for the tilde (~) operator in the Index
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +2190 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30335] Document deprecated alias of assertNotRegex
Marco Buttu added the comment: Hi Jim, I think assertNotRegexpMatches has never been introduced: https://docs.python.org/3/whatsnew/3.1.html https://docs.python.org/3/whatsnew/3.2.html That is why there is no reference in the documentation about that. I also executed a test with Python 3.1 and 3.2. and I found that there is no assertNotRegexpMatches assertion available. -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30335> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30217] Missing entry for the tilde (~) operator in the Index
Marco Buttu added the comment: Looking at Doc/reference/expressions.rst and Doc/reference/datamodel.rst, I do not see any reference to the symbols, but only to the operator name (negation, minus, plus, inversion, etc.). Therefore I think it is better to not change these files. In the PR [*] I added (in Doc/library/stdtypes.rst) both a reference to the symbol and to the name. Thank you very much [*] https://github.com/python/cpython/pull/1502/ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30217] Missing entry for the tilde (~) operator in the Index
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +1603 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30217] Missing entry for the tilde (~) operator in the Index
Marco Buttu added the comment: Thanks Eric. I think the reference should be added here, as we do for the other operators: https://docs.python.org/3/library/stdtypes.html#bitwise-operations-on-integer-types -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25435] Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation)
Marco Buttu added the comment: I also noticed that the howto differentiates between objects and classes: "The details of invocation depend on whether obj is an object or a class." I think it is misleading, because a class is actually an object. IMHO is better to differentiate between classes and non-classes objects: "The details of invocation depend on whether obj is a class or not." -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30055] Missed testcleanup in decimal.rst
Marco Buttu added the comment: We are not executing the doctests on Travis CI, but I executed them locally. That's why I realized there was a missed testcleanup. The issue27200 wants to fix all doctests, and I actually completed the job, but three PRs are still opened, and I am waiting for review approval. If you want to contribute to the reviews, look for 'bpo-27200' on the GitHub PRs. I hope the doctest will be run on Travis as soon as possible. Thanks, Marco -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30055] Missed testcleanup in decimal.rst
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +1236 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30055] Missed testcleanup in decimal.rst
New submission from Marco Buttu: The testsetup in Doc/library/decimal.rst is not enough for isolating the tests in respect to the other rst files. Currently we have the following testsetup, without a testcleanup: .. testsetup:: * import decimal import math from decimal import * # make sure each group gets a fresh context setcontext(Context()) Without a testcleanup, the changes on the context will affect the other files that use the context (like Doc/library/statistics.rst). We should better isolate the tests adding also a testcleanup: .. testcleanup:: * # make sure other tests (outside this file) get a fresh context setcontext(Context()) I am opening a PR. -- assignee: docs@python components: Documentation messages: 291559 nosy: docs@python, marco.buttu, skrah priority: normal severity: normal status: open title: Missed testcleanup in decimal.rst type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +727 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16355] inspect.getcomments() does not work in the interactive shell
Changes by Marco Buttu <marco.bu...@gmail.com>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29820] Broken link to "GUI Programming with Python: QT Edition" book
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +561 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29820] Broken link to "GUI Programming with Python: QT Edition" book
Marco Buttu added the comment: Hi Mariatta, all the other seealso entries (PyGObject, PySide, ...) have references to some specific books and tutorials. No one has a reference to the wiki, maybe because there is already a reference to it (at the end of the page). IMHO we can keep the PyQt description consistent with the other GUIs descriptions, and we can fix the broken URL just removing the reference to the outdated book. What do you think? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29820] Broken link to "GUI Programming with Python: QT Edition" book
New submission from Marco Buttu: In [*] the link to "GUI Programming with Python: QT Edition by Boudewijn Rempt", does not work. I did not find an official web page for this book, but it is really outdated (2002), so maybe we can take only the reference to the Mark Summerfield's book, about PyQt4. Let me know, so in case I will open a PR. [*] https://docs.python.org/3/library/othergui.html -- assignee: docs@python components: Documentation messages: 289678 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Broken link to "GUI Programming with Python: QT Edition" book versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +509 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +499 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29716] Python 3 Module doc still sounds like __init__.py is required
Changes by Marco Buttu <marco.bu...@gmail.com>: -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16355] inspect.getcomments() does not work in the interactive shell
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +356 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +332 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29414] Change 'the for statement is such an iterator' in Tutorial
Marco Buttu added the comment: > I don't see this point. The other section titles are not about > loops. The preceding chapter introduces while loops as a loop, > not a statement, and this chapter talks about while and for > loops further down the page. What I mean is that currently in every section (of this chapter) about a statemet, the statement is qualified as "statement": "if Statements", "for Statements", "pass Statements", and "break and continue Statements, and else Clauses on Loops". The last one is not an exeption, bacause we have already introduced for and while, and writing "break and continue Statements, and else Clauses on for and while statements" IMO is redundant. I like the current structure of titles, because IMO helps beginners to better classify things (statements, functions, ...), and it is not clear to me the objective motivation for changing "for Statemets" to "for Loops", breaking the structure given by the original author. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29414] Change 'the for statement is such an iterator' in Tutorial
Marco Buttu added the comment: Wolfgang, thanks for your contribution. However, I prefere the chapter as it currently is, because IMHO it introduces the concepts more gradually than your proposal. In addition the modification of the title section from "for Statements" to "for Loops" IMHO makes the title not consistent with the other section titles. > - I don't think range() really deserves its own section > in a chapter about control flow, so I removed most of it > and linked to the relevant stdtypes section instead -1 for me: the range() function is used in several examples in the chapter, that is why IMHO it is worth having the range() section as it is now. > - moved the definition of an iterable up into the for > loop section -1 for me: IMHO the current definition/introdution of iterable is easier to understand for a beginner. > - restructured the for loop section to discuss Python for loops > first and only compare them to Pascal/C afterwards +0. I think for a reader who is coming from another language is better to have the current introduction. But maybe it is not the same for a reader who is learning Python as a first programming language. > - moved the example for modifying a list while iterating > over it to the datastructures chapter +0 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29669] Missing import of bisect in the documentation examples
New submission from Marco Buttu: There is no import of bisect.bisect() and bisect.bisect_left() in the documentation. IMHO the examples are clearer and more complete if we import these functions, as in the attached patch. -- assignee: docs@python components: Documentation files: import_bisect.patch keywords: patch messages: 288663 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Missing import of bisect in the documentation examples type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46676/import_bisect.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29648] Missed reference to create_module() in versionadded (import.rst)
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +261 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29648] Missed reference to create_module() in versionadded (import.rst)
New submission from Marco Buttu: In the first `versionadded` of the Loader section [1] of Doc/reference/import.rst, there is no reference to `create_module()`: .. versionadded:: 3.4 The create_module() method of loaders. It should be: .. versionadded:: 3.4 The :meth:`~importlib.abc.Loader.create_module` method of loaders. I will make a PR. [1] https://docs.python.org/3/reference/import.html#loaders -- messages: 288560 nosy: marco.buttu priority: normal severity: normal status: open title: Missed reference to create_module() in versionadded (import.rst) versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29414] Change 'the for statement is such an iterator' in Tutorial
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +245 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16355] inspect.getcomments() does not work in the interactive shell
Marco Buttu added the comment: Hello Vajrasky, the doc patch LGTM. Looking at the David's comment in Rietveld, it seems that he does not want the test patch to be applyed. Can you please make a pull request? Thank you very much -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29414] Change 'the for statement is such an iterator' in Tutorial
Marco Buttu added the comment: Hello Jim, do you have the time to make a pull request? Let me know, otherwise I will do it -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29455] Mention coverage.py in trace module documentation
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +233 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22549] bug in accessing bytes, inconsistent with normal strings and python 2.7
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +203 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22594] Add a link to the regex module in re documentation
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +204 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Changes by Marco Buttu <marco.bu...@gmail.com>: -- pull_requests: +202 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29526] Documenting format() function
Marco Buttu added the comment: > It may be worth to add a reference to FORMATTING from the > format() docstring. +1 :-) -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29387] Tabs vs spaces FAQ out of date
Marco Buttu added the comment:
Thanks Jim. I tested thise exec() in Py2.7 and Py3 (3.5 - 3.7):
exec("if True:\n" + " "*width + "1\n" + "\t2\n")
* width == 0 raises a IndentationError both in Py2 and Py3
* width in range(1, 8) raises an IndentationError in Py2 and TabError in Py3
* width == 8 is OK in Py2, and raises a TabError in Python 3
* width > 8 is the same as width == 0
I think the most important case, is when width==4 or width==8, because they are
the usual widths of the TAB. In these cases, the editor will show a "correct"
level of indentation, but Python will raise an exception and a beginner user
will not understand the reason. IMO is here that Lib/tabnanny.py really comes
in handy. And in these cases (width== 4 or 8), Python 3 raises a TabError, but
if we write in the doc that it raises an IndentationError, IMO the user perhaps
will think there is an error in the doc, because IMO on the average he/she will
not spot that TabError is a subclass of IndentationError. Thats why I think it
is better to not specity the exeption type.
Anyway, it is really a minor issue, and currently is also related to other
issues, so there is no need to discuss to much for such a detail. Finally, the
wording in the pull request is good enough for me :) Thanks
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29387>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29506] Incorrect documentation for the copy module
Marco Buttu added the comment: Serhiy is right about "deep copy" instead of "deepcopy", but IMO the Steven's proposal (with the "deep copy" correction) is much clearer than the current doc. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29506] Incorrect documentation for the copy module
Marco Buttu added the comment: +1 for the Steven's suggestion -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29474] Grammatical errors in weakref.WeakValueDictionary docs
Marco Buttu added the comment: Thanks Mariatta, now it is OK to me -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29474] Grammatical errors in weakref.WeakValueDictionary docs
Marco Buttu added the comment: The second patch LGTM. In the first one there is a typo (see review). -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22594] Add a link to the regex module in re documentation
Marco Buttu added the comment: > With the VERSION0 flag (the default behaviour), it should > behave the same as the re module, and that's not going to change. Thanks for the clarification Matthew. However, the default version will change, as the regex PyPI page points out: "In the short term this will be VERSION0, but in the longer term it will be VERSION1." I propose a patch that integrates the Brett suggestion. -- Added file: http://bugs.python.org/file46575/regex_reference.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22594] Add a link to the regex module in re documentation
Marco Buttu added the comment: Looking at the regex module and documentation, it is not clear to me whether its API behaves exactly as the re API. In addition, being a third-party module, things can change in the future. To be defensive, IMO it is better to write as in the Ezio comment (in the review): "mostly compatible API". I propose a shorter patch, that adds the reference at the beginning of the page (right after the module introcution). -- Added file: http://bugs.python.org/file46561/regex_reference.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22594] Add a link to the regex module in re documentation
Marco Buttu added the comment: IMHO the reference proposed in the patch is too verbose. Adding details like what is supported and how to use some features I think is out of the scope of the reference. Moreover, if the regex module changes the features we are reporting in the reference, we'll have an outdated reference. In addition, as Brett Cannon pointed out in msg287159, the preferred way to mention a 3rd-party library should be by adding the reference at the top of the page, as in Doc/library/urllib.request.rst:19. I propose to just add a more concise reference, at the beginning of the page, like the following: .. seealso:: `regex <https://pypi.python.org/pypi/regex/>`_, a third-party alternative regular expression module. -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22594> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29455] Mention coverage.py in trace module documentation
Marco Buttu added the comment: Thank you Brett, here is another patch. I added the seealso directive right after the introduction of the trace module, in the same way as urllib.request does for requests. -- Added file: http://bugs.python.org/file46548/issue29455_2nd.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29455] Mention coverage.py in trace module documentation
Marco Buttu added the comment: I added a "seealso" at the end of the page. -- keywords: +patch nosy: +marco.buttu Added file: http://bugs.python.org/file46538/issue29455.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29455> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29441] Update examples to use async and await keywords in asyncio-task.rst
Marco Buttu added the comment: The patch is OK to me. I also executed the examples, and everything works fine :-) -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29428] Doctest documentation unclear about multi-line fixtures
Marco Buttu added the comment: > In parallel, I was thinking of some howto content that I would like to > see documented. Great :-) > How to decide what to test with doctests and what with unittests. > I have a feeling that the sweet spot of doctests is functionality > which you can invoke in one line, and which produces one line of > output which you can match against a reference string. If it takes > many lines to set up, or invoke, or checking for correctness is > more than a test for string equality, then maybe unittest is a > better tool. All your questions come up every time I speak about doctest, and these doubts are the main reason for my previous sentence: "there is more to say [about doctest] than only the API". That is why IMO an howto could be really helpful. What doctest checks is not one line of output, but the output as a string, and of course it could have multiple lines. Try to execute the doctest (with the -v option) for this docstring: def foo(): """ >>> a = 33 >>> a 33 >>> for i in range(2): ... print(i) ... 0 1 """ Three tests will be executed: one for `a=33`, expecting nothing, one for `a`, expecting 33 as output, and one test for the whole `for` block, expecting one output composed of two lines. For several reasons IMO doctest is not a substitute for unittest. They are different tools for different purposes, as thier name point up. To have a wide view, usually it is a good idea to start from the beginning: https://groups.google.com/forum/#!msg/comp.lang.python/DfzH5Nrt05E/Yyd3s7fPVxwJ Anyway, IMO this is not the right place to discuss and explain the objectives of doctest. I propose you to open a repository on github, work and discuss there, and when all is ready, we can ask for a review. Please write here the link to the github repo, so anyone else wants to contribute can find it. Thanks again for your time -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29414] Change 'the for statement is such an iterator' in Tutorial
Marco Buttu added the comment: Even though the Terry suggestion is formally correct, we are just at the beginning of the tutorial, and unluckily the tuples have not been introduced yet. To avoid adding to much complication here, IMHO we can just left the preceding sentences as they are. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29387] Tabs vs spaces FAQ out of date
Marco Buttu added the comment: I think you are right about the TAB model (Parser/tokenizer.c:40 and Lib/tokenize.py:215), that is why the difference between the two cases. In any case, I am not sure whether expliciting the type of the exeption is the best choice. So, to me +1 to just change "should report" with "reports" in the proposed patch, and +0 to indicate the exeption type. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29428] Doctest documentation unclear about multi-line fixtures
Marco Buttu added the comment: IMO if you would like to apply big changes to the current doc, as you wrote before, maybe is worth considering to propose a separate howto, instead of wide changes to the current page. I am suggesting this to you, because looking at the other modules of the standard library, I see they just explain the API, extending with examples when needed. When is worth adding extra documentation, in a different style, I see the usual solution is to extend with an howto. Look at the argparse module and related howto, for instance: https://docs.python.org/3/library/argparse.html https://docs.python.org/3/howto/argparse.html I also think an howto in this case is appropriate, because there is more to say than only the API. If you want to follow the howto way, I would like to contribute. In any case, I am disposed to review your patch -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29428] Doctest documentation unclear about multi-line fixtures
Marco Buttu added the comment: > I just had a problem with doctests. It manifested as an > error that occurred when I did > >>> import StringIO in my doctest. Maybe you are running the doctest with Python 3. The StringIO module is no more available in Python 3, so your doctest will fail on Python 3 and will pass on Python 2. > 1. There is no example of a multiple-line doctest fixture: > specifically, a fixture which involves at least one line to > set up state, and another line to be the example that tested. > I suggest adding such an example as a new section, "26.3.2. > Usage: multi-line tests". > Note that the example in 26.3.3.2 doesn't count: that is a > Compound Statement, and I'm talking about a test consisting > of multiple interactive statements. The example in section 26.3.3.2 [1], before the compound statement (the if/else), contains two simple statements. I also think the example is complete and straightforward for its purpose, and it does not have to be complicated adding avanced features. If you want a more complex control over your tests, for instance adding fixtures, you can find how to do it later, in [2]. > 2. Section "26.3.3.2. How are Docstring Examples Recognized?" does > not talk about when to use a PS1 prefix (>>>) and when to use a > PS2 prefix (...). It should say to use the PS1 at the start of each > Python "interactive statement", that is, a statement list ending with > a newline, or a Compound Statement. And, to use the PS2 to prefix each > continuing line within a Compound Statement. I am -1 on this. IMHO there is no need to add extra description to a such self-explaining, clear and concise example. But this I think is also clear from the beginning. Infact, the first line of the doc says: "The doctest module searches for pieces of text that look like interactive Python sessions" > 3. Section "26.3.3.3. What’s the Execution Context?" is not > clear about the crucial difference between state that accumulates > within a single docstring from Example to Example, and that is reset > from one docstring to another. The phrase "so that one test in M can’t > leave behind crumbs that accidentally allow another test to work" > can be interpreted as applying within a single docstring. The phrase > "names defined earlier in the docstring being run" is easy to miss. Also this section IMO is well written and clear. I do not know what to say... If someone else thinks it is not enough understandable, maybe the better think to do is to add a very small example, with two functions, that shows their docstrings have independent globals. > Unless someone tells me otherwise, I'll get around to filing similar > issues against Python 3.6 and Python 2.7. > Then it's my intention to write improvements to the documentation > for Python 3.7, 3.6, and 2.7, and submit each of those. Keep in mind that writing a patch is not enough. The patch has to be reviewed, and that means other people have to find the time to work on it. I suggest you to watch this talk of Raymond Hettinger, before going on: https://www.youtube.com/watch?v=voXVTjwnn-U [1] https://docs.python.org/3/library/doctest.html#how-are-docstring-examples-recognized [2] https://docs.python.org/3/library/doctest.html#unittest-api -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29414] Change 'the for statement is such an iterator' in Tutorial
Marco Buttu added the comment: I agree with you that the current sentence: "We have seen that the for statement is such an iterator" is wrong. But also the new sentence IMHO is confusing, because it stills compare statementes with objects: "the for statement expects an object that is iterable. The function list is another; it creates lists from iterables". Also list is a class, not a function. IMHO the goal of the sentence you want to patch is to complete the previous one [1], adding an example of "construct" that operates with iterables, and of function that takes an iterable. If you want to follow that purpose, I suggest somethink like this: "We have seen that the for statement is such a construct, while examples of functions that take an iterable are ``sum()`` and ``max()``::" Written in better English than mine... [1] "We say such an object is iterable, that is, suitable as a target for functions and constructs that expect something from which they can obtain successive items until the supply is exhausted." -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29414> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Marco Buttu added the comment: Thank you Raymond for your time. I just want to note that does not distrac the reader, because it is not show in the output. Furthermore, to doctest an example we do not need to add the prompt (>>>): we can use the testcode/testoutput Sphinx directives. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29387] Tabs vs spaces FAQ out of date
Marco Buttu added the comment: Hi Martin, why did you write "Python should report an error if mixed tabs and spaces are causing problems in leading whitespace."? Python for sure reports an error in that case. Maybe "Python reports an error if..." is a better choice. But my English is really poor, so I can be wrong... I have just this doubt, otherwise the patch is OK to me. -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Marco Buttu added the comment: Thanks Brett :-) Following the suggestion of Ezio to split the patch in more patches (msg284560), and according to msg284628, here is a first patch for just three files. To run their doctests: $ sphinx-build -b doctest . build/doctest \ library/configparser.rst \ library/ctypes.rst \ library/copyreg.rst -- Added file: http://bugs.python.org/file46456/configparser_ctypes_copyreg.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29247] Document return value of epoll.poll
Marco Buttu added the comment: The patch LGTM. There is just one typo, I think (see review). -- nosy: +marco.buttu ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29381] Tutorial documentation contains undefined reference to #!
Marco Buttu added the comment:
The patch LGTM. I think there is just one type (see review).
By the way, looking at the PEP 0263, the sentence "To define a source code
encoding, a magic comment must be placed into the source files either as first
or second line in the file" actually is not true. Also because I did not see
any point in the PEP that clarifies that the fist line has to be a comment.
Maybe it could be deduced by the examples (all using the shebang), but maybe
not, and the user could think this is a valid declaration:
print('très jolie')
# -*- coding: ascii -*-
If you think is worth to clarify, I open an issue with a patch for the PEP 0263.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29381>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29381] Tutorial documentation contains undefined reference to #!
Marco Buttu added the comment:
You wrote: "It is also possible to specify a different encoding for source
files. In order to do this, you can use a special comment line that defines the
source file encoding::". I think that is not true, because the line have to be
the first line, or right below a comment (just one, as in the case of the
shebang). For instance, in this case Python apply the declared coding:
$ cat foo.py
# The first line is a comment
# -*- coding: ascii -*-
print('è') # Encoded in UTF-8
$ python foo.py
...
SyntaxError: encoding problem: ascii
In this case it does not:
$ cat foo.py
# The first line is a comment
# and also the sencond line
# -*- coding: ascii -*-
print('è') # Encoded in UTF-8
$ python foo.py
è
But I think you are right that the current doc is confusing. Maybe yon can
write something like this:
"It is also possible to specify a different encoding for source files. In order
to do this, put one special comment line to define the source file encoding:
# -*- coding: encoding -*-
This coding comment has to be the first line of the file, or the second line in
case the first one is the #! line."
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29381>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Marco Buttu added the comment: In order for the patches to work for every Python version (see #msg284622 ), I added a new feature to the Sphinx doctest extension, called pyversion. Starting from Sphinx 1.6, it will be possible to specify the Python version in order for the example to be tested. For instance, if I run the doctests with Python 3.3, then this test will be skipped: .. doctest:: :pyversion: > 3.4 # Code example It will be tested only when Sphinx is running on Python > 3.4. My question is: what about using this feature in the patches? I am asking this because Sphinx 1.6 will be released in about 7-10 months, so until then, if we want to use the :pyversion: feature we have to build the documentation using the master version of Sphinx. Please, let me know -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29371] Typo in doctest documentation
Marco Buttu added the comment: What about this? "Symbolic names for the flags are supplied as module constants, which can be OR'ed together (flagA | flagB | ...) and passed to various functions." -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29371] Typo in doctest documentation
Marco Buttu added the comment: I think you got the meaning. I have never read it before :/ If you think the meaning is clear enough for everyone, I close the issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29371] Typo in doctest documentation
New submission from Marco Buttu: >From the doctest documentation [1]: "Symbolic names for the flags are supplied as module constants, which can be or'ed together and passed to various functions." Is there a typo in "...which can be or'ed together..."? Maybe "collected together"? [1] https://docs.python.org/3/library/doctest.html#option-flags -- assignee: docs@python components: Documentation messages: 286254 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Typo in doctest documentation versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example
Marco Buttu added the comment: Here is a 3rd patch with the Berker's suggestion. I just limited the output to 79 characters per line, and made use of the +NORMALIZE_WHITESPACE option (to normalize the newline inside the output). -- Added file: http://bugs.python.org/file46225/issue29133_3rd.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Marco Buttu added the comment: Thinking a little bit about it, I believe that the easiest way to proceed is to make one patch for every file or two, with the only purpose to make their doctests to pass. Otherwise if I make a patch with all the doctest directives, or just with the +SKIP options, we will have hundreds of failures, and it will be really hard to understand what is going wrong, also because the tests are not isolated, and we will have some random failures. Reducing the number of failures by making a patch with all the doctest/testsetup/testcleanup directives is not a solution, because we eventually fall again into a big patch, and the doctests are still not pass too. That is why I think having one patch for two files will reduce a lot the effort in making and reviewing the patch. We will end up in about 9 patches, and it will be really easy to review most of them (I think couple of minutes). It will be also easy to test them. For instance, if the patch involves the files Doc/library/copyreg.rst and Doc/library/ctypes.rst, we just have to to to the Doc/ directory and run: $ sphinx-build -b doctest . build/doctest \ > library/copyreg.rst \ > library/ctypes.rst expecting 0 failures. Maybe having one new issue for each patch will also simplify the process, because the purpose of the patch will be well explained by the issue description and title. Let me know what you think, and thank you very much for your time. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example
Changes by Marco Buttu <marco.bu...@gmail.com>: -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example
Marco Buttu added the comment: I did not add the doctest directive on purpose. In fact, if in the future we start running the doctests with buildbot (see issue27200), the tests related to this issue will pass only for Python >= 3.6. If we _currently_ want the doctests to pass for every Python version, I see only two solutions: 1) we do not have to doctest the example, as I did in issue29133_2nd.patch 2) we have to apply two patches, one with doctests (for the doc to be tested with Python >= 3.6), and another one without doctests (for the doc to be tested with Python < 3.6). I think the best solution is to add an option to the doctest directive, that allows us to specify for which Python version the tests have to be run: https://github.com/sphinx-doc/sphinx/issues/3303 I would like the commiters to give a feedback about this, because if they think this solution is doable, then I will spend the time to work on the Sphinx issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example
Marco Buttu added the comment: Yes, you are right. Here is a patch. -- Added file: http://bugs.python.org/file46128/issue29133_2nd.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Marco Buttu added the comment: Hi Ezio, thanks for your time :) The +SKIP option and the testsetup and teardown directives are not visible in the output. The only extra code in the output is sorted(). I agree with you about the use of sorted(), and I think we do not have to add extra code just to make the example passes. But as you can see in issue28860, I was asked to add it. Before going on, I think we should have a clear policy about it. I also think the examples are there do document, but I believe there are good reasons to test them. In fact, unittests and doctests have complete diffent purposes: the goal of doctests is to verify the examples work properly, that's all. An example could be wrong also if all the related unittests pass and it is still updated: there could be a typo in the code or in the output, a missing import, and other kind of errors or lacks that make the example not working, getting confused the reader. Unluckily there is not just the downside you pointed out :/ Ok to break the patch in more patches, but I did not get if you want me to open a new issue for each patch, or attach all the patches here in this issue. Thanks again -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29134] contextlib doc bug
Marco Buttu added the comment: Going a bit OT, in the contextlib doc there are two examples that have both normal code and shell code in the same code block. In this way we loose the prompt syntax highlight, and the code block can also confuse the reader. In the patch attached the two examples are executed entirely in the shell, and both are under doctest. -- keywords: +patch nosy: +marco.buttu Added file: http://bugs.python.org/file46116/contextlib.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example
Marco Buttu added the comment: Thank you. The patch fixes it and makes the example under doctest. -- keywords: +patch nosy: +marco.buttu Added file: http://bugs.python.org/file46114/issue29133.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26683] Questionable terminology for describing what locals() does
Marco Buttu added the comment: Another point in the doc, where the meaning of "free variable" is inconsistent with the ``locals()`` and ``code.co_freevars`` meaning: https://docs.python.org/3/reference/executionmodel.html#interaction-with-dynamic-features -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Marco Buttu added the comment: I isolated all snippets in the unittest.mock documentation, and now all doctests pass without surprises :-) -- Added file: http://bugs.python.org/file45818/issue27200_3rd.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28860] Fixed all the doctest failures in Doc/library/configparser.rst
Marco Buttu added the comment: I attached a patch in issue 27200 that makes all doctests pass, so I close here. -- resolution: -> duplicate status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28863] Doc/includes/*.py files and doctests
Marco Buttu added the comment: I attached a patch in issue 27200 that makes all doctests pass, so I close here. -- resolution: -> duplicate status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Marco Buttu added the comment: This last patch (make_doctest_ok.patch) makes all doctests pass (Sphinx 1.5, Python 3.6). Before applaying the patch there are 466 failures in 2096 tests, and after we have more tests (2414) and 0 failures. Actually, sometimes 3 tests fail in Doc/library/unittest.mock-examples.rst, but I did not get why :/ -- Added file: http://bugs.python.org/file45792/make_doctest_ok.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27200] make doctest in CPython has failures
Marco Buttu added the comment: Here is a patch that makes all Doc/library/datetime.rst doctests pass. The tests only pass with Python 3.6 and 3.7 (the optional ``timespec`` argument of ``datetime.isoformat()`` has been introduced in Python 3.6). To apply the patch you should agree with issue 28863. In particular, to make the patch effective, as explained in issue 28863, you should: * apply the Doc/conf.py patch of issue 28863. * rename Doc/includes/tzinfo-examples.py to Doc/includes/tzinfo_examples.py About the Raymond disappointment expressed in #10225, I see two ways to make both Raymond happy and the code examples tested. For the examples included from Doc/includes, using the ``literalinclude`` Sphinx directive, we can just add the Doc/includes path in Doc/conf.py (see issue 28863). At this point we can import them in the shell code examples (or in the ``setupcode``). In the datetime.rst.patch in attachment, I make use of this solution. Another option, for short snippets of code, not included from Doc/includes, is to use the ``testcode`` Sphinx directive. -- keywords: +patch nosy: +marco.buttu Added file: http://bugs.python.org/file45747/datetime.rst.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28863] Doc/includes/*.py files and doctests
Marco Buttu added the comment: Here is the patch for the Sphinx conf.py file. -- keywords: +patch Added file: http://bugs.python.org/file45746/conf.py.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28860] Fixed all the doctest failures in Doc/library/configparser.rst
Marco Buttu added the comment: Here is a 3rd patch. I used a generator expression argument to ``sorted()``, as recommend by Zachary. Thank you very much for all your suggestions -- Added file: http://bugs.python.org/file45745/configparser3rd.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28863] Doc/includes/*.py files and doctests
New submission from Marco Buttu:
In the Doc/includes directory, some of the *.py file names have a dash
character. For instance: Doc/includes/tzinfo-examples.py. I am trying to make
all of the code examples pass the doctests, and I usually need to import from
these files some code. Importing from these modules also allow us to test them,
and I think that is important because their code is included in the
documentation.
There are two problems:
1) I can not directly import them, because of the - character, so I have to use
__import__('file-name') and write other ugly tricks. I can import them in the
setuptests, so the reader will not see these imports, but it is still ugly, and
in addition the code examples will be not complete, and the reader will not be
able to try the code
2) the dash in the file names is un-pythonic. As the PEP 0008 says, the
preferred way is to use underscores: "Modules should have short, all-lowercase
names. Underscores can be used in the module name if it improves readability."
In conclusion, I propose to change the Doc/includes/*.py file names, replacing
the dash character with an underscore. If you agree, I will do it step by step:
I will change each file name only when I will work with the related
documentation and code examples.
PS. To include these files in the code examples, I also need to add the
Doc/includes directory to the sys.path (in conf.py).
--
assignee: docs@python
components: Documentation
messages: 282307
nosy: docs@python, marco.buttu
priority: normal
severity: normal
status: open
title: Doc/includes/*.py files and doctests
type: enhancement
versions: Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28863>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28860] Fixed all the doctest failures in Doc/library/configparser.rst
Marco Buttu added the comment: I usually keep the code examples focused, because I think extra code added just in order to have more tests can get the example less clear. But of course, there is an important downside :/ So, if your policy and goal is to have a better coverage of the code examples, here is another patch that uses sorted(). Thank you very much for your time :-) -- Added file: http://bugs.python.org/file45741/configparser2nd.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28853] locals() and free variables
Marco Buttu added the comment: I close it because the meaning of "free variable" is not clear. We are discussing about it in issue 26683. -- resolution: -> postponed status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28853> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26683] Questionable terminology for describing what locals() does
Marco Buttu added the comment:
The documentation [1] says: "If a variable is used in a code block but not
defined there, it is a free variable." According to this description, it seems
to me that the variable ``x`` is free in ``foo()``::
>>> def foo():
... print(x)
But actually for the code object it is not::
>>> foo.__code__.co_freevars
()
The meaning of free variable used for the code object is consistent with the
``locals()`` documentation [2]: "Free variables are returned by locals() when
it is called in function blocks". In fact, in the following code ``x` is not a
free variable for ``locals()``::
>>> def foo():
... print(x)
... print(locals())
...
>>> x = 3
>>> foo()
3
{}
So, I thing there is an inconsistency between the definition of "free variable"
given in [1] and the meaning of "free variable" both in the code object and in
the ``locals()`` documentation [2].
But if we change the definition of "free variable" according to the meaning of
both the code object and ``locals()``, I am afraid we go in the wrong
direction, because I suspect for most people the proper definition of free
variable is the one given in [1]. Also for Wikipedia [3]: "In computer
programming, the term free variable refers to variables used in a function that
are neither local variables nor parameters of that function.".
Instead, if we keep or remove the definition of "free variable" given in [1], I
agree with Terry to change the ``locals()`` documentation, writing that
"``locals()`` includes also the locals of the surrounding function contexts,
even though they are called 'nonlocal' within the nested function.". Maybe it
is also worth adding a shell example, to better clarify.
So, at the end, to me the ideal solution would be to keep in [1] the current
definition of "free variable", to change the ``locals()`` documentation
according to Terry suggestion, and to change the behavior of
``code.co_freevars`` (maybe not only this) in order to fit the definition.
[1] https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
[2] https://docs.python.org/3/library/functions.html#locals
[3] https://en.wikipedia.org/wiki/Free_variables_and_bound_variables
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26683>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28853] locals() and free variables
Marco Buttu added the comment: Sorry, in the last example, for the code object ``x`` is not free both in ``foo()`` and ``moo()``, but this does not affect the conclusion. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28853> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28853] locals() and free variables
Marco Buttu added the comment:
Martin, I removed the class blocks by accident. In any case, I reject the patch
by myself, because to me the definition of "free variable" is not clear.
The documentation [1] says: "If a variable is used in a code block but not
defined there, it is a free variable." According to this description, it seems
to me that ``x`` is free both in ``foo()`` and in ``moo()``:
>>> def foo():
... print(x)
... def moo():
... print(x)
... return moo
But actually for the code object it is not:
>>> foo.__code__.co_freevars
()
>>> moo.__code__.co_freevars
('x',)
Thank you for your feedback, I will continue the discussion in issue 26683.
[1] https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28853>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28860] Fixed all the doctest failures in Doc/library/configparser.rst
New submission from Marco Buttu: With Python 3.7.0a0 and sphinx-build 1.4.9, this was the result before applying the patch: Doctest summary === 80 tests 8 failures in tests 0 failures in setup code 0 failures in cleanup code build finished with problems, 139 warnings. After applaying the patch there are 0 failures in 84 tests. All the doctests also pass with Python 3.6 and 3.5. I skipped three tests (doctest: +SKIP) because their output is random (iterating over dictionary keys). -- assignee: docs@python components: Documentation files: configparser.patch keywords: patch messages: 282258 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Fixed all the doctest failures in Doc/library/configparser.rst type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45733/configparser.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28853] locals() and free variables
Marco Buttu added the comment: Yes, it is the same. "Free variables belonging to the enclosing local namespaces" are "non-global free variables". In order for the reader to better contextualize the sentence, I think it is worth keeping the code example in the patch. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28853> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28853] locals() and free variables
Marco Buttu added the comment:
In addition, also if here "function blocks" means nested function, the sentence
"Free variables are returned by locals() when it is called in function blocks"
I think is wrong. It is true only in case of free variables belonging to the
local enclosing scope. For instance, in the following case ``x`` is free in
``moo()``, but it is not in ``locals()``::
>>> x = 10
>>> def foo():
... def moo():
... print(x)
... print(locals())
... return moo
...
>>> moo = foo()
>>> moo()
10
{}
I attach a patch with a new description and an example.
PS. Is the rst rendered by Sphinx? In that case, why we are not using the
doctest Sphinx extension to test the code examples?
--
keywords: +patch
Added file: http://bugs.python.org/file45732/locals_func.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28853>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28853] locals() and free variables
New submission from Marco Buttu:
The locals() documentation [1] says that "Free variables are returned by
locals() when it is called in function blocks". A free variable inside a
function has a global scope, and in fact it is not returned by locals()::
>>> x = 33
>>> def foo():
... print(x)
... print(locals())
...
>>> foo()
33
{}
Maybe "function blocks" here means "closure"? Does the doc mean this?
>>> def foo():
... x = 33
... def moo():
... print(x)
... print(locals())
... return moo
...
>>> moo = foo()
>>> moo()
33
{'x': 33}
In that case, I think it is better to write "closures" instead of
"function blocks".
[1] https://docs.python.org/3/library/functions.html#locals
--
assignee: docs@python
components: Documentation
messages: 282200
nosy: docs@python, marco.buttu
priority: normal
severity: normal
status: open
title: locals() and free variables
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28853>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7951] Should str.format allow negative indexes when used for __getitem__ access?
Marco Buttu added the comment:
The error message is misleading:
>>> s = '{names[-1]} loves {0[1]}'
>>> s.format(('C', 'Python'), names=('Dennis', 'Guido'))
Traceback (most recent call last):
...
TypeError: tuple indices must be integers or slices, not str
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7951>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26898] Typo in the documentation of math.isclose()
Changes by Marco Buttu <marco.bu...@gmail.com>: -- title: Error in the -> Typo in the documentation of math.isclose() ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26898> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26898] Error in the
New submission from Marco Buttu: The math.isclose() documentation reports is_close() as function name, instead of isclose(): >>> import math >>> math.isclose.__doc__[:45] 'is_close(a, b, *, rel_tol=1e-09, abs_tol=0.0)' -- assignee: docs@python components: Documentation files: isclose.patch keywords: patch messages: 264585 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Error in the versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42669/isclose.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26898> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26182] Deprecation warnings for the future async and await keywords in Python 3.6
Marco Buttu added the comment: I added the PyErr_WarnEx(PyExc_DeprecationWarning, ...) in Python/ast.c, right below the check for None, True and False as names. Running the following test the message is properly printed: def test_async(self): with self.assertWarnsRegex(DeprecationWarning, "reserved keyword"): async = 33 However, the test does not pass, because the DeprecationWarning is not triggered. I am sorry but as a cpython beginner I can not figure out how to solve the problem, so I hope someone else can find the time to do it -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26182] Deprecation warnings for the future async and await keywords
Marco Buttu added the comment: Thank you Brett, your explanation (msg259409) and the c-api doc are really straightforward. I think I can fix it in a few days, just the time to read the devguide and be confident about the workflow. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26182] Deprecation warnings for the future async and await keywords
Marco Buttu added the comment: The check for the 'with' statement was handled in the parser (parsetok.c), and in Python 2.5 the warnings were enabled by default. I do not know how to check if the deprecation warning are enabled, otherwise I would have tried to fix the problem. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26182] Deprecation warnings for the future async and await keywords
New submission from Marco Buttu: I saw that async and await will become keywords in Python 3.7 : https://www.python.org/dev/peps/pep-0492/#deprecation-plans I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, and I noticed that assigning to async or await does not issue any deprecation warning: $ python -Wd -c "import sys; print(sys.version); async = 33" 3.5.1 (default, Jan 21 2016, 19:59:28) [GCC 4.8.4] $ python -Wd -c "import sys; print(sys.version); async = 33" 3.6.0a0 (default:4b434a4770a9, Jan 12 2016, 13:01:29) [GCC 4.8.4] -- components: Interpreter Core messages: 258833 nosy: marco.buttu priority: normal severity: normal status: open title: Deprecation warnings for the future async and await keywords type: enhancement versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20312] A missing link to Python-3.4.0b2.tar.bz2 in the download page.
New submission from Marco Buttu: At the page: http://www.python.org/getit/releases/3.4.0/ the link: http://www.python.org/ftp/python/3.4.0/Python-3.4.0b2.tar.bz2 does not work. -- assignee: docs@python components: Documentation messages: 208545 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: A missing link to Python-3.4.0b2.tar.bz2 in the download page. versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20312 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19472] inspect.getsource() raises a wrong exception type
New submission from Marco Buttu: I was looking at inspect.getsource(). In Python 3.3 and 3.4 either the docstring and the online doc say it raises a OSError, and in fact: import inspect def foo(): ... pass ... inspect.getsource(foo) Traceback (most recent call last): ... OSError: could not get source code However, getsource() calls getfile(), and this one raises a TypeError: inspect.getsource(0) Traceback (most recent call last): ... TypeError: 0 is not a module, class, method, function, traceback, frame, or code object -- assignee: docs@python components: Documentation, Library (Lib) messages: 201891 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: inspect.getsource() raises a wrong exception type type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19472 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19067] Built-in range docstrings are not PEP-8 compatible
New submission from Marco Buttu: The range documentation is not PEP-8 compatible: range.__doc__.splitlines()[-1] 'Returns a virtual sequence of numbers from start to stop by step.' range.__reversed__.__doc__ 'Returns a reverse iterator.' range.index.__doc__.splitlines()[-1] 'Raises ValueError if the value is not present.' They should have been 'Return...' and 'Raise...'. Patch is attached -- assignee: docs@python components: Documentation files: rangeobject.patch keywords: patch messages: 198244 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Built-in range docstrings are not PEP-8 compatible type: enhancement versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file31838/rangeobject.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
