Phil Elson
Phil Elson
> The jpype startup pattern predates me by a lot. I have studied other packages, but unfortunately they all have similar problems. The main issue is that Python does not...
> Any thoughts on the deferred module loading as a solution? The ``when`` statement is a neat idea. It has some curious side-effects though, and I can imagine it being...
I wanted to round off the ideas that are flying around with a couple of simple examples. In each case I don't explicitly state where the JVM starts because it...
> Radical solution... make JClass and JPackage have the same memory layout. Then we can make them do mock behavior until the jvm is started. Then we check which are...
> Proxing has some big speed implications over a morph. There are a lot of implications with referencing as the typing model for isinstance would have major implications. This is...
Some great detail here, thank you! > When I switched to a dedicated slot, it was much faster. Indeed, I could have updated the prototype to use ``__slots__`` (and morph...
I posted a tweak to the branch in https://github.com/Thrameos/jpype/pull/55. In there @Thrameos [said](https://github.com/Thrameos/jpype/pull/55#issuecomment-779913616): > So assuming we can port this in a C implementation with morphs for most field types...
> If it appears reasonable that I can start cutting code on the morphing which will change it from pure Python to actually mucking with the CPython internals. That will...
> Does that clear it up? Definitely, thank you! Though I have one follow-up one (sorry!) since this isn't about performance and more about fiddling with the underlying object pointers:...
Perhaps register ``jpype`` ASAP, and make it depend on ``jpype1`` (or the inverse)? Or even just raise an exception in the ``setup.py`` of the name you don't want. There is...