Hello, a while back we hit a bug with doctest and mock.call that
confused a few people on our team for a while.
I dug into fixing it and made doctest more defensive around
un-unwrappable calls.
I submitted a PR (https://github.com/python/cpython/pull/22981) for an
Issue
tive patch to be reviewed.
thanks,
-Alfred
Forwarded Message
Subject: [Python-Dev] minor PR 22981 waiting review ~20 days:
https://github.com/python/cpython/pull/22981
Date: Mon, 14 Dec 2020 13:25:36 -0800
From: Alfred Perlstein
Organization: FreeBSD
To: Python Dev
Hello,
There's been a bug open where doctest can break if there are proxy
objects that fail to unwrap (https://bugs.python.org/issue35753) since
python 3.7, this includes when importing 'call' from the 'mock' module.
Does someone have time to review PR 22981
PR 22981 is a minor update to doctest to allow it to safely consume
modules which contain objects that cause inspect.unwrap to throw.
I believe the review comments in the PR have been addressed at this
point for ~20 days. The patch is relatively small, reviews are done,
but it is unmerged.
On 10/16/20 3:29 PM, Tal Einat wrote:
(Context: Continuing to prepare for the core dev sprint next week.
Since the sprint is near, *I'd greatly appreciate any quick comments,
feedback and ideas!*)
Following up my collection of past beginning contributor experiences,
I've collected these
On 11/6/20 6:13 PM, Steven D'Aprano wrote:
For the benefit of others, the problem is that
`unittest.mock.call.__wrapped__` generates a new object, which in turn
has a dynamic `__wrapped__` attribute, which does the same, thus
generating an infinite chain of *distinct* proxies.
Being distinct
Hello,
We are using doctest to give our developers easy access to write very
fast unit tests and encourage "tests as documentation".
Recently we hit an issue where doctest crashes on certain objects that
fail to "unwrap".
Looking at the code and reasoning behind the crash it seems like we
On 6/30/18 4:20 PM, Greg Ewing wrote:
Alfred Perlstein wrote:
I am asking if there's a way we can discourage the use of
"signal(SIGPIPE, SIG_DFL)" unless the user really understands what
they are doing.
Maybe there's some way that SIGPIPEs on stdout could be handled
differently
Hello,
I'm looking for someone in the python community to help with a problem
of anti-patterns showing up dealing with SIGPIPE.
Specifically I've noticed an anti-pattern developing where folks will
try to suppress broken pipe errors written to stdout by setting
SIGPIPE's disposition to
(sorry for the double post, looks like maybe attachments are dropped,
inlined the attachment this time.)
Hello,
I'm looking for someone in the python community to help with a problem
of anti-patterns showing up dealing with SIGPIPE.
Specifically I've noticed an anti-pattern developing where
10 matches
Mail list logo
