Skip to content

uctypes: Getting (numeric) value of uctypes.PTR object #4084

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
pfalcon opened this issue Aug 29, 2018 · 5 comments
Closed

uctypes: Getting (numeric) value of uctypes.PTR object #4084

pfalcon opened this issue Aug 29, 2018 · 5 comments

Comments

@pfalcon
Copy link
Contributor

pfalcon commented Aug 29, 2018

uctypes has a few whitespots/goofs which need to be fixed, most of them are more or less clear, but here's one which needs discussion trail.

So, if there's a uctypes object of type uctypes.PTR (apparently gotten as a field of a structure), how to get its (i.e. address it points to) as integer? That's currently not supported. Ideas are:

(Let the s being containing structure and ptr a pointer field in it.)

  1. Apply int to it: int(s.ptr).
  2. Abuse and redefine uctypes.addressof() for PTR type: instead of returning address of a field, in case of specifically a pointer, it will return contents of a field.
  3. A completely adhoc solution of adding a method or attribute to uctypes type, just for this case of pointer (doesn't seem to be needed for anything else). s.ptr.val or s.ptr.value().

Discussion:

  1. int() seems like the most natural way. But we don't support conversion of an arbitrary object to int, which should be done by __int__ special method, we have No int conversion for int-derived types available #1782 on that.
  2. This seems like the quickest "hack-hack" solution. But it makes pointers even more confusing for layman people (which means it will bite "pros" from time to time too), and directly violates upstream semantics: https://docs.python.org/3.7/library/ctypes.html#ctypes.addressof . There're no exceptions for pointer types in that short description (though who knows how it really works).
  3. As written, adhoc, and rather given that uctypes' goal is to follow C syntax as closely as possible and avoid adding adhoc things to it.
@pfalcon
Copy link
Contributor Author

pfalcon commented Aug 29, 2018

So, by now, I guess I discounted p.2 completely, it's just not worth going for such hacks.

And I lean towards p.1. That's definitely cleaner and easier to grasp. P.1 may seem surprising, given my firm anti-bloat position, but actually, it's pretty logical too: there wouldn't be too much code difference implementing p.1 and p.3, but p.1 may benefit more code. That however would be user code, as I can't imagine what else could use __int__ in builtin modules.

However, one concern re: anti-bloat is that adding of support for __int__ may be a pandora box: then there will be a cry for __index__, then __trunc__, then __float__, then __complex__, etc. Well, the same logic should be applied: are there compelling usecases in the mainline modules? If not, it's on the part of the user code to adjust. (And as usual, anything can be implemented, ifdef'ed, default off, number of config options kept under control too (and nor implementing something is one of the way to keep that number under control)).

@pfalcon
Copy link
Contributor Author

pfalcon commented Aug 29, 2018

Besides, the right way to do it is apparently not to go to look up __int__, but have MP_UNARY_OP_INT, as usual.

@pfalcon
Copy link
Contributor Author

pfalcon commented Aug 29, 2018

MP_UNARY_OP_INT, as usual.

In this regard, one of the way to implement getting a numeric value without any infra changes would be to use MP_UNARY_OP_POSITIVE: +s.ptr. But that's too magical.

Besides, at the conception of uctypes, I pondered of overriding unary plus as a means of dereferencing a pointer, so +s.ptr would be analog of C's *s.ptr. But again, that's far too magical. Given the alternative of s.ptr[0], which is immediately understood by both C and Python programmers, the idea of using unary + for dereferencing for rejected. I guess, using it for getting a numeric value should be rejected too.

@pfalcon
Copy link
Contributor Author

pfalcon commented Aug 31, 2018

Patch for __int__ posted: #4088

@dpgeorge
Copy link
Member

The above PR was merged.

tannewt pushed a commit to tannewt/circuitpython that referenced this issue Feb 2, 2021
@dhalbert
Merge pull request micropython#4084 from jepler/default-serpentine
f6f007a 
RGBMatrix: change default to serpentine=True
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pfalcon @dpgeorge