a more Pythonic binding

[aquynh]

a proposal for a more Pythonic binding was posted on Twitter at https://gist.github.com/moyix/669344f534c83e0704e0 - by @moyix.

this looks cool. @JonathonReinhart, is this similar to what you plan to propose?

[JonathonReinhart]

Yes, that is nearly identical to what I was planning, right down to the ability to use slices to access target memory. I like it!

[lunixbochs]

I think register names should be lowercase here

[cforger]

What is the story on this? The code looks good, it runs without error. What is needed to move it forward?

I also agree with keeping the registers lower case.

[aquynh]

even if nothing is missing, we are still looking forward to the pull request :-)

on the register name: why keeping them in lower case, while we have UC_ARCH_X86?

[lunixbochs]

because all-caps attributes are not pythonic

[cforger]

Well two reasons:

1. The registers are variable, we'll change the values, so that's usually lower, where UC_ARCH_* isn't being changed (at least that's what I'm seeing so far), so it can be a const and in caps.

2. Other Emu's use the same convention.. but I'd be damned if I can find them now. :)

[cforger]

Re: pull request

It's been 3 months, so that may be the best we're going to get.

Was the idea for this to replace the current binding? It's currently importing much of what it needs from the existing binding, which is an improvement, but needs cleanup.

If no one feels that the new binding is on the way anytime soon, I can create it using this code as the base idea, replacing the existing binding, and referencing moyix's contribution.

[lunixbochs]

I feel that this should not completely replace the current Python bindings.

If nothing else, it adds significant overhead to the current bindings, which is already very noticeable when doing much register access.

Test case: https://bochs.info/p/f48ma

$ python test.py 
magic: 2.89082503319
native: 1.85509109497
$ python test.py 
magic: 3.02654600143
native: 1.85136508942
$ python test.py 
magic: 2.88477110863
native: 1.84552502632

[aquynh]

it is better to keep the old interface, but not replace it, so all the existing apps do not need to be rewritten.

on the performance, we should find all the problems, so we can either fix them, or document the issues.

[cforger]

I can probably get those test times closer together.

So: create a new binding, keep the old for compatibility and speed, and eventually switch as people find the new binding better?

[aquynh]

yes please. even though i dont think we will ever get rid the current interface due to backward compatibility reason.