It's a builtin python function/decorator:
http://docs.python.org/2/library/functions.html#property
A computed property acts like a normal attribute, but under the hood uses a
getter/setter/deleter. Before the decorator, the older way was to create
your individual getter/setter methods and then assign a property(). But the
decorator does it all for you. You can do stuff like lazy-evaluation where
you don't compute the value until it is called, and then cache it from then
on:
@property
def value(self):
if self.__value is None:
self.__value = computeTheValue()
return self.__value
They are useful when you want to represent them just like normal
attributes.
On Mon, Nov 11, 2013 at 9:46 PM, Simen Chris <[email protected]> wrote:
> You sir, are awesome! Thank you so much! :D One quick question, what are
> the @property decorators for?
>
> On Friday, November 8, 2013 11:02:24 PM UTC+1, Justin Israel wrote:
>
>> Now that I'm seeing some usage of your structure, it actually does seem
>> like its a pretty predictable dictionary. Its just some top level keys,
>> each with a list value of objects. In terms of wanting to break those up
>> into discreet data structures, you could just get rid of the dictionary and
>> make use of attributes on your rig class. That ends up just being 3 lists
>> (joints, groups, ikHand). Pretty easy to manage, and no recursive
>> dictionary action needed here (unless there is more to the story that isn't
>> in the code examples).
>>
>> I didn't really flesh out the entire behavior for you, to make defining
>> subclasses of the Rig more streamlined, but here is an example of one way
>> you could structure the base rig class to use attributes instead of a
>> dictionary:
>>
>> http://pastebin.com/nkDbciEY
>>
>> You will notice that I renamed your method to build() and it doesn't need
>> to return anything. Your data is accessible on the public attributes of
>> your rig instance. I also included an example of how you could wrap your
>> joints into a Limb class, to make it easier to manage the sets instead of
>> having to do hard-to-follow indexing into a big list. With these kinds of
>> abstractions, you could add logic to manage them, such as wrapping in cmd
>> calls to get info about the joints, or deleting them as needed. I think it
>> is a lot easier to reason about your data when they are broken up into
>> discreet manageable structures that don't require a big loop of different
>> logic over the members. Limbs know what to do with their joints (if you
>> extend the logic of the Limb class).
>>
>>
>>
>>
>>
>> On Fri, Nov 8, 2013 at 10:01 PM, Simen Chris <[email protected]> wrote:
>>
>>> Thanks guys, I understand :) I've tried to write down some example code
>>> to illustrate what I'm trying to do, one where I've done it the way I've
>>> done here, and one where I've tried to inherit from classes. It isn't much
>>> difference, and I still don't know how to do this without using
>>> dictionaries :/
>>>
>>> Here's the code without using inheritance: http://pastebin.com/f68x6x14
>>> Here's the code where I've tried to inherit from classes:
>>> http://pastebin.com/7h6tk49B
>>>
>>> I was hoping you could have a look at my code and give me some tips, I'd
>>> really appreciate that as I really struggle to wrap my head around this :/
>>>
>>> On Tuesday, November 5, 2013 8:11:46 PM UTC+1, Justin Israel wrote:
>>>
>>>> The problem for me, in giving a specific suggestion, is that you have
>>>> said your dictionary structure is completely variable in both its nested
>>>> depth and its composition of types. So this will make it difficult to use
>>>> in every function you give it to since any of them will need to scan
>>>> through it to find something.
>>>> It would be much easier on you to figure out what data you need to
>>>> store and what it will look like. As Paul suggested, you may find it more
>>>> manageable to keep the data in multiple fields of a custom class, with
>>>> methods that help to read and write to the structure.
>>>> On Nov 6, 2013 4:03 AM, "Paul Molodowitch" <[email protected]> wrote:
>>>>
>>>>> I'm not sure if this is the most efficient way to store the data,
>>>>>> actually I'm pretty sure it's among the worst, heh :p The reason why I'm
>>>>>> storing in a dictionary is that I have some pretty large functions, and I
>>>>>> want to be able to go in and get any object created within the
>>>>>> function after it has run, so I thought dictionaries was the most
>>>>>> readable
>>>>>> way to do it, do you have any other suggestions?
>>>>>>
>>>>>
>>>>> Try using object-oriented programming (OOP) - ie, classes. The
>>>>> problem of associating a common set of data with a set of functions is one
>>>>> of the core issues that OOP was created to solve. Unfortunately, this
>>>>> isn't necessarily an "easy" solution - learning how to properly use
>>>>> classes
>>>>> is something that will take practice - but it's well worth the effort, in
>>>>> my opinion.
>>>>>
>>>>> Also - at a guess, you might also want to try breaking your "pretty
>>>>> large functions" into several smaller ones, if possible...
>>>>>
>>>>> - Paul
>>>>>
>>>>> --
>>>>> 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/CAAssL7bEtFkgWN5W9eccGi6OYNeEMCD0%
>>>>> 3D7i5To9Ehdr4d6gC_Q%40mail.gmail.com.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>> --
>>> 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/eda1a162-1fdb-44fe-b0bc-
>>> 7ff6539ffd5a%40googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>> --
> 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/82df4de0-4bfe-43a4-b47a-dff2ad7a0710%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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/CAPGFgA3w%2BPgt4jxtczskNdPJo5c%3Dofyu_PuGDPQaazeE7y8UBg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
