http://tmml.sourceforge.net/doc/tcl/if.html
On Mar 9, 2011, at 1:32 PM, Michael Havart wrote: > Great ! this is quiet clear now. > > One last thing about tcl, what is the correct syntax for testing a condition > like: > if bool is True: > then dothis > else dothat > > Thanks a lot Frank ! > > > 2011/3/8 Frank Rueter <[email protected]> > Just remember that everything in tcl is basically a string (I guess you could > argue about that, but it's a helpful notion I found). > White spaces delimit arguments and square brackets indicate a nested tcl > command. double quotes are used to explicitly define a string allowing > substitution, while curly braces won't allow substitution. > > so: > puts hello > works as well as: > > puts "hello" > or > puts {hello} > > this will throw an error as it interprets "world" as a second argument to the > puts command (which is expected to be a IO channel: > puts hello world > so out come the quotes: > puts "hello world" > or braces: > puts {hello world} > > to see the difference between quotes and braces: > puts "the current frame is [frame]" > where [frame] is a nested tcl command, and because it's inside of double > quotes, it will be evaluated: > --> the current frame is 1 > > with braces the nested command is not evaluated: > puts {the current frame is [frame]} > --> the current frame is [frame] > > so when you put python syntax into a label, you essentially run a tcl command > called "python" followed by n argument which is the python syntax. And if > that syntax contains stuff like square brackets, tcl might try and evaluate > it as a nested command. And that's where braces come to the rescue to make > sure tcl doesn't try to mess with the python syntax. > > > > > > On Mar 9, 2011, at 7:58 AM, Nathan Rusch wrote: > >> It’s good practice to do it all the time, just to help make things clearer >> and avoid the potential for pesky errors. >> >> -Nathan >> >> >> From: Michael Havart >> Sent: Tuesday, March 08, 2011 10:24 AM >> To: Nuke Python discussion >> Subject: Re: [Nuke-python] knob syntax >> >> Ok that's clever, thanks >> When exactly you need to put the curly braces ? maybe it can improve my >> autolabel callbacks... >> >> thanks, >> Michael >> >> 2011/3/8 Ean Carr <[email protected]> >> That's because you're confusing the tcl interpreter. Try curly braces. >> >> [python {nuke.thisNode()["size"].value()}] >> >> -E >> >> >> On Tue, Mar 8, 2011 at 2:45 PM, Michael Havart <[email protected]> >> wrote: >> and also, in autolabel or expressions this will not work: >> >> [python nuke.thisNode()["size"].getValue()] >> >> but this will work: >> >> [python nuke.thisNode().knob("size").getValue()] >> >> >> >> >> >> 2011/3/8 Alexander Jones <[email protected]> >> >> >> >> On 8 March 2011 06:19, Ben Dickson <[email protected]> wrote: >> node['blah'].value() >> >> ..is less typing, so I use that over the functionally identical >> node.knob("blah").value() >> >> They're not identical -- ["blah"] will raise a KeyError for a missing knob, >> whereas knob("blah") will return None. Subtle! >> >> >> I use node.knobs() occasionally to iterate over all knobs (or use >> node.knobs().keys() ) >> >> Incidentally I use [''] over [""], because the first can be typed >> without shift (on UK/Australian keyboards anyway) - same with ("") which >> can be typed with shift held. Efficiency!... >> >> John RA Benson wrote: >> > Hey there - >> > >> > Basic question: >> > >> > just curious - if find myself flipping between using syntax like: >> > >> > node.knob('myknob').value() >> > vs: >> > node['myknob'].value() >> > >> > Is there any 'best practices' or preferred way to write that? Sort of >> > like, do you always use '"' or "'" for quotes... >> > >> > Cheers >> > JRAB_______________________________________________ >> > Nuke-python mailing list >> > [email protected] >> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> > >> >> -- >> ben dickson >> 2D TD | [email protected] >> rising sun pictures | www.rsp.com.au >> >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> >> -- >> Alexander Jones >> Double Negative R&D >> www.dneg.com >> >> >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> >> >> -- >> Michael Havart | DMP-ENV | MPC-London >> images: cghub.com | blogspot.com >> cv: linkedin profile | imdb >> >> >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> >> >> >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> _______________________________________________ >> Nuke-python mailing list >> [email protected] >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > _______________________________________________ > Nuke-python mailing list > [email protected] > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > _______________________________________________ > Nuke-python mailing list > [email protected] > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________ Nuke-python mailing list [email protected] http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
