Writing a CPython extension - calling another sibbling method ?

[R.Wieser]

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