[issue19645] decouple unittest assertions from the TestCase class
Robert Collins added the comment: Oh, I didn't mean to imply that these are the only options I'd support - just that these are the things I've thought through and that I think will all work well... I'm sure there are more options available ;) -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Change by Robert Collins : -- versions: +Python 3.9 -Python 3.5 ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Robert Collins added the comment: Ok so design wise - there is state on the TestCase that influences assertions; in potentially two ways. The first way is formatting - the amount of detail shown in long list comparisons etc. The second way I don't think we have at the moment, but potentially it could influence the fidelity of comparisons for NearlyEquals and the like - generally though we tend to pass those in as parameters. So just ripping everything off into standalone functions loses the home for that state. It either becomes global (ugh), or a new object that isn't a test case but is basically the same magic object that has to be known is carried around, or we find some other way of delegating the formatting choice and controls. hamcrest has some prior art in this space, and testtools experimented with that too. wordpress has managed to naff up the formatting on my old blog post about this https://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ and https://testtools.readthedocs.io/en/latest/for-test-authors.html#matchers Its been on my TODO for a very long time to put together a PEP for adding matchers to the stdlib; I find the full system we did in testtools very useful because it can represent everything from a trivial in-memory string error through to a disk image for a broken postgresql database, without running out of memory or generating mojibake but if we wanted to do something smaller that didn't prejuidice extensions like testtools still doing more that would be fine too. The core idea of matchers is that rather than a standalone function f() -> nil/raise, you build a callable object f() -> Option(Mismatch), and a Mismatch can be shown to users, combined with other mismatches to form composites or sequences and so forth. So this would give room for the state around object formatting and the like too. -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Robert Collins added the comment: Right now that attribute could be set by each test separately, or even varied within a test. TBH I'm not sure that the attribute really should be supported; perhaps thinking about breaking the API is worth doing. But - what are we solving for here. The OP here seems interested in using the assertion like things entirely outside of a test context. What would a nice clean API for that be? (Yes I like matchers, but put that aside - if the APIs aren't close enough, lets make sure we do a good job for each audience rather than a compromise..) -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37262] Make unittest assertions staticmethods/classmethods
Robert Collins added the comment: I think this is strictly redundant with that other ticket and I'm going to close it. That said, they need access to self.failureException. https://docs.python.org/3/library/unittest.html#unittest.TestCase.failureException -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Robert Collins added the comment: Sorry for the slow reply here; There are API breaks involved in any decoupling that involves the exception raising because of the failureException attribute. Something with signalling that can be adapted by other test suites etc might have merit, but I think we are lacking a clear use case for doing this to the existing exceptions. Setting up a way for new things to be more easily used by users of other test frameworks is quite attractive; perhaps just writing them as separate functions with an adapter to failureException would be sufficient. -- versions: +Python 3.9 -Python 3.5 ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36656] Please add race-free os.link and os.symlink wrapper / helper
Robert Collins added the comment: Thank you @Eryk -- ___ Python tracker <https://bugs.python.org/issue36656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36656] Please add race-free os.link and os.symlink wrapper / helper
Robert Collins added the comment: I'd like to add a few notes; please do consider Windows interactions here - Windows does not have the same model for inode replacement that Posix has. Secondly, I note that the thread model discussed here hasn't been particular well articulated. In particular the vagaries of directories with the sticky bit set are quite different to those where attacker and victim share group permissions : TOCTTOU attacks do imply that post-atomic operation attacks will be possible, and I disagree with the analysis by Serhiy suggesting that they are necessarily so. However I also agree with Toshio that the os module is not the right place to provide a more secure API: we have to have the basic primitive exposed to Python code somewhere, otherwise the higher level APIs such as you'd like to use are not creatable. My suggestion is that you put a module up on PyPI that provides the secure behaviour necessary, get some feedback on that, get some cross-platform experience, and then, if desired, propose it for inclusion in shutil or similar in the stdlib. I'm also going to retitle this - because actually, os.link and os.symlink aren't racy *per se* on Posix - its how they are used that is racy: and the very fact that a secure variant can be written (however ugly) is demonstration of that. -- nosy: +rbcollins title: Race conditions due to os.link and os.symlink POSIX specification -> Please add race-free os.link and os.symlink wrapper / helper ___ Python tracker <https://bugs.python.org/issue36656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36994] Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor
Robert Collins added the comment: New changeset b892d3ea468101d35e2fb081002fa693bd86eca9 by Robert Collins (Jeroen Demeyer) in branch 'master': bpo-36994: add test for profiling method_descriptor with **kwargs (GH-13461) https://github.com/python/cpython/commit/b892d3ea468101d35e2fb081002fa693bd86eca9 -- nosy: +rbcollins ___ Python tracker <https://bugs.python.org/issue36994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34125] Profiling depends on whether **kwargs is given
Robert Collins added the comment: New changeset b892d3ea468101d35e2fb081002fa693bd86eca9 by Robert Collins (Jeroen Demeyer) in branch 'master': bpo-36994: add test for profiling method_descriptor with **kwargs (GH-13461) https://github.com/python/cpython/commit/b892d3ea468101d35e2fb081002fa693bd86eca9 -- nosy: +rbcollins ___ Python tracker <https://bugs.python.org/issue34125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24653] Mock.assert_has_calls([]) is surprising for users
Robert Collins added the comment: I'm reopening this because I don't agree. I opened the bug because we have evidence that users find the current documentation confusing. Saying that its not confusing to us doesn't fix the confusion. Why should we mention the special case of an empty set? Because its the only special case. A simple single sentence: "Note: to assert that no calls were made see `assert_not_called`" would probably both cover the special case and direct users to the right place for that use case. -- resolution: wont fix -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue24653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
Robert Collins added the comment: This is now showing up in end user tools like black: https://github.com/ambv/black/issues/564 -- nosy: +rbcollins versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue26903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24412] setUpClass equivalent for addCleanup
Robert Collins added the comment: Serhiy, thats not a design flaw, its a feature. in a class hierarchy, setup and teardown ordering is undefined: implementors can choose whatever order they want to execute in. e.g. class A(TestCase): def setUp(self): super().setUp() acquire1() class B(A): def setUp(self): acquire2() super().setUp() class C(B): def setUp(self): super().setUp() acquire3() will acquire 2, then 1, then 3. tearDown() is similarly ill defined. Secondly, consider class Example(TestCase): def setUp(self): self._1 = acquire() self.addCleanUp(acquire()) self._3 = acquire() def tearDown(self): self._3.cleanUp() self._1.cleanUp() super().tearDown() As such, there is no ordering of cleanup + teardown that is 'right' in all cases. The question then becomes, which ordering *most facilitates* migration from tearDown to cleanup. The allowable orders are: - with a more complex implementation, per-class (no) - before tearDown starts - after tearDown finishes The common case tearDown tends to look like this: def tearDown(self): super().tearDown() so, by placing doCleanup after tearDown, we make it possible for base classes in a test hierarchy to migrate to cleanups without breaking compatibility with child classes. The cost, as you note is that we make it harder for child classes to migrate until the base class has migrated. But it is strictly better to permit the base class to migrate, because in projects you cannot be sure of all your subclasses out there in the wild, but you can be sure of all your base classes. -- ___ Python tracker <https://bugs.python.org/issue24412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Robert Collins added the comment: So, I think we're in a local minima here. As I said earlier, neither the old nor new names really grab me, and I think everyone has aknowledged that the new name is -at best- confusing. We don't need *any more discussion* about that. The question is how to fix it without yet more rounds of 'well this is confusing so lets change it again'. I want to suggest some basic criteria for a dramatically better name, just to unblock this. - follow the existing assert naming convention - be short enough to be comfortably usable - pass some user testing: do some lightning talks. Or ask on twitter for folk to tell you what the proposed name does without any hints. - follow up here with how you tested and the name you've chosen based on that testing. - we'll then do a straw poll amongst a few committers - me and michael at a minimum, and advise on go/nogo. Once thats done I'll happily review a patch that adds a new, better name as an alias, and doesn't deprecate the existing one. I'm leaving the bug in rejected status, because at this point there is nothing any committers seem to have appetite/energy to do: same as per https://bugs.python.org/msg266244 -- ___ Python tracker <https://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32419] Add unittest support for pyc projects
Robert Collins <robe...@robertcollins.net> added the comment: Whats the use for *unittest* - a tool to help folk develop - to run a test which is only present in sourceless form? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32419] Add unittest support for pyc projects
Robert Collins <robe...@robertcollins.net> added the comment: Oh, and why look for __init__ - in part, because it predates namespace packages, but also because unlike regular imports unittest will do negative things like reading the entire filesystem otherwise. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32419> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33021] Some fstat() calls do not release the GIL, possibly hanging all threads
Robert Collins <robe...@robertcollins.net> added the comment: Re: backporting this. I think backporting to 3.6/3.7 makes a lot of sense - bugfix and prerelease respectively. For 2.7, this bug has been around for ages, the patch is small, and I have no objection - but the RM has already said no, so I guess not happening :). That said, if I was analyzing this from scratch I'd look at the pypi download stats to assess what footprint 2.7 still has, and whether taking this fix there would make objective sense. While it is a genuine bug - and a nice catch - I have to say that running any Python with mmapped data off of NFS is a supremely bad idea :). -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30221] Deprecate assertNotAlmostEqual
Robert Collins added the comment: We've now spent more time debating the deprecation that we would have saved if it had been deprecated. Deprecations cost user good will. Whilst I very much want to delete all assertions in favour of matchers, which would allow composed symmetry rather than the manual symmetry we have today. Like michael I don't see any benefit in getting rid of it either. I don't believe it will make the API substantially easier to learn: the lack of symmetry increases special cases, so it will IMO make it harder to learn. Unless you've new arguments to make about this, I think the ticket can be closed WONTFIX. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30221> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
Robert Collins added the comment: @doug - I don't see how a separate fips module *wouldn't* solve it: - code that uses md5 in security contexts wouldn't be able to call it from the fips module, which is the needed outcome - code that uses md5 and isn't fips compliant would be importing from the non-fips module, and thats as auditable as looking for a 'usedforsecurity=False' flag - auditors can assume that code that doesn't use the fips module And its way less messy: remember we're going to have this flag passed to every hashlib invocation from every project in order to *opt out* of the FIPS restrictions. Because, over time, FIPS will change, so noone can assume that any given function is and will remain FIPS compatible: and this flag is going to percolate up into e.g. the HMAC module. I think thats pretty ugly: want to calculate the sha of a blob to look it up in git? sha1sum(file.read(), usedforsecurity=False) Separately I wonder about the impact on higher layers - are they ready to be parameterised by objects, or do they look things up by name - and thus need to start accepting this new parameter and passing it down? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9216] FIPS support for hashlib
Robert Collins added the comment: A few thoughts; usedforsecurity=xxx seems awkward: I wouldn't want, as a user of hashlib, to have to put that in literally every use I make of it. If I understand the situation correctly, the goal is for both linters, and at runtime, identification of the intended purpose of a call to md5 - e.g. whether there are security implications in its use (as far as FIPS is concerned). Perhaps having two separate implementations of the interfaces, one general purpose and one FIPS would be decent. e.g. from hashlib.fips import sha1 etc etc and hashlib.fips simply wouldn't contain md5. Then the md5 thats in hashlib is by definition not FIPS ready and any code using it should be fixed. -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9216> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17188] Document 'from None' in raise statement doc.
Changes by Robert Collins <robe...@robertcollins.net>: -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22431] Change format of test runner output
Robert Collins added the comment: +1 to changing the UI for 3.7 - just noting that if you're machine processing the output, the TUI isn't an appropriate channel. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
Robert Collins added the comment: Ok, so we need to figure out whether the tests are wrong, or the 'fix' is wrong. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15393] JSONDecoder.raw_decode breaks on leading whitespace
Robert Collins added the comment: I think the patch should either be rejected, or also handle trailing spaces: if we're taking the RFC definition of whitespace not being structural then we should also eat trailing space, which will change the check for extra data in decode to just checking end == s.len(). Obviously a test for the trailing case needs to be added as well. -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Robert Collins added the comment: I find details like this extremely useful in the main docs, so please do add there. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16288] TextTestResult uses TestCase.__str__() which isn't customisable (vs id() or shortDescription())
Robert Collins added the comment: @Chris - I don't like the idea of making new classes on the fly like that, it seems more likely to provoke bugs (as type(case) != SomeSpecificClass) anymore after that, vs just not relying on __str__ directly. Going back to Michael's proposal of short description, long description and repr (with str == repr) for debugging. - that is missing id(), and id() is IMO definitely still needed. I was proposing id(), friendlyId(), shortDescription(), and __str__ calls friendlyId(), and __repr__ is a regular <...> repr. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16288> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27946] issues in elementtree and elsewhere due to PyDict_GetItem
Robert Collins added the comment: Please add the reproducer as a test case (in test_dict.py I think) - even though it needs elementree to trigger it is a dict bug :). I also wonder if there are similar cases lying under other C collections like list, tuple and set. E.g. list.find() calls obj.__eq__, and so on. -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20140] UnicodeDecodeError in ntpath.py when home dir contains non-ascii signs
Robert Collins added the comment:
Given two (or more) parameters where one is unicode and one is not, upcasting
will occur multiples times in path.join on windows:
- '\\' is str and will cast up safely in all codecs
- the other str (or bytes) parameter will be upcast using sys.defaultencoding
which is often / usually ASCII on Windows
This will then fail when the str parameter is not valid ASCII.
>From this we can conclude that this is a failure to use path.join correctly:
>if all the parameters passed in were unicode, no error would occur as only
>'\\' would be getting coerced to unicode.
The interesting question is why there was a str parameter that wasn't valid
ASCII; and that lies with path.expanduser() which is returning a str for the
non-ascii home directory.
Changing that to return unicode rather than a no-encoding specified str when
HOME or HOMEPATH etc etc contain non-ascii characters is a change that would
worry me - specifically that we'd encounter code that assumes it is always str,
e.g. by calling path.join(expanduser('~fred'), '\xe1\xbd\x84D') which will then
blow up.
Worth noting too is that
expanduser(u'~user/\u14ffd')
will also blow up in the same way in the same situation - as it ends up
decoding the user home path when it concatenates userhome and path[i:].
So, what to do:
- It might be worth testing a patch that changes expanduser to decode the
environment variables - I'm not sure whether we'd want the filesystemencoding
or the defaultencoding for handling these environment variables. Steve Dower
probably knows :).
- Or we say 'sorry, too hard in 2.7' and move on: join *itself* is fine here,
given the limits of 2.7.
--
nosy: +rbcollins, steve.dower
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20140>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26240] Docstring of the subprocess module should be cleaned up
Changes by Robert Collins <robe...@robertcollins.net>: -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Robert Collins added the comment: It is a bugfix, but we should document when it started working using the version added segment IMO. I think addding this to 3.6 now would be ok. -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21254] PropertyMock refuses to raise AttributeErrror as a side effect
Robert Collins added the comment: I could imagine doing some complex things to let you get at the AttributeError in this case but *not* when a different descriptor was added to type(a_mock), but I think it would confusing overall. This might be worth a doc tweak to cover it? -- stage: needs patch -> test needed versions: +Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21254] PropertyMock refuses to raise AttributeErrror as a side effect
Robert Collins added the comment: We're poking at this at the kiwipycon sprints -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28087] macOS 12 poll syscall returns prematurely
Robert Collins added the comment: @Ned - any objection to my committing this at this point? -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28087] macOS 12 poll syscall returns prematurely
Changes by Robert Collins <robe...@robertcollins.net>: -- stage: patch review -> commit review ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25573] FrameSummary repr() does not support previously working uses of repr in traceback module
Robert Collins added the comment: So I think its fine to have a __len__ reporting 4. tuple(..) works via the iter() call, but thats really just a thunk to keep existing code working, and so __len__ for the same reason makes sense. On the documentation issue, yes, updating the docs is appropriate. Having the repr produce all the elements would be ok, the reason it is lazy is to avoid high costs for transient FrameSummary when its created and discarded shortly after. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24412] setUpClass equivalent for addCleanup
Robert Collins added the comment: Btw some things to be aware of in addressing this: - we will need tests that catchable exceptions raised from a setUpModule or setUpClass cause cleanups already registered to run - if (and I'd need to check this) setUpModule or setUpClass can nest - I think setUpModule may, in package.module contexts) - that non-local cleanups definitively run too -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24412] setUpClass equivalent for addCleanup
Robert Collins added the comment: So, thank you for the patch. However - there's no need for a metaclass here, and its actively harmful to comprehending the code. As I suggested earlier, please decouple the cleanups implementation and then consume it from the two places that it will be needed (testcase and testsuite). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27213] Rework CALL_FUNCTION* opcodes
Robert Collins added the comment: See http://bugs.python.org/issue28086 - this introduced a regression in the test suite. -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28086] test.test_getargs2.TupleSubclass test failure
New submission from Robert Collins: The test.test_getargs2.TupleSubclass test is failing in master. I suspect its a fastcall fallout. -- messages: 275879 nosy: rbcollins, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: test.test_getargs2.TupleSubclass test failure type: compile error ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27348] traceback (and threading) drops exception message
Robert Collins added the comment: hmm, can you give me a change to page this in? I'm pretty sure I saw breakage in external libraries prompting me to add the test and fix. I'd rather not recause that. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27198] Adding an assertClose() method to unittest.TestCase
Robert Collins added the comment: Chris, I suggested altering assertAlmostEqual in http://bugs.python.org/issue27198#msg267187 :) - I took your agreement with that as a good thing and didn't reply because I had nothing more to add. IMO the status of this issue is as you indicated: you needed time to code up the changes, so that its an extension to assertAlmostEquals, rather than a new assertion. When thats done I'll happily review it and commit it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27341] mock.patch decorating a generator returns a regular function.
Robert Collins added the comment: There are two related things here. Firstly, the generator's body will run without the patch (because the wrapping function has try: return decorated(..) finally: unpwatch() Secondly, the wrapping function is itself not a generator, and anything that introspects functions to see if they are generators will not detect the wrapped function as one - which is I suspect whats tripping nose up, but I haven't actually checked the nose code to see what its doing/expecting. -- nosy: +rbcollins title: mock.patch decorator fails silently on generators -> mock.patch decorating a generator returns a regular function. ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27341> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27341] mock.patch decorating a generator returns a regular function.
Robert Collins added the comment: Once fixed in CPython, we'll put the backport in mock, for folk using older Python's. -- versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27341> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27198] Adding an assertClose() method to unittest.TestCase
Robert Collins added the comment:
Future direction: hamcrest style matchers. You can read more about them in the
context of unittest
https://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/
and http://testtools.readthedocs.io/en/latest/for-test-authors.html#matchers -
sorry about the formatting in the blog post, wordpress changed theme details
some time after I wrote the post and it now renders horribly :(.
w.r.t. error messages, a regular function that raises AssertionError with a
nice message will be precisely as usable.
def assert_math_isclose(first, second, rel_tol=1e-09, abs_tol=0.0, msg=None):
if math.isclose(first, second, rel_tol=rel_tol, abs_tol=abs_tol):
return
standardMsg = ('%s != %s with relative tolerance of %.3g'
' and absolute tolerance of %.3g' % (safe_repr(first),
safe_repr(second),
rel_tol,
abs_tol))
if msg:
raise AssertionError("{} : {}".format(standardMsg, msg))
else:
raise AssertionError(standardMsg)
The reason I'm pushing back on adding methods to TestCase is that every one we
add collides with some number of subclasses out in the wild: the TestCase class
has multiple distinct APIs in the same namespace - and thats very poor for
maintaining compatibility.
Long term I want to have entirely separate interfaces for these things, but
thats even more radical an overhaul than adding matchers as a stock facility,
and I don't currently have a planned timeline for starting on that.
All of that said, I see that this isn't the same as assertAlmostEqual in
mathematical terms - but in /user/ terms I think it is. So why can't we make
assertAlmostEqual be this? Just add the extra parameter needed with a default
value and change the implementation?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27198>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27152] Additional assert methods for unittest
Robert Collins added the comment: I'm fine with these as a mixin - they are all very generic and unambiguously named. I'd marginally prefer the opt-in mixin over adding them to the base class. Ideally they'd be matchers, but since I haven't ported that upstream yet, thats asking for more work, and we can always migrate later. (https://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ and http://testtools.readthedocs.io/en/latest/for-test-authors.html#matchers - sorry about the formatting in the blog post, wordpress changed theme details some time after I wrote the post and it now renders horribly :( ) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27197] mock.patch interactions with "from" imports
Robert Collins added the comment: So its a feature of mock that it can mock a module that doesn't exist. And the semantics of the import system are designed to be very cheap when a module is already imported - so when 'patchbug.a' is in sys.modules, import will correctly return it rather than going out to the import path to find if its the same thing. We could possibly have an opt-in check on mock.patch to require that the thing being patched exists, but it would have to be opt-in as so many cases are dealing with optional or pretend instances. I'm not super keen on that though. This is perhaps worth calling out in the docs to avoid confusion. -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27198] Adding an assertClose() method to unittest.TestCase
Robert Collins added the comment: Thanks for proposing this. I really don't want to add new assertions to unittest, and I certainly don't want to add narrow usage ones like this, nor ones that are confusingly named (this has nothing to do with files, but 'close' is a verb for files, just like equal is a verb for objects. Instead, I suggest a regular function that will raise AssertionError on failure. The only thing you need _formatMessage for is handling long messages, and I don't think thats useful or relevant for a binary numeric test like this. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27071] unittest.TestCase.assertCountEqual is a very misleading name
Robert Collins added the comment: I don't particularly like either name FWIW :) - but sure, we can add a different name and deprecate assertCountEqual - but before we do anything lets look up the previous issue where the rename was done. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27063] Some unittest loader tests are silently skipped by mistake
Robert Collins added the comment: LGTM too -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27063> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26807] mock_open()().readline() fails at EOF
Robert Collins added the comment: I've committed a minimal variation - thanks for the patches. -- resolution: -> fixed stage: test needed -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26807] mock_open()().readline() fails at EOF
Robert Collins added the comment: So something like for line in _state[0]: yield line while True: yield '' Will probably do it just fine. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26807] mock_open()().readline() fails at EOF
Robert Collins added the comment:
Actually, further inspection and a teddybear with Angus Lees uncovers this:
diff --git a/Lib/unittest/test/testmock/testmock.py
b/Lib/unittest/test/testmock/testmock.py
--- a/Lib/unittest/test/testmock/testmock.py
+++ b/Lib/unittest/test/testmock/testmock.py
@@ -1419,6 +1419,18 @@
self.assertEqual('abc', first)
self.assertEqual('abc', second)
+def test_mock_open_after_eof(self):
+# read, readline and readlines should work after end of file.
+_open = mock.mock_open(read_data='foo')
+h = _open('bar')
+h.read()
+self.assertEqual('', h.read())
+self.assertEqual('', h.read())
+self.assertEqual('', h.readline())
+self.assertEqual('', h.readline())
+self.assertEqual([], h.readlines())
+self.assertEqual([], h.readlines())
+
def test_mock_parents(self):
for Klass in Mock, MagicMock:
m = Klass()
./python Lib/unittest/test/testmock/testmock.py
..sE
==
ERROR: test_mock_open_after_eof (__main__.MockTest)
--
Traceback (most recent call last):
File "Lib/unittest/test/testmock/testmock.py", line 1430, in
test_mock_open_after_eof
self.assertEqual('', h.readline())
File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/mock.py", line 917, in
__call__
return _mock_self._mock_call(*args, **kwargs)
File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/mock.py", line 976, in
_mock_call
result = next(effect)
StopIteration
--
Ran 80 tests in 0.197s
FAILED (errors=1, skipped=1)
That is, we need the yield '' to be infinite - while True: yield '', or the
while True: to be outside the try:except.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26807>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26807] mock_open()().readline() fails at EOF
Robert Collins added the comment: ./python Lib/unittest/test/testmock/testmock.py ..s. -- Ran 80 tests in 0.180s OK (skipped=1) So thats great. I am going to have to stare that this quite hard to be sure I understand why it fails without the change away from 'for line in ' - but yes, this is the right place, and I'll commit it to 3.5 and 3.6 and backport it to the external mock tomorrow. Thanks! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26859] unittest fails with "Start directory is not importable"
Robert Collins added the comment: Could you please add a test case. -- nosy: +rbcollins stage: patch review -> test needed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26807] mock_open()().readline() fails at EOF
Robert Collins added the comment: You're changing _mock_call but readline is actually implemented in _readline_side_effect - just changing that should be all thats needed (to deal with StopIteration). You will however need to fixup the return values since the test I added is a bit wider than just the single defect you uncovered. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26807] mock_open()().readline() fails at EOF
Robert Collins added the comment:
Thanks Yolanda. I've touched up the test a little and run a full test run (make
test) - sadly it fails: there is an explicit test that StopIteration gets
raised if you set it as a side effect.
==
FAIL: test_mock_open_after_eof (unittest.test.testmock.testmock.MockTest)
--
Traceback (most recent call last):
File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/test/testmock/test
mock.py", line 1428, in test_mock_open_after_eof
self.assertEqual('', h.readline())
AssertionError: '' != None
==
FAIL: test_side_effect_iterator (unittest.test.testmock.testmock.MockTest
)
--
Traceback (most recent call last):
File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/test/testmock/test
mock.py", line 980, in test_side_effect_iterator
self.assertRaises(StopIteration, mock)
AssertionError: StopIteration not raised by
==
FAIL: test_side_effect_setting_iterator (unittest.test.testmock.testmock.
MockTest)
--
Traceback (most recent call last):
File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/test/testmock/test
mock.py", line 1015, in
test_side_effect_setting_iterator
self.assertRaises(StopIteration, mock)
AssertionError: StopIteration not raised by
--
Ran 705 tests in 1.251s
FAILED (failures=3, skipped=3)
Of those, I think the first failure is a bug in the patch; the second and third
are genuine failures - you'll need to make your change in mock_open itself, not
in 'mock'.
I've attached an updated patch which has ACKS, NEWS filled out and tweaked your
test to be more comprehensive.
--
keywords: +patch
Added file: http://bugs.python.org/file42590/issue26807.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26807>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26807] mock_open()().readline() fails at EOF
Robert Collins added the comment: Thanks Yolanda, that looks sane - could you perhaps add a test for this in Lib/unittest/tests/test_mock/ ? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26807] mock_open()().readline() fails at EOF
New submission from Robert Collins: >>> import unittest.mock >>> o = unittest.mock.mock_open(read_data="fred") >>> f = o() >>> f.read() 'fred' >>> f.read() '' >>> f.readlines() [] >>> f.readline() Traceback (most recent call last): File "", line 1, in File "/home/robertc/work/cpython/Lib/unittest/mock.py", line 935, in __call__ return _mock_self._mock_call(*args, **kwargs) File "/home/robertc/work/cpython/Lib/unittest/mock.py", line 994, in _mock_call result = next(effect) StopIteration -- components: Library (Lib) messages: 263814 nosy: rbcollins priority: normal severity: normal stage: test needed status: open title: mock_open()().readline() fails at EOF type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24959] unittest swallows part of stack trace when raising AssertionError in a TestCase
Changes by Robert Collins <robe...@robertcollins.net>: -- stage: needs patch -> test needed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24959] unittest swallows par t of stack trace when raising AssertionError in a TestCase
Robert Collins added the comment: I'm fairly sure its eating the stack frames because the calling frames are annotated __unittest__ - its technically a feature :/. -- title: unittest swallows part of stack trace when raising AssertionError in a TestCase -> unittest swallows par t of stack trace when raising AssertionError in a TestCase ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24959] unittest swallows part of stack trace when raising AssertionError in a TestCase
Robert Collins added the comment: Yes, it is... ish. The frame skipping code occurs when we serialise exceptions, and we pass a limit in. The limit is calculated on the main exception only. If the cause has a longer exception than the limit we calculated, you'd see this behaviour. Probably need to make it possible to do per-exception processing of limit: I think via a callback or similar mechanism in traceback (because the cause might have thrown from some code that is also marked __unittest, so if we're honouring that, we should honour it within each exception. -- title: unittest swallows par t of stack trace when raising AssertionError in a TestCase -> unittest swallows part of stack trace when raising AssertionError in a TestCase ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25597] unittest.mock does not wrap dunder methods (__getitem__ etc)
Robert Collins added the comment: I think this is a valid mock bug; it likely needs some thoughtful exhaustive testing, and obviously support added for it. -- stage: -> test needed title: unittest.mock does not wrap dict objects correctly -> unittest.mock does not wrap dunder methods (__getitem__ etc) ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25894] unittest subTest failure causes result to be omitted from listing
Robert Collins added the comment: The basic model is this: - a test can have a single outcome [yes, the api is ambiguous, but there it is] - subtests let you identify multiple variations of a single test (note the id tweak etc) and *may* be reported differently We certainly must not report the test as a whole passing if any subtest did not pass. Long term I want to remove the error/failure partitioning of exceptions; its not actually useful. The summary for the test, when subtests are used, should probably enumerate the states. test_foo (3 passed, 2 skipped, 1 failure) in much the same way the run as a whole is enumerated. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24263] unittest cannot load module whose name starts with Unicode
Robert Collins added the comment: sih4sing5hong5 - I think we do need a test in fact - it can be done using mocks, but right now I think the patch has a bug - it looks for isidentifier on $thing.py, but not on just $thing (which we need to do to handle packages, vs modules). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25320] unittest loader.py TypeError when code directory contains a socket
Robert Collins added the comment: Thanks for the patch; the test may be redundant but not enough to matter for now - and the bug really doth need fixing, so I've applied it as-is. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26562] Large Involuntary context switches during oom-killer
Robert Collins added the comment: So this test script is making a 65K entry dict, and each item is a new, separate 65K string. The strings are allocated in single chunks, so we should expect couple hundred reference count writes total. AIUI involuntary context switches occur when there is CPU contention. What else do you have running? Notable Python is taking 3.83 seconds of system time, much more than your other tests. You may get some insight from strace -c. -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25783] test_traceback.test_walk_stack() fails when run directly (without regrtest)
Robert Collins added the comment: @serhiy, how is that different to what I said? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23890] assertRaises increases reference counter
Robert Collins added the comment: I don't think we make any guarantees for or against references, but - we attempt to free references already (see how we call clear_frames), so this is a bug, pure and simple. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24959] unittest swallows part of stack trace when raising AssertionError in a TestCase
Robert Collins added the comment: Hmm, this is a little surprising, but - why are you raising AssertionError like that - thats what assertRaises is for. -- stage: -> needs patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24922] assertWarnsRegex doesn't allow multiple warning messages
Robert Collins added the comment: The context manager errors if *nothing* matches, not if *everything* matches, which is very different to catch_warnings because the filters are used to *exclude* warnings, and excess warnings are errors there. Because of that, there's little if any reason to add support for multiple regexes - just nest two context managers. That said... The lineno is already not-fully-informative - its the first matching warnings lineno. Right now, the definition in the code is: for warnings in (the warning item-or-tuple) if the regex matches, done if none of the warnings match, error. If we allow the tuple of warnings to be a tuple of (warning, regex) items, we could do that compatibly, with some introspection. If the patch is fairly small, It might be ok, for all that I don't see a need for it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24922> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20556] Use specific asserts in threading tests
Robert Collins added the comment: @Serhiy care to commit it? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25520] unittest load_tests protocol not working as documented
Robert Collins added the comment: What version of python are you testing with? unittest 2.7 has a number of bugs vis-a-vis namespaces and discovery. If you're testing with less than 3.5, or perhaps 3.6, please try with unittest2, which has the same fixes as the stdlib unittest. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25783] test_traceback.test_walk_stack() fails when run directly (without regrtest)
Robert Collins added the comment: Can we just stop running the test suite directly? python -m unittest test.test_traceback should work fine and as quickly, ... I'd like to delete all the __main__ in the test suite as cruft TBH. The patch would be ok if ugly, its a bit of a magic number there. What the test really should do is create a recursive function of some depth, and then introspect the result of calling the function at the bottom of that recursion. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25690] Replacement for unittest.mock.mock_open
Robert Collins added the comment: Hmm, I haven't looked closely, but some high level thoughts. I'm worried about making mock too complex here. We already say folk should use a VFS for complex file based tests, and there's quite a chunk of code you're adding - perhaps better to just use a VFS? I don't like mock importing mock_open and mock_open importing mock: please keep this in a single mock.py at this point. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24780] unittest assertEqual difference output foiled by newlines
Robert Collins added the comment: Thanks for the patch; reviewed in rietvald. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19217] Calling assertEquals for moderately long list takes too long
Robert Collins added the comment: The new output seems ok to me? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21159] configparser.InterpolationMissingOptionError is not very intuitive
Robert Collins added the comment: I think we should close this again: if you subclass something you need to implement the full public API. raw has been in that API since 2010!. It's a shame that folk have been implementing just-enough, rather than the actual API, but I don't see that has all that much bearing on the go-forward. Rolling it back out of 3.4 could be done - but since the problematic subclasses are fixing themselves now 3.5 is out, that should take care of issues on 3.4 too. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24294] DeprecationWarnings should be visible by default in the interactive REPL
Robert Collins added the comment: @mbussonn - I don't see an updated non-tty-checking patch from you? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24294> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26481] unittest discovery process not working without .py source files
Robert Collins added the comment: Sorry, I missed the little footnote on case 4 about still supporting source-less distributions. I guess in that context we do still need to support this. However - please check that this does indeed happen on Python master - 3.6. unittest does evolve and if you're testing on 2.7 or something your bug is perhaps already fixed. -- resolution: not a bug -> stage: resolved -> test needed status: closed -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26481] unittest discovery process not working without .py source files
Robert Collins added the comment: Python has stopped supporting .pyc-only distributions - see https://www.python.org/dev/peps/pep-3147/#case-3-pycache-foo-magic-pyc-with-no-source - and so, while what you are seeing is inconsistent with import in some older python's, it is not a bug in newer Python's, and I don't see any benefit in doing a backport-only fix for it. -- resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25900] unittest ignores the first ctrl-c when it shouldn't
Robert Collins added the comment: I'd rather make this super simple: just terminate the test run immediately. We can catch KeyBoardInterrupt in the UI layer to still permit outputting summary information. That removes one more source of global state that makes testing fragile. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22625] When cross-compiling, don’t try to execute binaries
Robert Collins added the comment: So in general: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/System-Type.html#System-Type and https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html There are three platforms in play: target, host, build. Host is the platform where what you build should run on. build is the platform we are building on. target is the platform where the *output* of the build thing itself should run on. Baby steps though: lets assume target==host always. Now, the pathological case of building things is the canadian cross - https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross Note here that you actually build multiple different entire compilers, - and thats what we need here. We need to build two python's. One, for build, which pgen and _freeze_importlib can depend on. One, for host, which is the output, and can depend on the output of running pgen and _freeze_importlib I don't have examples of Makefile parameterisation to support this offhand, but gcc would be the obvious (if perhaps overwhelming) place to look at it. The key things I'd expect are that: - when host==build, the dependencies and outputs are identical, so we only build one copy of Python and everything else. - when host!=build, we get a chain - the host Python -> pgenoutput -> pgen -> build Python -> pgenoutput -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5319] stdout error at interpreter shutdown fails to return OS error status
Robert Collins added the comment: @Martin I was wrong re: the defs - they only cover function vs data, not return codes. So it looks fine to me. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Robert Collins added the comment: @Serhiy, EXIT_FAILURE is used in Python's C code itself (just once admittedly, and then we use 0 sometimes for success and sometimes for errors, and then 1 for errors... aiee.) FWIW to the extent that folk want to write posix code in Python, I'm all for helping them, I find the amount of help this will be to be hard to assess. There is some code to adding the constants in documentation and learning surface area. Right now we don't document all the ways Python can interact with exit codes, and I suspect thats actually a bigger burden than writing the code to generate any given code. -- nosy: +rbcollins ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24053> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25320] unittest loader.py TypeError when code directory contains a socket
Robert Collins added the comment: The fix is appropriate (we might want to think about symlinks in the future). I'd very much like a test for it (in Lib/unittest/test/test_discovery.py) and it should be applied to 3.5, master - older versions had this wrapped up in simpler code and won't fail like this. -- stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25111] Broken compatibility in FrameSummary equality
Robert Collins added the comment: LGTM too. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25108] traceback.extract_stack() compatibility break in 3.5
Robert Collins added the comment: wouldn't changing walk_stack to add one more f_back be better? Seems odd to work around it... -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25108] traceback.extract_stack() compatibility break in 3.5
Robert Collins added the comment: Hmm, I think we can fix this. Its leaking due to the use of a helper I think. So - we should just fix this [and add a test, since clearly the test coverage is insufficient] -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5319] stdout error at interpreter shutdown fails to return OS error status
Robert Collins added the comment: It seems to me that how, and when, Python exits the process is important to folk who will never ever touch the C API. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses
Robert Collins added the comment: 2.7 is sufficiently different that I haven't backported this there - plus the report said it was introduced in 3.4. If someone can show this doesn't work in 2.7 and also supply a patch, we could apply it there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses
Changes by Robert Collins robe...@robertcollins.net: -- resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2786] Names in function call exception should have class names, if they're methods
Robert Collins added the comment: Here are some options. a) Don't make the new thing public - instead export within Python.exe the existing private symbol _...withNames. Pros: no change to public API. Cons: extension modules using the public API cannot make these sorts of errors clearer. b) Add a new API. Either narrow (add the parameter) or big (add a struct). Pros: everyone treated equally. Cons: More API surface area, and more complex calling convention. c) use symbol versioning to change the existing API. Cons: more complex build-time detection for users. Pros: API surface area held constant. d) Don't fix it. :) I don't have a particular preference, though the struct thing is a wash IMO - it saves adding a serial to the API, at the cost of having a versioned datastructure which needs an embedded serial number. [Except perhaps that you can use symbol versioning to deal with evolutions of the struct - but thats fairly complex to carry off well, and I think this would be the first example w/in Python]. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2786 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5319] stdout error at interpreter shutdown fails to return OS error status
Robert Collins added the comment: def main(): try: thing() except SomethingChanged: exit(1) except BinaryDiff: exit(2) except: exit(3) This is the sort of pattern e.g. 'diff' has. Should exit(3) there become exit(1) ? exit(1) means 'succeeded and there were changes'. So no, 3,for this app, means 'broke entirely'. Exiting with '1' is also poor/confusing for this app. So perhaps we should pick something rarely used - like 255. But anyhow the same logic applies: if an app signals 'error' with a different code, we shouldn't change the apps 'error' signal to be something else when we detect an error. But OTOH preserving a non-zero not-error code when an error occurs is also wrong. So I think, on reflection: 1) pick an unusual code. Not 1. Not 77 (automake test skip code). Maybe 255? https://www.freebsd.org/cgi/man.cgi?query=sysexitssektion=3apropos=0manpath=FreeBSD+10.2-RELEASE defines some codes we should avoid as well. 2) We document that python itself may cause this exit code to be used and that apps written in python should never use that code 3) we use your patch as it is - on shutdown error force it to this chosen value. What do you think? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5319] stdout error at interpreter shutdown fails to return OS error status
Robert Collins added the comment: Right. So I think one could also propose that the default exception handling should also change to this new number, but it is a different situation - programs don't conflict with that - they allow it to bubble up, but this situation is outside its control. CLI handling of Python itself is clearly outside both situations and there's no need to reevaluate it now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5319 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22936] traceback module has no way to show locals
Robert Collins added the comment: This itself is fixed. -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22936 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23552] Have timeit warn about runs that are not independent of each other
Changes by Robert Collins robe...@robertcollins.net: -- resolution: - fixed stage: patch review - resolved status: open - closed versions: +Python 3.6 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23552 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23183] timeit CLI best of 3: undocumented output format
Changes by Robert Collins robe...@robertcollins.net: -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23183 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21112] 3.4 regression: unittest.expectedFailure no longer works on TestCase subclasses
Changes by Robert Collins robe...@robertcollins.net: -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21112 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24193] Make LOGGING_FORMAT of assertLogs configurable
Robert Collins added the comment: I don't know if or when it was moved, but right now: ./python -m pydoc unittest.case.TestCase.assertLogs ... the docs for it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24294] DeprecationWarnings should be visible by default in the interactive REPL
Robert Collins added the comment: Hi, just to say - I'm happy to help steer this through. I think its an important ecosystem fixup. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24294 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
