On 5/1/2019 9:30 AM, Chris Withers wrote:
Agreed, but my focus here is to get to 100% for mock so that it's clear
that all the code is there for a reason; mock is very complicated by
necessity, and having examples of why code needs to be there is what I'm
aiming for most of all.
I agree
Chris Withers writes:
> On 01/05/2019 17:09, Stephen J. Turnbull wrote:
> > Executive summary:
> >
> > "There should be a tool" (sorry, I'm not volunteering any time soon)
> > that could be added to $VCS diff (say, "git coverage-diff" or "git
> > diff --coverage").
>
> That sounds like a
Thanks Antoine.
As BDFL-Delegate I'm happy with this version of the PEP, so it's my
pleasure to accept it for inclusion in Python 3.8.
Regards,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Yes, I'll help with this, and I try to get signed up with an account for
the issue tracker ASAP.
I've just started trying to build create the embeddable package for windows
locally (all from source). Once I have that automated, I'll take a naive
stab at the Linux layout. I'm sure i'll soon hit
> I thought https://www.python.org/dev/peps/pep-0582/ had something about
> no longer add '.' to sys.path, but looks like I was mistaken.
>
It was discussed [0] in the past with respect to security since Perl did a
similar change and PEP 432 is also mentioned in the thread. [1]
[0]
On 01/05/2019 17:09, Stephen J. Turnbull wrote:
Executive summary:
"There should be a tool" (sorry, I'm not volunteering any time soon)
that could be added to $VCS diff (say, "git coverage-diff" or "git
diff --coverage").
That sounds like a very hard problem to solve...
> If people are
On 01May2019 1305, Gerald Wiltse wrote:
That does help, thanks so much for the fast response! I now see how
it's executed on Azure pipelines also, so that should be enough for me
to reverse engineer the rest.
Followup questions if you have time:
1. It seems that directory doesn't exist in
That does help, thanks so much for the fast response! I now see how it's
executed on Azure pipelines also, so that should be enough for me to
reverse engineer the rest.
Followup questions if you have time:
1. It seems that directory doesn't exist in the 3.6 branches/tags, so it
must have been
On Wed, 1 May 2019 14:30:01 +0100
Chris Withers wrote:
>
> > Is it really that difficult to simply tell coverage to ignore them? I
> > thought someone had already pointed to a coveragerc file that let you
> > do this.
>
> It would be if the cpython repo had a coveragerc, but it does not.
On 01May2019 1109, Gerald Wiltse wrote:
I looked through all the windows builders here and could not find any
which generate this package, can anyone tell me where the work happens?
I also tried searching looking for scripts and CI files which create the
package in all the relevant repos and
Executive summary:
"There should be a tool" (sorry, I'm not volunteering any time soon)
that could be added to $VCS diff (say, "git coverage-diff" or "git
diff --coverage").
Chris Withers writes:
> It's an interesting point; I personally don't see much value in coverage
> of less than 100%,
I looked through all the windows builders here and could not find any
which generate this package, can anyone tell me where the work happens? I
also tried searching looking for scripts and CI files which create the
package in all the relevant repos and could not find those either.
Is this
On 01/05/2019 14:52, Karthikeyan wrote:
We try to support several different ways of running tests. This allows
to catch some environment depended flaws in tests and serves as a kind
of the test of unittest itself. Not all test files are made
discoverable
yet, but we move in
On Wed, May 1, 2019 at 6:13 PM Serhiy Storchaka wrote:
> 01.05.19 10:09, Chris Withers пише:
> > Right, but that's not the documented way of running individual suites in
> > the devguide.
> >
> > I'm happy to remove these on the basis that there should be one and only
> > one way of doing things
On 01/05/2019 14:22, Paul Moore wrote:
If people are actually using these blocks, then so be it, but it feels
like the people who want them to stick around are saying they're using
them just on the off chance they might use them, which feels like a poor
reason to keep a bunch of dead code
On Wed, 1 May 2019 at 13:53, Chris Withers wrote:
>
> On 01/05/2019 13:37, Paul Moore wrote:
> > I agree - removing this just to make the coverage figures look pretty
> > seems like the wrong motivation.
> >
> > Configuring coverage to understand that you want to exclude these
> > lines from the
Sorry, accidentally include a comment for this in a reply to Paul:
On 01/05/2019 13:39, Serhiy Storchaka wrote:
We try to support several different ways of running tests. This allows
to catch some environment depended flaws in tests and serves as a kind
of the test of unittest itself. Not all
On 01/05/2019 13:37, Paul Moore wrote:
I agree - removing this just to make the coverage figures look pretty
seems like the wrong motivation.
Configuring coverage to understand that you want to exclude these
lines from the checking would be fine, as would accepting that a
coverage of slightly
01.05.19 10:09, Chris Withers пише:
Right, but that's not the documented way of running individual suites in
the devguide.
I'm happy to remove these on the basis that there should be one and only
one way of doing things like this.
This principle is not applicable here because the Python
I agree - removing this just to make the coverage figures look pretty
seems like the wrong motivation.
Configuring coverage to understand that you want to exclude these
lines from the checking would be fine, as would accepting that a
coverage of slightly less than 100% is OK. Removing
On 01/05/2019 13:21, Victor Stinner wrote:
Le mer. 1 mai 2019 à 03:12, Chris Withers a écrit :
Right, but that's not the documented way of running individual suites in
the devguide.
Maybe, but I'm using that sometimes and it's useful for some specific
issues. Is it possible to run an
Le mer. 1 mai 2019 à 03:12, Chris Withers a écrit :
> Right, but that's not the documented way of running individual suites in
> the devguide.
Maybe, but I'm using that sometimes and it's useful for some specific
issues. Is it possible to run an individual test file using unittest?
Something
On Tue, 30 Apr 2019 22:24:53 +0100
Chris Withers wrote:
> Hi All,
>
> I have a crazy idea of getting unittest.mock up to 100% code coverage.
>
> I noticed at the bottom of all of the test files in testmock/, there's a:
>
> if __name__ == '__main__':
> unittest.main()
>
> ...block.
>
>
On 5/1/2019 2:13 AM, Chris Withers wrote:
On 01/05/2019 06:12, Terry Reedy wrote:
Such blocks should be excluded from coverage by the default
.coveragerc file. Mine came with
exclude_lines =
# Don't complain if non-runnable code isn't run:
if 0:
if __name__ == .__main__.:
On 01/05/2019 07:46, Serhiy Storchaka wrote:
01.05.19 00:24, Chris Withers пише:
I have a crazy idea of getting unittest.mock up to 100% code coverage.
I noticed at the bottom of all of the test files in testmock/, there's a:
if __name__ == '__main__':
unittest.main()
...block.
How
01.05.19 00:24, Chris Withers пише:
I have a crazy idea of getting unittest.mock up to 100% code coverage.
I noticed at the bottom of all of the test files in testmock/, there's a:
if __name__ == '__main__':
unittest.main()
...block.
How would people feel about these going away? I don't
On 01/05/2019 06:12, Terry Reedy wrote:
Such blocks should be excluded from coverage by the default .coveragerc
file. Mine came with
exclude_lines =
# Don't complain if non-runnable code isn't run:
if 0:
if __name__ == .__main__.:
if DEBUG:
Which .coveragerc are you
27 matches
Mail list logo
