What follows is all my hazy recollection. If memory serves, the answer was this, although obviously if you ask RMS you get slightly different answers depending: you have to GPL your code (if you distribute it) if you link to GPL code. If you can plausibly link to several different libraries, not all of which are GPL, you don't. So when readline was alone in the world, everything that used it had to be GPL. The BSD folks wrote editline specifically to avoid this--initially, editline was extremely lame compared to readline and I think might still be, but because the API was equivalent they could say "We're BSD licensed through and through; use our code for anything you want" and still have a non-horrible CLI and yet at link time decide to use the good library.
I think the reason this works legally, although I'm not a lawyer, is because yes, when you link your program with readline that executable cannot be distributed except under the terms of the GPL. Because you have multiple potential targets for this sort of thing, nobody can argue that you are trying to technically evade the requirements.
But apparently this is still contentious.
Sometime last year, I saw an article claiming that because of libedit's existence, we could all link against readline from whatever we wanted (or at least that this showed that the dynamic-linking-is-deriving was crap), but I can't find the article now.
Does the answer change if foo.py does not ship with bar.py, but nonetheless requires foo.py to function? Does the answer change if foo.py does not ship with bar.py and does not require its presence to function?
If GPL foo.py is the only library that can fill that void, then sure, once your app runs a code path that takes it through foo.py, it's a derivative work. But what something else could fill that void?
For instance, what would happen if Editline exposed a Readline compatibility layer?