Move __name__ mangling to end of module#156
Conversation
bf6815d to
c513420
Compare
|
Ah, I see these CI failures are already addressed in #155, I'll rebase once that lands |
|
Given the MacOS testing failures that affected #155, and which got fixed externally (seems like a Mac test environment problem in GHA that was present for a couple of days), I re-ran the failed Mac test for this PR. Indeed, it succeeds. |
|
Hey @noahbkim, it looks like that was the first time we merged one of your PRs! Thanks so much! 🎉 🎂 If you want to keep contributing, we'd love to have you. So, I just sent you an invitation to join the python-trio organization on Github! If you accept, then here's what will happen:
If you want to read more, here's the relevant section in our contributing guide. Alternatively, you're free to decline or ignore the invitation. You'll still be able to contribute as much or as little as you like, and I won't hassle you about joining again. But if you ever change your mind, just let us know and we'll send another invitation. We'd love to have you, but more importantly we want you to do whatever's best for you. If you have any questions, well... I am just a humble Python script, so I probably can't help. But please do post a comment here, or in our chat, or on our forum, whatever's easiest, and someone will help you out! |
Changing
__name__in the middle of the module causes subsequent definitions to have the mangled (and therefore incorrect)__module__, which causes a bad interaction withcloudpickle(which in turn needs to ensure pickled functions can be imported from their__module__). Moving the__name__change to the end of the module satisfies theDeprecationWarningcheck while sidestepping the above.