.type() no longer exists?

[GoogleCodeExporter]

Describe the problem.
trying to obtain the "type" of class a PyNode is doesn't work anymore.

What Version of Maya are you using? Maya 2009

On what operating system? (be as specific as possible and include service
packs, 64bit vs 32bit, etc)
Windows 7 Ultimate 64-bit

What Version of PyMEL are you using? 1.0.0 rc1

What is the expected output? What do you see instead?

all pymel objects (and data types) should have a method called type(), not
just DagNodes.

# EXAMPLE WORKS WITH DAG OBJECTS
import pymel.all as pm
blah = pm.sphere()[0]
blah.type()
# Result: transform # 

# FAILS WITH VECTOR
vec = pm.datatypes.Vector([1.0,0.0,0.0])
vec.type()

# Error: type
# Traceback (most recent call last):
#   File "<maya console>", line 2, in <module>
#   File
"C:\engserv\rbuild\195\build\wrk\optim\runTime\Python\Lib\site-packages\maya\Ope
nMaya.py",
line 8229, in <lambda>
#   File
"C:\engserv\rbuild\195\build\wrk\optim\runTime\Python\Lib\site-packages\maya\Ope
nMaya.py",
line 34, in _swig_getattr
# AttributeError: type # 

# TYPE SHOULD RETURN THIS FOR ALL OBJECTS
vec.__class__.__name__
# Result: Vector # 

Original issue reported on code.google.com by geordiem...@gmail.com on 20 Mar 2010 at 9:27

[GoogleCodeExporter]

title is misleading. should be for non-dag objects, .type() seems to be missing 
now.

Original comment by geordiem...@gmail.com on 20 Mar 2010 at 9:29

[GoogleCodeExporter]

i'm not sure i agree with you here.  node classes have a type because this type 
refers to 
the internal names that maya.cmds uses.  the type method is like the command 
cmds.nodeType().  most data types don't have a maya.cmds equivalent: 
BoundingBox, 
Time, Angle, Quaternion, etc.  if you want to check the type of a data instance 
just use 
isinstance(x, dt.Vector)

-chad

Original comment by chad...@gmail.com on 20 Mar 2010 at 10:24

[GoogleCodeExporter]

i don't believe that Vector ever had a type() method.  maybe in 0.7, but i 
don't think so.

-chad

Original comment by chad...@gmail.com on 20 Mar 2010 at 10:25

[GoogleCodeExporter]

I guess I could always .__class__.__name__ to get what used to be type() in 0.7
we use a version of 0.7 at IMD.  

it was often helpful when developing code at IMD to determine if the return 
value
type from some other departments code.

example. the database could return was a path object, a PDO object, or a string 
to
know what it was and what you could do with it. but if some other department 
wrapped
the return object -- one way to find out what the return obj was was to use 
.type()
to find out what it was.

It seems useful to me to have a .type() for every object, not just MEL wrapped 
ones. 

Original comment by geordiem...@gmail.com on 20 Mar 2010 at 11:02

[GoogleCodeExporter]

ah, now i see why i'm getting such a blast from the past.  you guys at IMD have 
been 
on the 0.7 line for awhile, and now you're upgrading to 1.0.  there have been a 
lot of 
changes since 0.7, but where we broke backward compatibility we did so with 
only 
after great consideration.  for example, datatypes and nodetypes have their own 
namespaces to prevent clashes (Time data type and Time node, for example).  the 
addition of custom nodes makes this even more possible (someone could easily 
make 
a "vector" node, which would create another Vector class).  

in this case, DependNode.type() means "what is the maya type of this node?"  
and 
Attribute.type() means "what is the type of data stored by this attribute?".  
these are 
both maya-specific meanings that are very different in meaning from a 
Vector.type() 
or a Matrix.type() that returns the name of the python class.  this would 
create an 
inconsistency in meaning -- one set of type() methods being maya-specific, 
while 
the other set are for python in general. you're right that 
Vector.__class__.__name__ is 
the info you are looking for, but wrong in the implication that 
DependNode.type() 
and DependNode.__class__.__name__ are the same data.  sure, it might be handy 
if 
everything in python had a type() method, but until guido decides to put this 
on the 
`object` class, i'm going to keep using object.__class__.__name__.

Original comment by chad...@gmail.com on 21 Mar 2010 at 5:53

[GoogleCodeExporter]

Awesome explanation Chadrik. it all makes sense now. I hadn't considered the 
.type
for attr issue at all... 
Since IMD is shutting down decided it's a good time to adopt the new syntax 
asap. Thanks!

Geordie

Original comment by geordiem...@gmail.com on 21 Mar 2010 at 9:11

[GoogleCodeExporter]

Original comment by chad...@gmail.com on 25 Mar 2010 at 5:43

• Changed state: WontFix