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.o
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
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/
Changes by Marco Buttu :
--
pull_requests: +356
___
Python tracker
<http://bugs.python.org/issue16355>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Buttu :
--
nosy: +marco.buttu
___
Python tracker
<http://bugs.python.org/issue29716>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Buttu :
--
pull_requests: +499
___
Python tracker
<http://bugs.python.org/issue27200>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Buttu :
--
pull_requests: +509
___
Python tracker
<http://bugs.python.org/issue27200>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
Changes by Marco Buttu :
--
pull_requests: +561
___
Python tracker
<http://bugs.python.org/issue29820>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Buttu :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Marco Buttu :
--
pull_requests: +727
___
Python tracker
<http://bugs.python.org/issue27200>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Marco Buttu :
--
pull_requests: +1236
___
Python tracker
<http://bugs.python.org/issue30055>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 waitin
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 betwe
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
Changes by Marco Buttu :
--
pull_requests: +1603
___
Python tracker
<http://bugs.python.org/issue30217>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
Changes by Marco Buttu :
--
pull_requests: +2190
___
Python tracker
<http://bugs.python.org/issue30217>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Buttu :
--
pull_requests: +2191
___
Python tracker
<http://bugs.python.org/issue30217>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Buttu :
--
pull_requests: +2192
___
Python tracker
<http://bugs.python.org/issue30217>
___
___
Python-bugs-list mailing list
Unsubscribe:
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: "
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'
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
Changes by Marco Buttu :
--
title: OverflowError during division: wrong message -> OverflowError in
division: wrong message
___
Python tracker
<http://bugs.python.org/issu
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 numeri
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 Py
Changes by Marco Buttu :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue16046>
___
___
Python-bugs-list mailing list
Unsubscri
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
imp
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/issue16
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
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 d
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:
h
Changes by Marco Buttu :
Added file: http://bugs.python.org/file31821/py2howto.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list mailin
Changes by Marco Buttu :
--
keywords: +patch
Added file: http://bugs.python.org/file31820/py3howto.patch
___
Python tracker
<http://bugs.python.org/issue19
Changes by Marco Buttu :
Removed file: http://bugs.python.org/file31820/py3howto.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list m
Changes by Marco Buttu :
Removed file: http://bugs.python.org/file31821/py2howto.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list m
Changes by Marco Buttu :
Added file: http://bugs.python.org/file31829/py2howto.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list mailin
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
Changes by Marco Buttu :
Removed file: http://bugs.python.org/file31829/py2howto.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list m
Changes by Marco Buttu :
Added file: http://bugs.python.org/file31830/py2howto.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list mailin
Changes by Marco Buttu :
Removed file: http://bugs.python.org/file31828/py3howto.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list m
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.
--
Changes by Marco Buttu :
Removed file: http://bugs.python.org/file31831/py3howto.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list m
Changes by Marco Buttu :
Removed file: http://bugs.python.org/file31830/py2howto.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list m
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
Changes by Marco Buttu :
--
resolution: invalid -> works for me
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Pyth
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
Changes by Marco Buttu :
Removed file: http://bugs.python.org/file31834/py3full.patch
___
Python tracker
<http://bugs.python.org/issue19054>
___
___
Python-bugs-list m
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/issue19
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
Marco Buttu added the comment:
$ python -c "import this" | grep "silently"
Errors should never pass silently
--
___
Python tracker
<http://bug
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.'
>>&g
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 accord
Changes by Marco Buttu :
--
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue19068>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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)
Trace
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
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
>>&
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
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 e
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
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 ther
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/issue28
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
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.py
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
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
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
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/issue28
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
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
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/i
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/i
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
<h
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-dynami
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.
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
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
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/issue29
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 Pyt
Changes by Marco Buttu :
--
nosy: +r.david.murray
___
Python tracker
<http://bugs.python.org/issue29133>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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/file
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 &
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/issue29
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
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
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
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" actua
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/issue29
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
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 m
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 d
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
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 do
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
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
1 - 100 of 136 matches
Mail list logo
