Writing a CPython extension - calling another sibbling method ?
R.Wieser
address at not.available
Wed Nov 20 04:02:48 EST 2019
Michael,
> If you mentioned RPi.GPIO before, I apologize for my mistake.
No I didn't, there is nothing to apologize for.
> That's very helpful to know.
I have no clue to why it would be, as my question has got *zero* to do with
it - its valid for /any/ extension using the CPython C API. Just look at
the "this is what I'm using" code in my previous message.
> If I knew what the pin naming scheme was (how do you use it from python?)
:-) You can't (use it from python). That was the whole problem I started
with. Its simply not exposed to the user.
> But I thought, and remain convinced, that there were probably other
> ways of solving it that didn't involve mucking with C code.
I already asked that question in "comp.sys.raspberry-py", in a thread named
"Accessing GPIO pins using the two different numering schemes (BCM and
BOARD) at the same time ?".
You know what most of the answers boiled down to ? 'Use another extension'.
Most likely well-ment, but not something I tend to accept/do before doing an
in-depth search for possibilities (for multiple reasons, also stated there).
> You mentioned you're working with RPi.GPIO, so why not just use the
> real function names in your questions?
Because my question was-and-is not about that extension. Its as simple as
that. And ofcourse because I did not want yet another "just use a different
entextension" slew of non-answers (once bitten, twice shy).
> After grepping I've determined that you are really wanting to work
> with the C function py_output_gpio().
That one, and a number of others that cannot be used before & get locked
into place by the "py_setmode()" call.
> Why not just say that? Doesn't take very much extra time but will
> get more people willing to respond who might know.
See above: My experience tells me that I would have gotten a jumble of
people who would just tell me to forget about my question and use something
completely different - possibly stopping someone from posting the answer I
needed. Yep, that latter part is the other side of your coin.
Part of the problem might also be that I am here to enjoy the journey, with
the goal as a kind of extra. Heck, everytime I reach a goal I need to find
myself another journey ... :-)
>That "int ExtraArg" bit looks a bit strange; I thought everything that
> was exposed to the Python side of things had to be wrapped in
> PyObject. Guess I'm wrong?
Yes, it did and still does look a bit strange, and I was even worse off: I
somehow assumed that a PyObject method would only accept a single argument,
hence my question to how to prepend that "foo" string to the origional one.
But with me being me I also tried to transfer the PyObject containing that
"foo" string by itself as a second argument, and it worked. Score one, and
much easier to work with.
Than I simply tried to replace that PyObject string with a C-style argument.
Which also worked and made the solution even simpler. Score two.
Changing "foo" into a numeric argument was just the last step - all I needed
to transfer was either the BCM or BOARD constants. And that was "game over".
Regards,
Rudy Wieser
More information about the Python-list
mailing list