Antonio Cuni

> It does look like it's being called twice (and it's a bug). Still, it's something that will be taken care as part of the bigger redesign work in https://github.com/pyscript/pyscript/issues/622...

> I talked to @antocuni about it and agree with redesigning it as part of #622 efforts. @marimeireles make sure to add the relevant tests ;)

> This adds gnu readline. This should in principle allow us to match the normal Python repl behavior (which relies on readline). I'm confused: how can it possibly work? If...

> > how can it possibly work? > > The short answer is it probably can't work reasonably without stack switching. ok, this also matches my intuition/understanding. > With great...

Unfortunately the original branch has conflicts with the `develop` branch of p4a. I rebased it on top of the latest version (6ed70232) and published the rebased branch here: https://github.com/antocuni/python-for-android/tree/fileprovider-rebased See...

> Up until the callback is scheduled, there's no place where the hub would be keeping such a Queue or the consumer greenlet alive. The references to it are contained...

> Even if there were, and it didn't add any overhead at all, I'm not sure that's a good idea. That would be changing "by chance" behaviour into "supported" behaviour....

> I need to figure out why that is (and that probably involves writing the pure-greenlet test case). So, you were correct: I managed to write a minimal pure-greenlet test...

> I think I'm convinced that it would be good to move this from the "by chance" category to the "explicitly designed" category. I think that probably is something like...

attaching stderr [stderr.zip](https://github.com/gphoto/libgphoto2/files/7796703/stderr.zip)