15:50:28 <omwb> I finally cleaned up my PR "auto --poll" https://github.com/getnikola/nikola/pull/3757 , but now one of the tests (Python 3.12 on macos-latest) seems to take forever. (I would be surprised if that had anything to do with my change, though.) The still-uncomplete test (after 23 minutes thus far) is https://github.com/getnikola/nikola/actions/runs/7874003541/job/21482604431?pr=3757 15:52:42 <omwb> Though the test it chews on is the (somewhat new) tests/integration/test_dev_server.py . 15:58:50 <omwb> In https://github.com/getnikola/nikola/actions/runs/7680116937/job/20935494651 , the same test complained "there is no current event loop". As this is my test, I'm the culprit here. 😳 17:10:51 <omwb> Ah! I could reproduce (at least once) the "test is stuck" after installing Python 3.12 locally. I'm on it. 18:05:04 <ChrisWarrick> I’ve restarted the macOS pipeline in the meantime 18:08:00 <KwBot> [nikola] Kwpolska closed pull request #3757 (aknrdureegaesr:auto-symbolic-links): Support passing --poll to the auto plugin to better deal with symlink farms. https://github.com/getnikola/nikola/pull/3757 21:54:04 <omwb> There is a bit something to it. The "auto" uses `loop = asyncio.get_event_loop()` which, in the old days, used to automatically create an event loop if none already existed. To create an event loop in this implicit fashion is deprecated. It should still work with Python 3.12, but is deprecated and will, at some point in the future, result in an error. 21:54:04 <omwb> We really should refactor the code that requires the event loop into a coroutine function. Inside that function, the asyncio.get_running_loop() could be used to acquire the loop, if accessing the loop is really needed. 22:07:27 <omwb> Also, I see in NikolaEventHandler that `loop.call_soon_threasafe` is being called. The future returned by that should either be canceled or waited for, I think. As it stands now, it is simply being forgotten/ignored. But we should not close the loop before these futures are properly dealt with. 22:20:13 <ChrisWarrick> I agree this code could use some improvements 22:23:57 <omwb> Would you think `NikolaEventHandler` is part of the public API of Nikola, or can it be improved in a non-backwards-compatible way? 22:24:15 <ChrisWarrick> it’s not a public api at all 22:24:22 <omwb> Good news! 22:24:39 <omwb> (And also: Good night! :)) 22:24:39 <ChrisWarrick> most things in plugins are not what I would consider public api 22:24:44 <ChrisWarrick> (good night to you too!) 22:24:58 <omwb> Good to know. 22:31:41 <omwb> Ah! These event handlers live in auto's __init__.py. That makes it more clear that they are not public API. I somehow didn't notice that prior to asking. 22:31:41 <omwb> It might be worth a consideration to rename the classes to names starting with a leading underscore. 22:34:24 <ChrisWarrick> are underscores for class names popular? 22:39:51 <omwb> Yes - with me. :-D. Not entirely sure, but the underscores are generally symbolizing that something is internal in Python. Judge yourself: 22:39:51 <omwb> andreas@meise:~/comp/nikola/venv 22:39:51 <omwb> $ find . -type f -name \*.py -print0 | xargs -0r grep -P '^\s*class\s' | wc -l 22:39:51 <omwb> 10492 22:39:51 <omwb> andreas@meise:~/comp/nikola/venv 22:39:52 <omwb> $ find . -type f -name \*.py -print0 | xargs -0r grep -P '^\s*class\s\_' | wc -l 22:39:52 <omwb> 775 22:40:36 <ChrisWarrick> doesn’t seem to be popular 22:41:35 <omwb> So a meager 7.4% of classes use that convention. - It is a bit unclear: How popular are classes for stuff that's needed internally in the first place, in Python?