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/
< 5]
[1, 2, 3, 4, 5]
--
Marco Buttu
INAF-Osservatorio Astronomico di Cagliari
Via della Scienza n. 5, 09047 Selargius (CA)
Phone: 070 711 80 217
Email: mbu...@oa-cagliari.inaf.it
--
https://mail.python.org/mailman/listinfo/python-list
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
Marco Buttu added the comment:
Or maybe: "tuple of names of global variables used in the bytecode"
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +2192
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30217>
___
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +2191
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30217>
___
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +2190
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30217>
___
and style than the developer of logging,
or email, or re, and so on.
True story
If we had one person who had the authority to make doc-wide decisions,
then we might be able to move towards coherent guidelines for the docs
to be more uniform.
That could be a solution :-)
--
Marco B
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
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
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +1603
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30217>
___
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
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:
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
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +1236
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30055>
___
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 <marco.bu...@gmail.com>:
--
pull_requests: +727
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27200>
___
_
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +561
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29820>
___
_
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
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 b
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +509
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27200>
___
_
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +499
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27200>
___
_
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29716>
___
_
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +356
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16355>
___
_
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +332
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27200>
___
_
Marco Buttu added the comment:
> I don't see this point. The other section titles are not about
> loops. The preceding chapter introduces while loops as a loop,
> not a statement, and this chapter talks about while and for
> loops further down the page.
What I mean is that curren
Marco Buttu added the comment:
Wolfgang, thanks for your contribution. However, I prefere the chapter as it
currently is, because IMHO it introduces the concepts more gradually than your
proposal. In addition the modification of the title section from "for
Statements" to "
New submission from Marco Buttu:
There is no import of bisect.bisect() and bisect.bisect_left() in the
documentation. IMHO the examples are clearer and more complete if we import
these functions, as in the attached patch.
--
assignee: docs@python
components: Documentation
files
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +261
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29648>
___
_
New submission from Marco Buttu:
In the first `versionadded` of the Loader section [1] of
Doc/reference/import.rst, there is no reference to `create_module()`:
.. versionadded:: 3.4
The create_module() method of loaders.
It should be:
.. versionadded:: 3.4
The :meth
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +245
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29414>
___
_
Marco Buttu added the comment:
Hello Vajrasky, the doc patch LGTM. Looking at the David's comment in Rietveld,
it seems that he does not want the test patch to be applyed. Can you please
make a pull request? Thank you very much
--
___
Python
Marco Buttu added the comment:
Hello Jim, do you have the time to make a pull request? Let me know, otherwise
I will do it
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +233
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29455>
___
_
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +203
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22549>
___
_
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +204
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22594>
___
_
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
pull_requests: +202
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27200>
___
_
Marco Buttu added the comment:
> It may be worth to add a reference to FORMATTING from the
> format() docstring.
+1 :-)
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Marco Buttu added the comment:
Thanks Jim. I tested thise exec() in Py2.7 and Py3 (3.5 - 3.7):
exec("if True:\n" + " "*width + "1\n" + "\t2\n")
* width == 0 raises a IndentationError both in Py2 and Py3
* width in range(1, 8) raises an IndentationError
Marco Buttu added the comment:
Serhiy is right about "deep copy" instead of "deepcopy", but IMO the Steven's
proposal (with the "deep copy" correction) is much clearer than the current doc.
--
___
Python tracker
Marco Buttu added the comment:
+1 for the Steven's suggestion
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Marco Buttu added the comment:
Thanks Mariatta, now it is OK to me
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29474>
___
___
Marco Buttu added the comment:
The second patch LGTM. In the first one there is a typo (see review).
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Marco Buttu added the comment:
> With the VERSION0 flag (the default behaviour), it should
> behave the same as the re module, and that's not going to change.
Thanks for the clarification Matthew. However, the default version will change,
as the regex PyPI page points out: "In the
Marco Buttu added the comment:
Looking at the regex module and documentation, it is not clear to me whether
its API behaves exactly as the re API. In addition, being a third-party module,
things can change in the future.
To be defensive, IMO it is better to write as in the Ezio comment
Marco Buttu added the comment:
IMHO the reference proposed in the patch is too verbose. Adding details like
what is supported and how to use some features I think is out of the scope of
the reference. Moreover, if the regex module changes the features we are
reporting in the reference, we'll
Marco Buttu added the comment:
Thank you Brett, here is another patch. I added the seealso directive right
after the introduction of the trace module, in the same way as urllib.request
does for requests.
--
Added file: http://bugs.python.org/file46548/issue29455_2nd.patch
Marco Buttu added the comment:
I added a "seealso" at the end of the page.
--
keywords: +patch
nosy: +marco.buttu
Added file: http://bugs.python.org/file46538/issue29455.patch
___
Python tracker <rep...@bugs.python.org>
<htt
Marco Buttu added the comment:
The patch is OK to me. I also executed the examples, and everything works fine
:-)
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Marco Buttu added the comment:
> In parallel, I was thinking of some howto content that I would like to
> see documented.
Great :-)
> How to decide what to test with doctests and what with unittests.
> I have a feeling that the sweet spot of doctests is functionality
> which
Marco Buttu added the comment:
Even though the Terry suggestion is formally correct, we are just at the
beginning of the tutorial, and unluckily the tuples have not been introduced
yet. To avoid adding to much complication here, IMHO we can just left the
preceding sentences
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
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
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
this result when I run some processes in parallel on
different CPUs, but this code uses threads, so the GIL prevents the two
task() functions to be executed in parallel. What am I missing?
--
Marco Buttu
INAF-Osservatorio Astronomico di Cagliari
Via della Scienza n. 5, 09047 Selargius (CA)
Phone: 070 711
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 ex
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:
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:
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:
The patch LGTM. There is just one typo, I think (see review).
--
nosy: +marco.buttu
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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"
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:
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
Marco Buttu added the comment:
What about this?
"Symbolic names for the flags are supplied as module constants, which can be
OR'ed together (flagA | flagB | ...) and passed to various functions."
--
___
Python tracker <rep...@bugs.pyth
Marco Buttu added the comment:
I think you got the meaning. I have never read it before :/ If you think the
meaning is clear enough for everyone, I close the issue.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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 "colle
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
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
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29133>
___
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
Marco Buttu added the comment:
Yes, you are right. Here is a patch.
--
Added file: http://bugs.python.org/file46128/issue29133_2nd.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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:
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:
Thank you. The patch fixes it and makes the example under doctest.
--
keywords: +patch
nosy: +marco.buttu
Added file: http://bugs.python.org/file46114/issue29133.patch
___
Python tracker <rep...@bugs.python.org>
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:
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 <
namespace, it
raises a NameError
* enclosing scope (LOAD_DEREF): there is a closure, and Python looks for
the name in the enclosing namespace
Is that right, or am I missing something? Thanks, Marco
[1]
http://sebastianraschka.com/Articles/2014_python_scope_and_namespaces.html
--
Marco B
Marco Buttu added the comment:
I attached a patch in issue 27200 that makes all doctests pass, so I close here.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Marco Buttu added the comment:
I attached a patch in issue 27200 that makes all doctests pass, so I close here.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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:
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:
Here is the patch for the Sphinx conf.py file.
--
keywords: +patch
Added file: http://bugs.python.org/file45746/conf.py.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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
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:
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
Marco Buttu added the comment:
I close it because the meaning of "free variable" is not clear. We are
discussing about it in issue 26683.
--
resolution: -> postponed
status: open -> closed
___
Python tracker <rep...@bug
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():
... pri
Marco Buttu added the comment:
Sorry, in the last example, for the code object ``x`` is not free both in
``foo()`` and ``moo()``, but this does not affect the conclusion.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
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
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:
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
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
l
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
>>&
sistent, and maybe could also be error prone:
>>> f.seek(2)
2
>>> f.write('c')
1
>>> f.close()
>>> open('myfile').read()
...
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3...
--
Marco Buttu
--
https://mail.python.org/mailman/listinfo/python-list
Marco Buttu added the comment:
The error message is misleading:
>>> s = '{names[-1]} loves {0[1]}'
>>> s.format(('C', 'Python'), names=('Dennis', 'Guido'))
Traceback (most recent call last):
...
TypeError: tuple indices must be integers or slices, not str
--
Changes by Marco Buttu <marco.bu...@gmail.com>:
--
title: Error in the -> Typo in the documentation of math.isclose()
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
New submission from Marco Buttu:
The math.isclose() documentation reports is_close() as function name, instead
of isclose():
>>> import math
>>> math.isclose.__doc__[:45]
'is_close(a, b, *, rel_tol=1e-09, abs_tol=0.0)'
--
assignee: docs@python
components: D
On 27/02/2016 10:13, Steven D'Aprano wrote:
I think it would be more acceptable to me if the sender
labelled the subject line as "Advertising".
+1
--
Marco Buttu
INAF-Osservatorio Astronomico di Cagliari
Via della Scienza n. 5, 09047 Selargius (CA)
Phone: 070 711 80 217
Email:
Marco Buttu added the comment:
I added the PyErr_WarnEx(PyExc_DeprecationWarning, ...) in Python/ast.c, right
below the check for None, True and False as names. Running the following test
the message is properly printed:
def test_async(self):
with self.assertWarnsRegex(DeprecationWarning
1 - 100 of 190 matches
Mail list logo
