I'm not sure this is a good idea in general. One example that springs to mind is pickling; another is that it may tend to produce very confusingrepr results. Why would we want to do this?

If this is something that's for very specialized use-cases, perhaps that would be better served in the hook functions for the module? (See below for some general comments about underscore-prefixed things.)

Reviewing#1447 I see that pickling was specifically mentioned as the motivation for this. I'm still not convinced, I'd need to see a specific example to understand what problem this solves that can't be solved by the object itself.

I was concerned about this extra import either leading to more imports that might cause issue with monkey-patching, or with it taking time for cases that we might not need it.

But on Python 3, it's imported by default anyway during startup, so those are completely moot.

On Python 2, it's a trivial file with no imports besidessys.

In the tradition of 'explicit is better than implicit', it would probably be better to make this a required argument instead of defaulting.

Instead of an extra argument, what ifname was required to be the fully-qualified name instead of the simple module name? That would allow patches that consist only of a module, not a package. (With a small amount of work, that could generalize to allowing arbitrary objects to be the patch source.)

I have no problem with any aesthetic API changes (argument requirement, order, naming, refactoring).

Probably better namedsource_module at this point.

I have no problem with any aesthetic API changes (argument requirement, order, naming, refactoring).

This function doesn't seem to be used here.

Here's my general philosophy about the underscore prefixed functions and arguments in this module: They're an implementation detail, subject to change. (That's obvious.) But we also know that, as external plugins get going, until we feel ready to publish some sort of official monkey-patching API, they'll be used outside the gevent package. If functionality that gevent itself doesn't use is only used by those external plugins, its much more likely that that functionality is going to break in a way that is not caught by the gevent tests, or be refactored away without planning too. So it's best to keep the implementation details to a minimum and be sure that gevent has a use-case for them all.

In this case, it looks like it would be easy to make_check_repatching use this function.

This function is supposed to be used externally by plugins. I was hesitant to make it public, but then again maybe I should've.

I have no problem with any aesthetic API changes (argument requirement, order, naming, refactoring).

It's not clear to me what difference this makes. Could you clarify please? It may be missing a test case, or perhaps that's the reason for the broken test.

Oh. Silly me. I just reviewed#1447 and see where the problem was mentioned. So this either is the reason for the test failure, or it definitely needs a specific test.