Absolultely confused...

[Jeremy Moles]

So, here is my relevant code:

PyArg_ParseTuple(args, "O!", &PyType_vector3d, &arg1)

And here ismy error message:

argument 1 must be pylf.core.vector3d, not pylf.core.vector3d

I know PyType_vector3d "works" (as I can use them in the interpreter all
day long), and I know I'm passing a pylf.core.vector3d (well, apparently
not...)

I've spent hours and hours on this and I'm finally just giving up and
asking. I've tried everything to get my program to verify that arg1 is
really a PyType_vector3d, but to no avail.

If I take out the "!" in the format string and just use "O", I can at
least get past PyArg_ParseTuple. Then I try something like...

PyObject_TypeCheck(arg1, &PyType_vector3d)

Which also fails, but I know for a fact that arg1's PyObject_Repr is
what it should be. (pylf.core.vector3d)

I guess my question is: what in the world could be causing this to fail?
It seems like I'm just not able to use ParseType or BuildValue to create
objects of my own type.

I know I haven't provided a lot of information, but does anyone have any
ideas or where I should start looking?

 

[Jeremy Moles]

All of these are runtime errors. Using GCC4 and compiling perfectly with
-Wall.

 

[Jeremy Moles]

Thanks for the reply.

I may be missing something critical here, but I don't exactly grok what
you're saying; how is it even possible to have two instances of
PyType_vector3d? It is (like all the examples show and all the extension
modules I've done in the past) a static structure declared and assigned
to all at once, only once.

Am I misunderstanding the point?

/me ducks

 

[Jeremy Moles]

Well, there's certainly no doubting that all of you are right. I guess
now I need to track down how this is happening and either fix it or
understand it so that I can explain why I'm having to work around it.

Many, many thanks.

 

[Brandon K]

If I take out the "!" in the format string and just use "O", I can at
least get past PyArg_ParseTuple.

Is this a compile-time error? Or a runtime error?



----== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups ==----
Get Anonymous, Uncensored, Access to West and East Coast Server Farms!
----== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==----

 

[Thomas Heller]

So, here is my relevant code:

PyArg_ParseTuple(args, "O!", &PyType_vector3d, &arg1)

And here ismy error message:

argument 1 must be pylf.core.vector3d, not pylf.core.vector3d

I know PyType_vector3d "works" (as I can use them in the interpreter all
day long), and I know I'm passing a pylf.core.vector3d (well, apparently
not...)

I've spent hours and hours on this and I'm finally just giving up and
asking. I've tried everything to get my program to verify that arg1 is
really a PyType_vector3d, but to no avail.

If I take out the "!" in the format string and just use "O", I can at
least get past PyArg_ParseTuple. Then I try something like...

PyObject_TypeCheck(arg1, &PyType_vector3d)

Which also fails, but I know for a fact that arg1's PyObject_Repr is
what it should be. (pylf.core.vector3d)

I guess my question is: what in the world could be causing this to fail?
It seems like I'm just not able to use ParseType or BuildValue to create
objects of my own type.

I know I haven't provided a lot of information, but does anyone have any
ideas or where I should start looking?

Can it be that you have TWO instances of the pylf.core.vector3d object?
Debugging should reveal it...

Thomas

 

[Daniel Dittmar]

So, here is my relevant code:

PyArg_ParseTuple(args, "O!", &PyType_vector3d, &arg1)

And here ismy error message:

argument 1 must be pylf.core.vector3d, not pylf.core.vector3d

It looks as if two PyType_vector3d exist in your system
- the one that created the object passed to your routine
- the one in your extension code

As PyType_vector3d probably comes from a shared object/DLL
- does your code accesses really the same shared object that is also
loaded by the Python interpreter? It could be that you linked with a
specific file, but Python loads something different from $PYTHONPATH
- on Windows, you couldn't simply import a variable from a DLL, you had
to call a special routine to get the pointer

One possible portable solution: in your module initialization
- import pylf.core
- create an object of type vector3d
- use your knowledge about the inner structure of Python objects and get
the pointer to the PyType from the object
- store it in a module static variable TypeVector3D
- pass that variable to PyArg_ParseTuple

Browse the Python Extension API, maybe partts or all of this are already
available.

There's still a problem left when pylf.core gets reloaded (rare, but
possible). I assume the shared object also gets reloaded, which means
that the type objects gets loaded to a new address and PyArg_ParseTuple
will complain again. I'm not sure if there is a solution to this,
because there still could be objects create from the old module.

Maybe you should just check the type yourself by comparing the class
names buried in the PyType. You could cache one or two type pointers to
speed this up.

Daniel

 

[Thomas Heller]

Thanks for the reply.

I may be missing something critical here, but I don't exactly grok what
you're saying; how is it even possible to have two instances of
PyType_vector3d? It is (like all the examples show and all the extension
modules I've done in the past) a static structure declared and assigned
to all at once, only once.

Am I misunderstanding the point?

/me ducks

The only reason that I can think of for this error message is that the
type of the argument is something that has a repr of
'pylf.core.vector3d', but the type object is not the same as your
'PyType_vector3d' pointer. As I said, use a source debugger or some
other way to find out, or use a debug build of Python and step through
the PyArg_ParseTuple code to find out why the call fails.

Thomas

 

[Tim Peters]

[Jeremy Moles]

...
I may be missing something critical here, but I don't exactly grok what
you're saying; how is it even possible to have two instances of
PyType_vector3d? It is (like all the examples show and all the extension
modules I've done in the past) a static structure declared and assigned
to all at once, only once.

The most common cause is inconsistent import statements, with one
place using package-relative import but another place explicitly
specifying the package. Here's a simple pure Python example, with
this directory structure:

playground/
package_dir/
__init__.py
source.py
module.py

__init__.py is empty; it just serves to make `package_dir` a package.

source.py defines a single type, named Type:

class Type(object):
pass

module.py imports source.Type in two different ways, then prints various stuff:

from source import Type as one_way # package-relative import
from package_dir.source import Type as another_way

print one_way is another_way
print one_way.__name__, another_way.__name__
print repr(one_way), repr(another_way)

import sys
for k, v in sys.modules.items():
if "source" in k:
print k, v

Now _from_ playground, run module.py:

python playground/module.py

This is the output, with annotations; I ran this on Windows, so expect
to see backslashes <wink>:

False

That is, one_way is not the same object as another_way: there are two
distinct instances of the Type object.

Type Type

Although they're distinct, they have the same __name__, "Type".

<class 'source.Type'> <class 'package_dir.source.Type'>

Their reprs differ, though, showing the path via which they were imported.

source <module 'source' from 'C:\playground\package_dir\source.pyc'>
package_dir.source <module 'package_dir.source'
from 'C:\playground\package_dir\source.pyc'>

That's two lines of output from crawling over sys.modules: there are
two distinct instances of the entire `source` module. That's the real
cause of the multiple `Type` instances.

package-relative import is rarely a good idea. Are you doing that anywhere?