Absolultely confused...

[Jeremy Moles]

So, here is my relevant code:

PyArg_ParseTupl e(args, "O!", &PyType_vector3 d, &arg1)

And here ismy error message:

argument 1 must be pylf.core.vecto r3d, not pylf.core.vecto r3d

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.vecto r3d (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_ParseTupl e. Then I try something like...

PyObject_TypeCh eck(arg1, &PyType_vector3 d)

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

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?

[Brandon K]

Re: Absolultely confused...

[color=blue]
> If I take out the "!" in the format string and just use "O", I can at
> least get past PyArg_ParseTupl e.[/color]

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 ==----

[Jeremy Moles]

Re: Absolultely confused...

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

On Thu, 2005-10-06 at 09:12 -0500, Brandon K wrote:[color=blue][color=green]
> > If I take out the "!" in the format string and just use "O", I can at
> > least get past PyArg_ParseTupl e.[/color]
>
> 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 ==----
>
>[/color]

[Thomas Heller]

Re: Absolultely confused...

Jeremy Moles <jeremy@emperor linux.com> writes:
[color=blue]
> So, here is my relevant code:
>
> PyArg_ParseTupl e(args, "O!", &PyType_vector3 d, &arg1)
>
> And here ismy error message:
>
> argument 1 must be pylf.core.vecto r3d, not pylf.core.vecto r3d
>
> 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.vecto r3d (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_ParseTupl e. Then I try something like...
>
> PyObject_TypeCh eck(arg1, &PyType_vector3 d)
>
> Which also fails, but I know for a fact that arg1's PyObject_Repr is
> what it should be. (pylf.core.vect or3d)
>
> 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?[/color]

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

Thomas

[Jeremy Moles]

Re: Absolultely confused...

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 misunderstandin g the point? :)

/me ducks

On Thu, 2005-10-06 at 16:26 +0200, Thomas Heller wrote:[color=blue]
> Jeremy Moles <jeremy@emperor linux.com> writes:
>[color=green]
> > So, here is my relevant code:
> >
> > PyArg_ParseTupl e(args, "O!", &PyType_vector3 d, &arg1)
> >
> > And here ismy error message:
> >
> > argument 1 must be pylf.core.vecto r3d, not pylf.core.vecto r3d
> >
> > 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.vecto r3d (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_ParseTupl e. Then I try something like...
> >
> > PyObject_TypeCh eck(arg1, &PyType_vector3 d)
> >
> > Which also fails, but I know for a fact that arg1's PyObject_Repr is
> > what it should be. (pylf.core.vect or3d)
> >
> > 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?[/color]
>
> Can it be that you have TWO instances of the pylf.core.vecto r3d object?
> Debugging should reveal it...
>
> Thomas[/color]

[Thomas Heller]

Re: Absolultely confused...

Jeremy Moles <jeremy@emperor linux.com> writes:
[color=blue]
> 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 misunderstandin g the point? :)
>
> /me ducks
>
> On Thu, 2005-10-06 at 16:26 +0200, Thomas Heller wrote:[color=green]
>> Jeremy Moles <jeremy@emperor linux.com> writes:
>>[color=darkred]
>> > So, here is my relevant code:
>> >
>> > PyArg_ParseTupl e(args, "O!", &PyType_vector3 d, &arg1)
>> >
>> > And here ismy error message:
>> >
>> > argument 1 must be pylf.core.vecto r3d, not pylf.core.vecto r3d
>> >[/color][/color][/color]

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.vect or3d', but the type object is not the same as your
'PyType_vector3 d' 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_ParseTupl e code to find out why the call fails.

Thomas

[Daniel Dittmar]

Re: Absolultely confused...

Jeremy Moles wrote:[color=blue]
> So, here is my relevant code:
>
> PyArg_ParseTupl e(args, "O!", &PyType_vector3 d, &arg1)
>
> And here ismy error message:
>
> argument 1 must be pylf.core.vecto r3d, not pylf.core.vecto r3d
>[/color]

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_ParseTupl e

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_ParseTupl e
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

[Jeremy Moles]

Re: Absolultely confused...

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. :)

On Thu, 2005-10-06 at 16:48 +0200, Daniel Dittmar wrote:[color=blue]
> Jeremy Moles wrote:[color=green]
> > So, here is my relevant code:
> >
> > PyArg_ParseTupl e(args, "O!", &PyType_vector3 d, &arg1)
> >
> > And here ismy error message:
> >
> > argument 1 must be pylf.core.vecto r3d, not pylf.core.vecto r3d
> >[/color]
>
> 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_ParseTupl e
>
> 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_ParseTupl e
> 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[/color]

[Tim Peters]

Re: Absolultely confused...

[Jeremy Moles][color=blue]
> ...
> 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.[/color]

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.sou rce import Type as another_way

print one_way is another_way
print one_way.__name_ _, another_way.__n ame__
print repr(one_way), repr(another_wa y)

import sys
for k, v in sys.modules.ite ms():
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.so urce.Type'>

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

source <module 'source' from 'C:\playground\ package_dir\sou rce.pyc'>
package_dir.sou rce <module 'package_dir.so urce'
from 'C:\playground\ package_dir\sou rce.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?