Log file Viewer

[01:17:15] <cooperlees> Anyone here done a lot of pytest + asyncio mocking? Generally I just use the unittest module with some wrappers ...

[01:17:26] <cooperlees> With pytest I'm getting a lot of TypeError: object MagicMock can't be used in 'await' expression

[01:18:13] <cooperlees> I feel if I make the MagicMock return a coroutine, this works outside of pytest ... Wondering what's throwing this TypeError ... Wonder if it's a newer cpython thing

[01:21:12] <cooperlees> Definitely not cpython - Just tested that. I think it's some pytest magic. Really making async'ing bandersnatch unit tests hard :(

[02:50:08] <toad_polo> cooperlees: I think there was some Async/Await mock stuff added in 3.8?

[02:50:34] <toad_polo> I think maybe Lisa was working on it at the core dev sprint?

[02:50:37] <cooperlees> Does not help when you're a 3.6 > 3.8 projet

[02:50:40] <cooperlees> *project

[02:50:55] <cooperlees> I've wrote tons of asyncio - Just never with pytest .. so trying it.

[02:51:12] <toad_polo> Well I think it got backported to the 3rd party mock.

[02:51:37] <cooperlees> Still don't think it helps me at all.

[02:53:15] <cooperlees> I've always found it easier to write mock stubs for clients (thrift / grpc / http) in asyncio

[02:53:37] <cooperlees> Think I'm going to have to go that way

[02:54:07] <cooperlees> So annoying when unit tests take 10x the time of doing the actual code.

[02:54:21] <cooperlees> Had bandersnatch async'd in 2 hours. Prob spent 10 hours now on the unittests

[03:29:47] <toad_polo> Such is life.

[03:30:04] <toad_polo> But TBH I'm not sure I can consider my code "done" until it's got like at least 95% test coverage.

[03:30:56] <toad_polo> I spent so long on the standard library time zone unit tests and it's still littered with "# TODO: Add tests for Australia, Portugal", etc.

[03:31:08] <toad_polo> PLus a bunch of stuff that I know I have to do but haven't even bothered to add TODO comments for.

[03:50:54] <techalchemy> testing is hard

[03:51:16] <techalchemy> especially if you actually care about cross platform or edge cases

[04:16:54] <toad_polo> Yes, soon I have to write this thing in C and then figure out the best way to test for PEP 399 (i.e. C implementation matches Python implementation)

[04:17:08] <toad_polo> The way we do it with datetime seems weird and fragile.

[04:17:25] <toad_polo> You have to fuck with the imports to force it to not recognize the C module that's there in order to test the pure python version.

[04:18:31] <techalchemy> sounds right, is it particularly hard to ignore c modules ? i'm not sure i've done that

[04:33:30] <toad_polo> techalchemy: I think it depends on how the c module is configured, but the bigger issue is that you are modifying the live interpreter in the test, and you want to import the same thing and run the same tests twice, once with the C backend and once with the Python backend.

[04:33:50] <toad_polo> And sys.modules is a mutable global.

[04:34:04] <techalchemy> yeah but i mean, what choice do you really have

[04:34:48] <toad_polo> Well, theoretically you could use an environment variable and run the tests in separate processes.

[04:35:11] <techalchemy> or you can use a context manager to do your modifications and hope you monkeypatch correctly

[04:35:19] <techalchemy> or you can use a subinterpreter? :)

[04:35:36] <techalchemy> i dont know how globals are managed in subinterpreters actually

[04:36:05] <toad_polo> I'm considering trying to figure something out like that, I'm not sure how well supported it would be in testing frameworks, but I'd love it to be able to spawn a fresh interpreter that just runs my test and reports the response.

[04:36:45] <techalchemy> but unittest.mock supports dictionary mocks and sys.modules is a global dictionary technically

[04:36:55] <techalchemy> so that's usually what i would do (or the pytest equivalent)

[04:36:55] <toad_polo> I dunno about subinterpreters. I'm not looking for efficiency, though, I'm looking for maximum isolation for a limited grouping of tests.

[04:37:16] <techalchemy> then spawning a subprocess might be best

[04:37:17] <toad_polo> Mock is not the right solution here. It's tightly coupled to implementation.

[04:37:49] <toad_polo> And this is the kind of thing that erroneously passes when your clever solution fails.

[04:38:17] <techalchemy> i dont know what you're talking about i've never seeen anything like that :p

[05:00:01] <techalchemy> hrm i wonder how close pycon is to selling out, i need to buy a ticket tomorrow i think

[05:29:48] <cooperlees> toad_polo: Where can I fix something for Australia in the stdlib? :D

[05:30:07] <cooperlees> I've been head down - But I got all the tests to pass - fuck what a marathon.

[05:30:22] <cooperlees> I went back to making objects and having mock use them

[05:31:05] <cooperlees> Now it's battle black + lints ... haha

[05:31:38] <cooperlees> techalchemy: You will love it - I'm removing requests for aiohttp: https://travis-ci.org/pypa/bandersnatch/builds/654261877

[14:28:01] <xafer> Hello, has anyone an idea why https://certifi.io redirects to pip documentation ?

[14:50:55] <techalchemy> omg cooperlees that's amazing

[14:50:58] <techalchemy> thanks for doing that

[14:52:20] <cooperlees> Now we can aio-s3 ... there is aioboto etc.

[14:52:31] <cooperlees> techalchemy: ^^

[14:53:52] <cooperlees> I’ll clean up the lint and some unit tests ...

[14:54:03] <cooperlees> Then up the mypy strictness

[14:54:21] <cooperlees> Then some other things I want to cleanup for 4.0

[16:46:36] <cooperlees> If anyone is asyncio / aiohttp familiar - Would love a review for clownery on https://github.com/pypa/bandersnatch/pull/440

[22:08:34] <travis-ci> pypa/twine#1310 (master - fb03835 : Brian Rutledge): The build was broken.

[22:08:34] <travis-ci> Change view : https://github.com/pypa/twine/compare/613a6f641fdefb815f6ad9cd20ee98220c5529c5...fb03835ebf124ed2f9a447a5f0bd607c283172fb

[22:08:34] <travis-ci> Build details : https://travis-ci.org/pypa/twine/builds/654636406

[22:52:35] <k4vej> Just packaged my first lib as a wheel (private use only, not published to pypi or anything fancy like that), was surprised at the lack of specificity of python-tag in the resultant wheel - defaulting simply to py3 despite the source making use of features only available in 3.6+

[22:54:18] <k4vej> Seems a bit lame to force the maintainer to manually supply the python-tag, would have thought with some static analysis, determining this would be relatively straight forward. Thoughts...