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 -- https://mail.python.org/mailman/listinfo/python-list
