Marco Buccini added the comment:
I've just found a similar bug:
http://bugs.python.org/issue1646838
However, does os.path.realpath's behavior have to be as the one
specified by the POSIX standard (
http://www.kernel.org/doc/man-pages/online/pages/man3/realpath.3.html )?
If we wanted
Marco Buccini added the comment:
>Thanks for looking deeper into it.
>I would like to check the solution ASAP.
>We have really crazy dir structure which can catch a lot of
>the unexpected problems with paths, links, circular links etc.
Oh well, so you can see if the patch works
Marco Buccini added the comment:
If we decide to follow paths as '~' it means that we want to follow the
POSIX standard.
Infact, it doesn't make sense calling os.path.realpath as follow:
>>> import os
>>> os.getcwd()
'/home/marco/Desktop'
>>>
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
Marco Buttu added the comment:
Even though the Terry suggestion is formally correct, we are just at the
beginning of the tutorial, and unluckily the tuples have not been introduced
yet. To avoid adding to much complication here, IMHO we can just left the
preceding sentences as they are
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 yo
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
<http://bugs.python.org/issue29
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
<http://bugs.python.o
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:
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&#x
Marco Buttu added the comment:
Looking at the regex module and documentation, it is not clear to me whether
its API behaves exactly as the re API. In addition, being a third-party module,
things can change in the future.
To be defensive, IMO it is better to write as in the Ezio comment (in
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: "I
Marco Buttu added the comment:
The second patch LGTM. In the first one there is a typo (see review).
--
nosy: +marco.buttu
___
Python tracker
<http://bugs.python.org/issue29
Marco Buttu added the comment:
Thanks Mariatta, now it is OK to me
--
___
Python tracker
<http://bugs.python.org/issue29474>
___
___
Python-bugs-list mailin
Marco Buttu added the comment:
+1 for the Steven's suggestion
--
nosy: +marco.buttu
___
Python tracker
<http://bugs.python.org/issue29506>
___
___
Pytho
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:
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:
> It may be worth to add a reference to FORMATTING from the
> format() docstring.
+1 :-)
--
nosy: +marco.buttu
___
Python tracker
<http://bugs.python.org/i
Changes by Marco Buttu :
--
pull_requests: +202
___
Python tracker
<http://bugs.python.org/issue27200>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Buttu :
--
pull_requests: +204
___
Python tracker
<http://bugs.python.org/issue22594>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Buttu :
--
pull_requests: +203
___
Python tracker
<http://bugs.python.org/issue22549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Buttu :
--
pull_requests: +233
___
Python tracker
<http://bugs.python.org/issue29455>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue29
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
--
___
P
Changes by Marco Buttu :
--
pull_requests: +245
___
Python tracker
<http://bugs.python.org/issue29414>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 :
--
pull_requests: +261
___
Python tracker
<http://bugs.python.org/issue29648>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 "
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 c
Changes by Marco Buttu :
--
pull_requests: +332
___
Python tracker
<http://bugs.python.org/issue27200>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marco Paolini added the comment:
THe guys developing uvloop say their implementation is already quite fast [1].
Is it worth integrating it?
[1] https://github.com/MagicStack/uvloop
--
nosy: +mpaolini
___
Python tracker
<http://bugs.python.
New submission from Marco Buttu:
Right now I downloaded and installed Python 3.3.1 on Linux Mint 14, with
Cinnamon:
$ uname -a
Linux buttu-oac 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
$ python3.3
Python 3.3.1 (default, Apr 12 2013, 16:24:16
New submission from Marco Clemencic:
When passing a Python int to a C function expecting long int (or void*) via
ctypes, the number gets truncated to 32 bits, even if the args types are
correctly declared.
The workaround is to wrap the argument in c_long (or c_void_p), but the
automatic
Marco Clemencic added the comment:
Hi,
apologies for the very late answer, but I just discovered that the mails got
flagged as spam :(
In any case, I do not know where I got this "args" from, but I can confirm that
the problem is just a bug on my side.
Thanks
Marco
--
Changes by Marco Paolini :
--
nosy: +mpaolini
___
Python tracker
<http://bugs.python.org/issue23496>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marco Paolini :
--
nosy: +mpaolini
___
Python tracker
<http://bugs.python.org/issue23670>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marco Paolini added the comment:
Linking related issues http://bugs.python.org/issue24721
http://bugs.python.org/issue24667 and http://bugs.python.org/issue24685
--
nosy: +mpaolini
___
Python tracker
<http://bugs.python.org/issue24
Marco Paolini added the comment:
Attaching a patch. Does it make any sense?
--
keywords: +patch
nosy: +mpaolini
Added file: http://bugs.python.org/file40353/issue24891.patch
___
Python tracker
<http://bugs.python.org/issue24
Marco Paolini added the comment:
ops wrong patch... trying again.
--
Added file: http://bugs.python.org/file40354/issue24891.patch
___
Python tracker
<http://bugs.python.org/issue24
Changes by Marco Paolini :
Removed file: http://bugs.python.org/file40353/issue24891.patch
___
Python tracker
<http://bugs.python.org/issue24891>
___
___
Python-bug
Marco Paolini added the comment:
@haypo thanks for the quick review. This new issue24891_2.patch covers all of
the points you raised except the "check exception type" which I am still
figuring out.
--
Added file: http://bugs.python.org/file40355/issue248
Marco Paolini added the comment:
@haypo, yeah, definitely better than mine! All good for me.
--
___
Python tracker
<http://bugs.python.org/issue24891>
___
___
New submission from Marco Buttu:
I saw that async and await will become keywords in Python 3.7 :
https://www.python.org/dev/peps/pep-0492/#deprecation-plans
I enabled the deprecation warnings in Python 3.5.1 and Python 3.6 dev, and I
noticed that assigning to async or await does not issue any
Marco Buttu added the comment:
The check for the 'with' statement was handled in the parser (parsetok.c), and
in Python 2.5 the warnings were enabled by default.
I do not know how to check if the deprecation warning are enabled, otherwise I
would have tried to fix t
Marco Buttu added the comment:
Thank you Brett, your explanation (msg259409) and the c-api doc are really
straightforward. I think I can fix it in a few days, just the time to read the
devguide and be confident about the workflow.
--
___
Python
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
Marco Buttu added the comment:
Thank you Brett, the problem was the missed exec(). With the patch in
attachment the tests pass, but it does not seem to me a good solution. Infact,
changing the filter at runtime has no effect:
$ cat foo.py
import warnings
warnings.simplefilter("a
New submission from Marco Sulla:
Steps to reproduce
1. create a format_bytes.py with:
"Hello {}".format(b"World")
2. launch it with
python3 -bb format_bytes.py
Result:
Traceback (most recent call last):
File "format_bytes.py", line 1, in
"Hello {}&
Marco Sulla added the comment:
I want to clarify more: I do not want to suppress the warning, I would that the
format minilanguage will convert bytes to string properly.
--
___
Python tracker
<http://bugs.python.org/issue26
Marco Sulla added the comment:
> Python 3 doesn't guess the encoding of byte strings anymore
And I agree, but I think format minilanguage could convert it by default to
utf8, and if something goes wrong raise an error (or try str()). More simple to
use and robust at the same time.
My
Marco Sulla added the comment:
> Using utf8 means guessing the encoding
Well, it's not what format() is doing now, using str()? :)
--
___
Python tracker
<http://bugs.python.org
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
com
Changes by Marco Buttu :
--
title: Error in the -> Typo in the documentation of math.isclose()
___
Python tracker
<http://bugs.python.org/issue26898>
___
___
Py
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 indice
Marco Paolini added the comment:
I think there is an issue in the way you designed your cleanup logic. So I
think this issue is invalid.
Usually, the code (funcion, class, ...) that *opens* the file should also be
resposible of closing it.
option 1) the caller opens and closes the file and
Marco Paolini added the comment:
KeyboardInterrupt is not handled gently by asyncio (see
https://groups.google.com/d/msg/python-tulip/sovg7EIBoXs/m7U-0UXqzSQJ)
you could cancel all tasks in the signal handler:
...
def sig_interrupt():
print('interrupt')
f
New submission from Marco den Otter :
In the file socket_connection.c on line 139 a cast to Py_ssize_t is missing for
the return value.
Is:
return res < 0 ? res : ulength;
Should be
return res < 0 ? (Py_ssize_t)res : (Py_ssize_t)ulength;
Now it can be possible that a close of the
New submission from Alejandro Marco Ramos:
hi, when use the param 'funcName' in the logging module (version 0.4.9.6 for
python 2.6) the module crash. Researching in the code (__init__.py) i see that
the code for get the function name is in method '_log' in the class &#x
Alejandro Marco Ramos added the comment:
is not related to 16778
--
___
Python tracker
<http://bugs.python.org/issue16844>
___
___
Python-bugs-list mailin
Alejandro Marco Ramos added the comment:
In response to msg178860.
When use the module logging and in the definition of the format string appear
'%(funcName)s' the module crash.
(Extract):
File
"/Library/Python/2.6/site-packages/logging-0.4.9.6-py2.6.egg/logging/__init__.py&
301 - 400 of 402 matches
Mail list logo
