views:

122

answers:

1

If I'm trying to overload an embedded Python function so that the second argument can be a long or an Object, is there a standard way to do it? Is this it?

What I'm trying now (names changed to protect the innocent):

  bool UseLongVar2 = true;
  if (!PyArg_ParseTuple(args, "ll:foo", &LongVar1, &LongVar2))
  {
      PyErr_Clear();
      if (!PyArg_ParseTuple(args, "lO&:foo", &LongVar1, convertObject, &Object))
      {
         UseLongVar2 = false;
         return NULL;
      }
  }
+1  A: 

What I normally do is have two C functions that take the different arguments. The "python-facing" function's job is to parse out the arguments, call the appropriate C function, and build the return value if any.

This is pretty common when, for example, you want to allow both byte and Unicode strings.

Ryan Ginstrom
How does that differ from what I'm doing here? After the example code I can say something along the lines of "result = UseLongVar2 ? fooLong(LongVar1, LongVar2) : fooObj(LongVar1, Object)"?
patros
Just to clarify: I'm interested in how to tell which types of arguments were passed from Python. Is there something better than PyArg_ParseTuple, or is there a cleaner shorthand for separating out different types of variable. The construct I'm using would be completely hideous for even a few arguments that could have 2 or 3 possible types.
patros
This is different because with your way, you're doing two tests. First the test to see if it passed, and then later you'll have to test the flags you set to see which arguments to parse. With the way I outlined, you only do one test. And no, I don't think that there's a cleaner way to check what args you got. Another good reason to keep the arguments in C extensions simple.
Ryan Ginstrom
You didn't outline what structure you use to parse out the arguments.
patros