Help Me To Take A Look This Code! In Class

[liuguanghui]

import maya.cmds as cmds

class testC():

def printV(self,value):
	print value

def cbc(self,*args):
	for i in range(5):
		cmds.button(l=str(i),w=100,c=lambda *args:self.printV(i))

def mainCom(self):
	vvv = "nihao"
	cmds.window('vb')
	cmds.columnLayout("ccco")
	cmds.button(l = "Add button",c=self.cbc)
	cmds.showWindow('vb')

com = testC()
com.mainCom()

the problem is :
when I dynamically create the buttons,why they have the same command!!,thanks a lot

[kurianos3d]

strange

[joojaa]

QUOTE(liuguanghui @ 03/25/09, 11:45 AM) [snapback]303890[/snapback]
when I dynamically create the buttons,why they have the same command!!,thanks a lot

Wellbecause they would end up getting the same i. i is not magically convertted to a value at lambda definition it would still be a reference to the same i that the others point to. This is caused by lanbda allways getting the locals of its predecessor as globals inside it. Try putting the lambda generation in a function of its own so the variable has time to die and reinit.

To my understanding they would be separate functions they just have all the exact same input.

[chadrik]

don't feel bad, this is one of the most common misunderstandings when first building UIs in python. check out this page from pymel's documentation, it should clear things up: http://pymel.googlecode.com/svn/docs/pymel...ows-module.html

-chad

[kurianos3d]

Chad ,

I think you will not feel bad . coz i striped some code from pyMel

CODE
import maya.cmds as cmds
class testC():
    def printV(self,value):
        print value

    def cbc(self,*args):
        for i in range(5):
            cmds.button(l=str(i),w=100,c=Callback(self.printV,(i)))

    def mainCom(self):
        vvv = "nihao"
        cmds.window('vb')
        cmds.columnLayout("ccco")
        cmds.button(l = "Add button",c=self.cbc)
        cmds.showWindow('vb')
class Callback(object):
    _callData = None
    @staticmethod
    def _doCall():
        (func, args, kwargs) = Callback._callData
        Callback._callData = func(*args, **kwargs)
    def __init__(self,func,*args,**kwargs):
        self.func = func
        self.args = args
        self.kwargs = kwargs
    def __call__(self,*args):
        Callback._callData = (self.func, self.args, self.kwargs)
        Callback._doCall()
        return Callback._callData
com = testC()
com.mainCom()

Now it will work

Chad Dont kill me

[joojaa]

QUOTE(Chadrik @ 04/03/09, 01:30 AM) [snapback]304757[/snapback]
don't feel bad, this is one of the most common misunderstandings when first building UIs in python.

Yes, its a very common mistake. Itsnot only in maya but in general however i find the explanation on the wiki a bit misleading*. Tough technically correct at some fringe. Its not actually going to be the value at the end of the loop. In fact ist not value at all. its a reference to the variable. So it is possible to change what the entire lambda stack does way after the loop has gone. Since thet value inside the for is now local.
so if you do
CODE
def foo(a):
  print a
def run():
  a=[]
  for i in ["a","b","c"]:
    tmp=(lambda :foo(i) )
    a.append(tmp)
  i="z"
  for item in a:
    item()
run()

Youd get it to print

CODE
z
z
z

Which is a slightly bit disturbing if you know any other language. And not

CODE
a
b
c

or
CODE
c
c
c

So you dont need gui development for thi to pop up just standard python stuff. Just happens a lot in gui stuff

IHMO ive only identified 3 drawbacks in the python language lambdas, and one of them is exactly this. Its a general problem of python as it is impossible to know wheter or not something got passed by value or by reference for certain base types. Which makes you very flabbergasted if you except either or. The second is related to this and its pythons scoping mechanism wich is weird to say the least. And third is no multiline lambdas. Nothing to fret over but causes problesm if you dont know of them.

*it probably suffices as depth but you could get into other troubles with this aswell if you asume ist the last loop that sets it.

PS: yes i am too pretty confident that the callback works right. Theres a easier way tough its a bit of a hack.

[uiron]

btw a workaround for the above problem Joojaa posted would be wrapping lambda creation into different scope, like lambda-maker function.

CODE
def foo(a):
  print a

def makeFoo(a):
  return lambda: foo(a)

def run():
  a=[]
  for i in ["a","b","c"]:
    tmp=makeFoo(i)
    a.append(tmp)
  i="z"
  for item in a:
    item()
run()

anyway, i don't like lambdas much and try to avoid them.

