[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 <http://bugs.python.org/issue30951> ___ ___ 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 <http://bugs.python.org/issue31021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue31224> ___ ___ 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 : -- pull_requests: +356 ___ Python tracker <http://bugs.python.org/issue16355> ___ ___ 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 : -- nosy: +marco.buttu ___ Python tracker <http://bugs.python.org/issue29716> ___ ___ 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 : -- pull_requests: +499 ___ Python tracker <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 : -- pull_requests: +509 ___ Python tracker <http://bugs.python.org/issue27200> ___ ___ 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 <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 <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
Changes by Marco Buttu : -- pull_requests: +561 ___ Python tracker <http://bugs.python.org/issue29820> ___ ___ 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 : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <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 : -- pull_requests: +727 ___ Python tracker <http://bugs.python.org/issue27200> ___ ___ 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 <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 : -- pull_requests: +1236 ___ Python tracker <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
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 <http://bugs.python.org/issue30055> ___ ___ 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 <http://bugs.python.org/issue25435> ___ ___ 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 <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 : -- pull_requests: +1603 ___ Python tracker <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: 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 <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 <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
Changes by Marco Buttu : -- pull_requests: +2190 ___ Python tracker <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 : -- pull_requests: +2191 ___ Python tracker <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 : -- pull_requests: +2192 ___ Python tracker <http://bugs.python.org/issue30217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18424] sum() does not return only the sum of a sequence of numbers + PEP8 reccomandation
New submission from Marco Buttu:
The documentaion of sum():
Returns the sum of a sequence of numbers (NOT strings) plus the
value of parameter 'start' (which defaults to 0).
When the sequence is empty, returns start.
A. According to the PEP-8 it should be: "Return the sum...", and
"When the sequence is empty, return start.", like the other docs.
For instance:
>>> print(len.__doc__)
len(object) -> integer
Return the number of items of a sequence or mapping.
B. When the second argument is a tuple or a list, you can add sequences
of sequences:
>>> sum([['a', 'b', 'c'], [4]], [])
['a', 'b', 'c', 4]
>>> sum(((1, 2, 3), (1,)), (1,))
(1, 1, 2, 3, 1)
C. sum() takes not just sequences:
>>> sum({1: 'one', 2: 'two'})
3
Maybe it is not a good idea to give a complete description of sum() in the
docstring, but perhaps something "good enough". In any case, I think the lack
of the PEP-8 recommendation should be fixed.
--
assignee: docs@python
components: Documentation
messages: 192805
nosy: docs@python, marco.buttu
priority: normal
severity: normal
status: open
title: sum() does not return only the sum of a sequence of numbers + PEP8
reccomandation
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue18424>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18424] sum() does not return only the sum of a sequence of numbers + PEP8 reccomandation
Marco Buttu added the comment: By reading the Ronald's comment, I realized it is better to keep it simple, so I agree with him. The "extremely inefficient" reason seems to be less important (Python 3.3): $ python -m timeit -s "a=['a']*1; b=['b']*1; a+b" 1 loops, best of 3: 0.00831 usec per loop $ python -m timeit -s "a=['a']*1; b=['b']*1; sum([a, b], [])" 1 loops, best of 3: 0.0087 usec per loop -- ___ Python tracker <http://bugs.python.org/issue18424> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18570] OverflowError during division: wrong message
New submission from Marco Buttu: When the integer division result is too large to converto to float, and the operands are inside the limits, the result is `inf` or `-inf`:: >>> 2**1023 / 2**-3 inf >>> 2**1022 / 2**-4 inf >>> 2**1023 / 2**-1074 inf When both the result and an operand are too large to converto to float, we raise an OverflowError:: >>> 2**1028 / 2**-2 Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to float The message says: "long int too large to convert to float". I think in Python 3 it should be "int too large to convert...". In any case, the most important thing is that in the same situation we get a different message [1]_:: >>> 2**1032 / 2**2 Traceback (most recent call last): File "", line 1, in OverflowError: integer division result too large for a float and I think is it muddleheaded, because it should be "long int too large to convert to float", as we got in the case `2**1028 / 2**-2`. I think we should never show "integer division result too large for a float", but just: * `inf` or `-inf` when the operands are inside the limits, but the result does not * `OverflowError: long int too large to convert to float` when the result, and at least one operand, are out of range. .. [1] In this situation, we get the message "OverflowError: integer division result too large for a float" only when the denominator exponent is positive. -- messages: 193783 nosy: marco.buttu priority: normal severity: normal status: open title: OverflowError during division: wrong message type: behavior versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue18570> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18570] OverflowError in division: wrong message
Changes by Marco Buttu : -- title: OverflowError during division: wrong message -> OverflowError in division: wrong message ___ Python tracker <http://bugs.python.org/issue18570> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18839] Wrong sentence in sys.exit.__doc__
New submission from Marco Buttu: Python 3.3:: >>> import sys >>> print(sys.exit.__doc__) exit([status]) Exit the interpreter by raising SystemExit(status). If the status is omitted or None, it defaults to zero (i.e., success). If the status is numeric, it will be used as the system exit status. If it is another kind of object, it will be printed and the system exit status will be one (i.e., failure). The sentence "If the status is numeric, it will be used as the system exit status." is wrong:: >>> sys.exit(3.33) 3.33 $ echo $? 1 It should be "If the status is an *integer*, it will be used as the system exit status.", as specified in the SystemExit `doc`. .. doc: http://docs.python.org/3/library/exceptions.html#SystemExit -- assignee: docs@python components: Documentation messages: 196195 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Wrong sentence in sys.exit.__doc__ type: behavior ___ Python tracker <http://bugs.python.org/issue18839> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16046] python -O does not find *.pyo files
New submission from Marco Buttu: $ echo "print(__file__)" > foo.py $ python3.3 -O -m foo /home/marco/temp/foo.py $ ls foo.py __pycache__ $ rm foo.py $ mv __pycache__/foo.cpython-33.pyo foo.pyo $ rm __pycache__ -r $ ls foo.pyo # The following works in Python3.2, but not in Python 3.3.0rc3 $ python3.3 -O -m foo /usr/local/bin/python3.3: No module named foo -- components: Interpreter Core messages: 171276 nosy: mbuttu priority: normal severity: normal status: open title: python -O does not find *.pyo files versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16046> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16046] python -O does not find *.pyo files
Changes by Marco Buttu : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue16046> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16355] inspect.getcomments() does not work in the interactive shell
New submission from Marco Buttu: The documentation for `inspect.getcomments()` says that it returns the "lines of comments immediately preceding an object's source code". It works fine for the comments that immediately preceded an object defined in a module: $ more foo.py import inspect # A dummy comment def foo(): pass print(inspect.getcomments(foo)) $ python3.3 foo.py # A dummy comment But it does not work if we define an object interactively: $ python3.3 Python 3.3.0 (default, Oct 9 2012, 18:20:32) [GCC 4.5.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import inspect >>> # A dummy comment ... def foo(): ... pass ... >>> inspect.getcomments(foo) >>> # A dummy comment ... >>> def foo(): ... pass ... >>> inspect.getcomments(foo) >>> -- components: Library (Lib) messages: 174108 nosy: marco.buttu priority: normal severity: normal status: open title: inspect.getcomments() does not work in the interactive shell type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue16355> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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: If inspect.getcomments() requires a source file to inspect, I think it would be better to indicate it in the doc. -- ___ Python tracker <http://bugs.python.org/issue16355> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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:
I saw there is the same lack of clarity in the doc of `inspect.getsource()`:
>>> import inspect
>>> print(inspect.getsource.__doc__)
Return the text of the source code for an object.
The argument may be a module, class, method, function, traceback, frame,
or code object. The source code is returned as a single string. An
IOError is raised if the source code cannot be retrieved.
>>> def foo():
... pass
...
>>> inspect.getsource(foo)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.3/inspect.py", line 726, in getsource
lines, lnum = getsourcelines(object)
File "/usr/local/lib/python3.3/inspect.py", line 715, in getsourcelines
lines, lnum = findsource(object)
File "/usr/local/lib/python3.3/inspect.py", line 563, in findsource
raise IOError('could not get source code')
OSError: could not get source code
--
___
Python tracker
<http://bugs.python.org/issue16355>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16916] The Extended Iterable Unpacking (PEP-3132) for byte strings doesn't match the specification
New submission from Marco Buttu: The PEP 3132 said: """ ... if seq is a slicable sequence, all the following assignments are equivalent if seq has at least three elements: a, b, c = seq[0], seq[1:-1], seq[-1] a, *b, c = seq [a, *b, c] = seq """ But this doesn't happen for byte strings: >>> seq = b'xyz' >>> a, b, c = seq[0], seq[1:-1], seq[-1] >>> a, b, c (120, b'y', 122) >>> a, *b, c = seq >>> a, b, c (120, [121], 122) Tested on Python3.3 and Python3.2 (Linux Ubuntu 11.04) -- components: Interpreter Core messages: 179545 nosy: marco.buttu priority: normal severity: normal status: open title: The Extended Iterable Unpacking (PEP-3132) for byte strings doesn't match the specification type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue16916> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
New submission from Marco Buttu: I think in the descriptor howto, at this point: >>> class MyClass(object): x = RevealAccess(10, 'var "x"') y = 5 or the prompt should not have been, or there is a wrong indentation. Furthermore, in Python 3: http://docs.python.org/3/howto/descriptor.html we can remove the explicit derivation from `object` -- assignee: docs@python components: Documentation messages: 198096 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Descriptors howto type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Added file: http://bugs.python.org/file31821/py2howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : -- keywords: +patch Added file: http://bugs.python.org/file31820/py3howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Removed file: http://bugs.python.org/file31820/py3howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Removed file: http://bugs.python.org/file31821/py2howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Added file: http://bugs.python.org/file31829/py2howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Marco Buttu added the comment: Maybe is better to underline the difference between classes and non-classes objects, instead of between objects and classes, because a class is an object, so it could be confusing). Raymond, what do you think about rewriting this sentence: `The details of invocation depend on whether obj is an object or a class.` as: `The details of invocation depend on whether obj is a class or not.` I upload two new patches (one for py2 and the other for py3) -- Added file: http://bugs.python.org/file31828/py3howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Removed file: http://bugs.python.org/file31829/py2howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Added file: http://bugs.python.org/file31830/py2howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Removed file: http://bugs.python.org/file31828/py3howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Marco Buttu added the comment: I saw right now your decision about keeping object in the Python 3 doc: http://bugs.python.org/issue17351#msg183870 So, now the py3 patch takes in account just the indentation of the `RevealAccess` example and the "class or not" suggestion. -- Added file: http://bugs.python.org/file31831/py3howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Removed file: http://bugs.python.org/file31831/py3howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Removed file: http://bugs.python.org/file31830/py2howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Marco Buttu added the comment: I think the indentation is a problem, for several reasons. In all the examples in the documentation, the form by using the interactive shell is the following: >>> class MyClass: ... pass otherwise: class MyClass: pass This one is awful: >>> class MyClass: pass and in fact it is no used in the doc. So if you want to put the class clause in the interactive shell, you have to add the dots to indent the suite of the compound statement, in order to be consistent with the rest of all the documentation. But it is not just a problem of beauty: $ python -m doctest descriptor.rst ** File "descriptor.rst", line 165, in descriptor.rst Failed example: class MyClass(object): Exception raised: ... class MyClass(object): ^ SyntaxError: unexpected EOF while parsing ... By applying the patch, the definitions of the classes RevealAccess and MyClass pass the documentation test. The whole example does not pass in any case, because you are not consistent using the shell notation. -- Added file: http://bugs.python.org/file31833/py3howto.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : -- resolution: invalid -> works for me status: closed -> open ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Marco Buttu added the comment: By looking at the other examples in the howto, I saw there is the same problem in all the definitions in the prompt, and furthermore, we are using a different number of spaces to indent MyClass respect the rest of the classes defined in the prompt. There is also a wrong indentation in the StaticMethod definition (no prompt definition): class StaticMethod(object): "Emulate PyStaticMethod_Type() in Objects/funcobject.c" def __init__(self, f): self.f = f def __get__(self, obj, objtype=None): return self.f Applying the py3full.patch, the howto passes all the documentation tests: $ python -m doctest descriptor.rst | tail -n 1 ***Test Failed*** 18 failures. $ python -m doctest descriptor_modified.rst | tail -n 1 $ My 2 cents -- Added file: http://bugs.python.org/file31834/py3full.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Changes by Marco Buttu : Removed file: http://bugs.python.org/file31834/py3full.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Marco Buttu added the comment: You are right. Now it should be ok -- Added file: http://bugs.python.org/file31835/py3full.patch ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Marco Buttu added the comment: By the way, it does not pass all the tests in Python 2.7: $ python2.7 -m doctest descriptor_modified.rst | tail -n 1 ***Test Failed*** 3 failures. If we want to be very rigorous, in order to pass the tests in Py2.7 too (kipping the rst aligned between py2 and py3), we have to add 3 others doctest: +SKIP directives. PS. I think there is a small bug in sphinx, related to our examples: https://bitbucket.org/birkenfeld/sphinx/issue/1271/doctest-directive-and-dots-not-hidden -- ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19054] Descriptors howto
Marco Buttu added the comment: $ python -c "import this" | grep "silently" Errors should never pass silently -- ___ Python tracker <http://bugs.python.org/issue19054> ___ ___ 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 <http://bugs.python.org/issue19067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19068] Some built-in complex docstrings are not PEP-8 compatible
New submission from Marco Buttu: As reported in the title: >>> complex.conjugate.__doc__.splitlines()[-1] 'Returns the complex conjugate of its argument. (3-4j).conjugate() == 3+4j.' >>> complex.__format__.__doc__.splitlines()[-1] 'Converts to a string according to format_spec.' They should have been 'Return...' and 'Convert...'. Patch is attached -- assignee: docs@python components: Documentation files: complexobject.patch keywords: patch messages: 198245 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Some built-in complex docstrings are not PEP-8 compatible versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file31839/complexobject.patch ___ Python tracker <http://bugs.python.org/issue19068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19068] Some built-in complex docstrings are not PEP-8 compatible
Changes by Marco Buttu : -- type: -> enhancement ___ Python tracker <http://bugs.python.org/issue19068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19069] Built-in float docstrings are not PEP-8 compatible
New submission from Marco Buttu: As reported in the title: >>> float.as_integer_ratio.__doc__.splitlines()[2] 'Returns a pair of integers, whose ratio is exactly equal to the original' >>> float.as_integer_ratio.__doc__.splitlines()[4] 'Raises OverflowError on infinities and a ValueError on NaNs.' >>> float.conjugate.__doc__ 'Returns self, the complex conjugate of any float.' >>> float.is_integer.__doc__ 'Returns True if the float is an integer.' >>> float.__setformat__.__doc__.splitlines()[-2] 'Overrides the automatic determination of C-level floating point type.' ... They should have been 'Return...', 'Raise...' and 'Override...' Patch is attached -- assignee: docs@python components: Documentation files: floatobject.patch keywords: patch messages: 198246 nosy: docs@python, marco.buttu priority: normal severity: normal status: open title: Built-in float docstrings are not PEP-8 compatible type: enhancement versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file31840/floatobject.patch ___ Python tracker <http://bugs.python.org/issue19069> ___ ___ 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 <http://bugs.python.org/issue19472> ___ ___ 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 <http://bugs.python.org/issue20312> ___ ___ 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
<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
<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: 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 <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 <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:
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
<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: 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 <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
<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: 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 <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
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 <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
<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 <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: Here is the patch for the Sphinx conf.py file. -- keywords: +patch Added file: http://bugs.python.org/file45746/conf.py.patch ___ Python tracker <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: 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 <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: 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 <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: I attached a patch in issue 27200 that makes all doctests pass, so I close here. -- resolution: -> duplicate status: open -> closed ___ Python tracker <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 attached a patch in issue 27200 that makes all doctests pass, so I close here. -- resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/issue28860> ___ ___ 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 <http://bugs.python.org/issue27200> ___ ___ 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 <http://bugs.python.org/issue26683> ___ ___ 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 <http://bugs.python.org/issue29133> ___ ___ 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 <http://bugs.python.org/issue29134> ___ ___ 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 <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
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 <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 <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
Changes by Marco Buttu : -- nosy: +r.david.murray ___ Python tracker <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 <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
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 <http://bugs.python.org/issue29133> ___ ___ 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 <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 <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: 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 <http://bugs.python.org/issue29371> ___ ___ 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 <http://bugs.python.org/issue27200> ___ ___ 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
<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:
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
<http://bugs.python.org/issue29381>
___
___
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 <http://bugs.python.org/issue29247> ___ ___ 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 <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 <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: 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 <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 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 <http://bugs.python.org/issue29414> ___ ___ 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 <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: 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 <http://bugs.python.org/issue29428> ___ ___ 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 <http://bugs.python.org/issue29387> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
