On Mon, Jul 21, 2014 at 11:08 PM, Gabriele Bartoli <[email protected]
> wrote:
> Hi, sorry for the late reply. Busy weekend!
>
>
> On Friday, 18 July 2014 23:36:52 UTC+2, Justin Israel wrote:
>>
>> I can offer a couple points of feedback so far, but I didn't get too deep
>> into the too since it has some compatibility issues with python2.6 (Maya
>> 2013).
>> If you use the str.format() approach for formatting text, python2.6
>> doesn't support the anonymous fields. That was introduced in python2.7
>>
>> So in python2.7, this is valid: "My string says {}
>> {}!".format("Hello", "World")
>> But in python2.6 you have to name the fields: "My string says {0}
>> {1}!".format("Hello", "World")
>>
>
> Good to know! I'll fix it so that it works with older versions too. :)
>
>
>> Also, there are a couple button callbacks where you use "mm.eval()", but
>> if someone doesn't have maya.mel imported as mm in their global scope
>> (either having done it manually in the script editor, or in their
>> userSetup.py) then it will produce an error. That could be another
>> candidate for partial, doing something like partial(mm.eval, "my mel
>> command"). Otherwise you have to do the more verbose string approach that
>> has to first import maya.mel: "import maya.mel as mm; mm.eval('my mel
>> command')". I kind of prefer the former, if you have to call mel as a
>> python callback. Or it can call a python method you have set up already
>> that will cleanly call the mel command, like: self.__prefixHierarchy()
>>
>
> Thanks, I never noticed that issue, probably because I have always
> launched the script at least once from the script editor, importing
> maya.mel in the global scope, before trying the shelf button. I fixed it
> creating three methods looking like this:
>
> def launch_prefixHierarchy(self, *args):
> """Launches Maya's built-in command"""
>
> from maya.mel import eval as eval
>
> eval('prefixHierarchy')
>
> Out of curiosity, why did you add the double underscore in the method
> example? I know it is supposed to tell python that the method is private,
> but I don't see why would someone do that (it is more of a general inquiry,
> not a specific one).
>
The use of double underscore is for methods where the implementation is
private and outside people shouldn't be calling it. For things like
callbacks that may take private arguments or have functionality where you
want control over them being called, it is good to hide them. Ideally you
are only exposing functions you want the outside world to have access to. I
just chose to make this a private method since it's sole purpose was to
wrap a mel call to prefixHierarchy, and really serves no purpose as being a
part of your public API. But it is possible you might have some reason to
make it a public method.
Out of curiosity for me as well, why do you choose to use that specific
form of an import statement? It seems redundant to import something as an
alias of the original name (not to mention that technically in this case,
"eval" would shadow the python eval, although it would have no effect if
you weren't going to use the python eval() anywhere). But it could be
written as:
from maya.mel import eval
>
> * "New-style" python classes always at least subclass object: class
>> MyClass(object):
>>
>
> Ok, not really sure what is going on here, but I'll do some research! To
> be on the safe side, I'll do as you say and take it from there.
>
> * When testing if a list is empty, instead of allocating a new empty list
>> object each time, just to test if it is equal to the other list, you can
>> simply check if your list is empty using: if not myList
>>
>
> Do you mean that instead of doing
>
> if my_list != []:
>
> I should do
>
> if not my_list
>
> ? I guess I stick with the first method as it reminds me of the few things
> I remember about C :P
>
Well my comment wasn't just about syntax. You are actually allocating a
temporary list object in memory each time that just gets garbage collected.
Seems like something you might want to avoid doing. Do you allocate
temporary arrays in C to check if an existing array is empty? Or are you
confusing this syntax with comparing an array to NULL in C (asking if it is
a NULL pointer)?
>
>
>> * It is usually best not to have your class constructor have side
>> effects, such as showing the window. It should have a separate method like
>> show(). That way someone can import and create an instance of the window
>> and show it when they want to. Constructors are for setting up the state of
>> the class.
>>
>
> Ok, to put in other words, I can leave the __init__ empty, given that
> there isn't much to initialize, and create a new method that does what the
> __init__ was doing. It seems to work, so I'll do it :)
>
You could leave all of your widget construction and layout in the
constructor if you want (thats up to you). I only meant the last line where
it shows the window as part of the constructor.
>
> * The approach where you are using the tool_launcher() method with a
>> string tool name might be cleaner if you made those tools formal functions
>> or methods. There are a couple of places where you test for the literal
>> string names in order to do different logic, which could be bug prone
>> because changing the name in one spot means you have to find and replace
>> all of the literal string references. Maybe you might want to define those
>> once in your class as class constants:
>>
>> class MyClass(object):
>> ACTION_NAME_1 = "action1"
>> ACTION_NAME_2 = "action2"
>>
>> Or if you want to make the association between an action and a
>> displayable name, you can register a dictionary in your constructor that
>> maps them:
>>
>> self._actions = {
>> "Action 1": self.__action1,
>> "Action 2": self.__action2,
>> }
>>
>> Then you won't have to do the 'if actionName == "literal name"' test in
>> multiple places to figure out the action to perform. You can just look up
>> the associated action in the dict: self._actions[actionName]
>>
>
> You're very much right. I think I'll live it as it is for now. If happen
> to change that part of the code I'll fix it properly.
>
>
>> * rsplit() is a method of a string
>> so this: str.rsplit(str(temp_name), split_char, 1)
>> can be written as: temp_name.rsplit(split_char, 1)
>>
>
> Ok, now this is interesting. It was definitely stupid of me to use that
> syntax. I do have a question though. I started with:
>
> str.rsplit(temp_name, split_char, 1)
>
> which gave me this:
>
> TypeError: descriptor 'rsplit' requires a 'str' object but received a
> 'unicode'
>
> This is why I managed to make the ugly code even uglier with the
> str(temp_name) type conversion.
>
> Now with the question. Following the error stated above, I assumed that if
> I wanted to avoid the same TypeError, your suggestion
>
> temp_name.rsplit(split_char, 1)
>
> needed to be converted to
>
> str(temp_name).rsplit(split_char, 1)
>
> Needles to say, you were right and it works perfectly without conversion.
> Any idea why it needed the conversion in the first case and not in the
> second?
>
>
Ya, the reason it was giving you an error was because you were passing an
instance of a unicode object to a method of the string class. If you really
wanted to make it work that way, it would look like this:
s = u"foo bar"
unicode.rsplit(s, ' ', 1)
But obviously you have figured out that you can just call the rsplit()
method on the object so it is shorter.
>
> Well, thanks a lot. You've been really helpful. Do you have anything to
> say about the actual functionality of the whole thing? UI design and stuff
> like that?
>
I didn't get to try the whole thing out, since I didn't have Maya2014+
handy at the time. But it looks nice! Also very kind of you to add so much
help at the bottom. Leaves nothing to ambiguity! Sorry that I focused more
on the code aspects, rather than the interface. It was easier for me to do
that at the given moment.
>
> Thank you very much!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/ed3474e4-08f8-4b02-9f7d-2b4cd958d6c0%40googlegroups.com
> <https://groups.google.com/d/msgid/python_inside_maya/ed3474e4-08f8-4b02-9f7d-2b4cd958d6c0%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA03mzsJbaBr-Cd5aNg7S-eXUTJeJOyt3tzR3vcNVq9xEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