[joojaa]

Yes ofrfourse. But wouldn't that defeat the purpose of having lambda? I mean why would you want a lambda if you write a function for it?

Anyway suffice to say this is just something you wouldnt want to use lambda for.

[uiron]

well, that doesn't defeat the purpose of lambda. e.g., you have some function foo(val), and want to make parameterless instances of it that call different val by default

anyway, i like more traditional object-oriented approach, that is:

CODE
class Something:
      def foo(self):
          print self.val

obj1 = Something()
obj1.val = 5

obj2 = Something()
obj2.val = 10

obj1.foo()
obj2.foo()

[joojaa]

Well yes but people tend to use lambdas because their convenient to type, and lets face it making a class means you need to type in 2 places. Now if you make it a class you kind of break that. It is however VERY rare for people to sue lambdas for the right reason. So its more of a syntactic sugar than anything else. So yes lambdas should be used for their anonymity but very rarely do people do so.

Thing is tough your its not actually very smart to use lambdas for this purpose. A object will do and its easier to expand later when you know you need some more data. Also its VERY much easier to debug.

PS wouldn't it be just smarter to define a init and a call to the class that way the syntax should be more or less exactly the same as with a lambda!

PPS: im not actually seeking a solution i know several im actually jsut pointing out thet lanbda doesnt kindof do what one thinks it does.

[joojaa]

By the way kurianos allready said this and it was implemented in callback they are all more elegant solutions. I wasn't actually interested in solving this as much as to explain WHY it happens, as knowing what you do is as important as to getting something that works. But here a reiteration of the thread so far because urion missed it

something like:

CODE
class likeLambda:
    def __init__(self,store):
        self.value=store
    def __call__(self):
        print self.value

You can now use it just like the lamda in the for loop above. Because its now a function that inits at first cal. Does exactly what the lambda does just not anonymously. Sytaxically you call it just allmost like the lambda like, lets tekae the pymel wiki example:
CODE
from pymel import *

class buttonPressed:
    def __init__(self,store):
        self.value=store
    def __call__(self,*args):
         print "pressed %s!" % self.value

win = window(title="My Window")
layout = columnLayout()
names = [ 'chad', 'robert', 'james' ]
for character in names:
    button( label=name, command =  buttonPressed(character))

showWindow()

But thats more or less whet the callback class does so yes its 4 lines of extra code but no more than wrapping it up. And looses to lambda only in having a name.

[uiron]

not having value as __init__ parameter is more of a habbit - i tend to NOT put configuration parameters right into init call.

as for latest example for gui... i'd actually put MORE into the utility object, not just a press handler, smth like this

CODE
class buttonServer:
    def __init__(self):
        self.value="default value"
        self.button = None

    def pressHandler(self,*args):
        print "pressed %s!" % self.value

    def createGui(self):
        self.button = cmds.button(self.value,command=self.pressHandler)

win = cmds.window(title="My Window")
layout = cmds.columnLayout()
names = [ 'chad', 'robert', 'james' ]
for character in names:
    s = buttonServer()
    s.value = character
    s.createGui()

cmds.showWindow()

[joojaa]

Yes yes but theres infinite ways of designing good code just like theres infinite ways of doing bad one.

QUOTE
i tend to NOT put configuration parameters right into init call.

To me this sounds like your ide is lacking in ability to echo the synatx on highlight. Anyway it sound slike youd want python to be java level verbose

[uiron]

QUOTE(Joojaa @ 04/08/09, 12:12 PM) [snapback]305233[/snapback]
To me this sounds like your ide is lacking in ability to echo the synatx on highlight.

don't know exactly what you mean but that's Eclipse+pydev, can't complain about my IDE:]

QUOTE(Joojaa @ 04/08/09, 12:12 PM) [snapback]305233[/snapback]
Anyway it sound slike youd want python to be java level verbose

maybe:] maybe not. __init__ having only "default version" initialization of parameters is the result of previous practice, where you first build constructors like __init__(val1,val2), then require val1 to be skipped and end up with code __init__(val1=defaultValue1,val2=defaultValue2), then realise it's much safer, preventing future troubles, build parameterless constructors __init__() with default value for every member. imagine that as "construct it -> configure it -> use it" pattern.

[joojaa]

So your writing more code to save form writing code?

QUOTE(uiron @ 04/08/09, 01:48 PM) [snapback]305241[/snapback]
then realise it's much safer

But also error prone, if you mistype one of those vars then something unexpected can happen.