Christopher Rowley

Could also export e.g. `pyconvert_int(T, x)` as essentially `pyconvert_rule(T, Val(Symbol("builtins.int")), x)` (actually it runs up the whole MRO for the type) for when you know what you have. Could also...

The rationale for the current ordering is to prevent packages from overriding rules from upstream packages - in particular the rules in PythonCall itself. For example, it is documented API...

> I don't think that would be enough because if package A defines `pyconvert(A.MyAbstractVector, some_list)` and later definitions take priority, then `pyconvert(AbstractVector, some_list)` will return an `A.MyAbstractVector`. The alternatives I...

I like this. I need to think about it. Also, we have diverged quite a way from the original issue.

[see here](https://juliapy.github.io/PythonCall.jl/stable/faq/#Is-PythonCall/JuliaCall-thread-safe?) for a bit more context on @MilesCranmer's comment

Yes indeed, the issue is that in Python stdout has a large buffer by default (unless it's an interactive session and it line buffers too) which isn't being flushed as...

If you do `%load_ext juliacall.ipython` first then it will work. I had never tried it from VSCode before, but am happy to see that it does! https://cjdoris.github.io/PythonCall.jl/dev/compat/#IPython (It's only in...

Turns out what I had implemented was pretty hacky. It's much better now, I've made a release, it certainly seems to be much better in VSCode now.

Yeah, that's because in Julia you can't (reliably) replace stdout in Julia, you can only redirect it, and that needs to happen asynchronously, so anything printed to stdout from Julia...

That seems reasonable - if we also provide a mechanism (env var) to turn this behaviour off.