Robert Collins added the comment:
This was reported as https://code.google.com/p/unittest-ext/issues/detail?id=71
a while back. I think blacklisting FunctionTestCase in TestLoader is entirely
reasonable.
--
___
Python tracker rep...@bugs.python.org
Ezio Melotti added the comment:
Does removing from unittest import * from somewhere fix the issue?
Is this a bug in your code, or did that import reveal a bug in unittest?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22680
Antoine Pitrou added the comment:
Does removing from unittest import * from somewhere fix the issue?
Yes.
Is this a bug in your code, or did that import reveal a bug in unittest?
Your choice :-)
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
btw, in case that's not clear from the traceback, discover was mistaking
FunctionTestCase as one of my test classes (while it was just there because of
the import *).
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Or perhaps everything that has as a __module__ something which has the
attribute __unittest = True?
(the attribute is there for a reason, right?)
--
___
Python tracker rep...@bugs.python.org
Michael Foord added the comment:
Ah. Test discovery is discovering FunctionTestCase and attempting to
instantiate it as a test. And failing.
Maybe discovery should special case that class and not treat it as a normal
TestCase.
--
___
Python
Ethan Furman added the comment:
Michael Foord opined:
-
Maybe discovery should special case that class and not treat it as a normal
TestCase.
Not a bad idea. On the other hand, I don't believe unittest is advertised as
supporting 'from ... import *', which *is* usually
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22680
___
New submission from Antoine Pitrou:
I just got the following traceback when trying discover without 3.5. It runs
fine under 3.4...
$ ~/cpython/default/python -m unittest discover -v
Traceback (most recent call last):
File /home/antoine/cpython/default/Lib/runpy.py, line 170, in
Michael Foord added the comment:
I assume you mean you get the error *with* 3.5 (not without). Does this
happen *every time* (i.e. is it trivially reproducible) - or can you provide a
repro?
This is regression that I would *assume* (a totally lazy assumption) introduced
by the new error
Antoine Pitrou added the comment:
I assume you mean you get the error *with* 3.5 (not without).
Yes, sorry :-)
Does this happen *every time* (i.e. is it trivially reproducible)
It happens with the llvmlite repository: https://github.com/numba/llvmlite
Since using it requires some compiling,
Michael Foord added the comment:
As _testFunc is a string and shouldn't be, I'd be very interested to know
*what* the string is. That may give us a clue as to where it has come from. (So
a try...except...raise that also prints that value would be a good first step.)
--
Antoine Pitrou added the comment:
testFunc contains runTest (!).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22680
___
___
Python-bugs-list
Antoine Pitrou added the comment:
Ok, apparently it's because I have from unittest import * somewhere.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22680
___
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22680
___
___
Python-bugs-list mailing
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22680
___
___
Python-bugs-list
16 matches
Mail list logo