On Fri, Aug 7, 2020 at 9:51 AM Rudi Hammad <rudiham...@gmail.com> wrote:
> That's am interesting aproach Marcus. Didn't thought about it.
>
> After writinh that example, I was driving and I thought... wait a
> minute...that is example is so simple that just setting name and lastName
> as public properties is the same. I swear I was goinh to
> reply with that very same example you did! XD
> That was a bad example, but the logic was very simple. What about this
> random example? :
> class Foo(object):
>
> def __init__(self, input_):
> self.input = input_
>
> @property
> def x(self):
> trans = cmds.getAttr(self.input + ".tx")
> return trans
>
> @x.setter
> def x(self, value):
> if self.x >= 0:
> cmds.setAttr(self.input + ".tx", value)
> else:
> pass
>
>
> jnt = cmds.joint()
> foo = Foo(jnt)
> foo.x
> foo.x = 5
> foo.x = foo.x + 10
>
>
> # vs
>
> class Foo(object):
>
> def __init__(self, input_):
> self.input = input_
>
> def getX(self):
> trans = cmds.getAttr(self.input + ".tx")
> return trans
>
> def setX(self, value):
> if self.getX() >= 0:
> cmds.setAttr(self.input + ".tx", value)
> else:
> pass
>
>
> jnt = cmds.joint()
> foo = Foo(jnt)
> foo.getX()
> foo.setX(5)
> foo.setX(foo.getX() + 10)
>
>
> I think almost every one can agree that foo.x = foo.x + 10 is a much more
> clear than foo.setX(foo.getX() + 10)
> So this example isn't a read only attribute case. You can get and set.
> Aren't cases like that aslo a good use of properties?
>
Ya this is a likely case where I might expect properties to be used.
>
> El jueves, 6 de agosto de 2020, 22:42:18 (UTC+2), Justin Israel escribió:
>>
>> @rudi
>> So in your example I would say the name and lastName properties are a
>> perfect example of where I would not use a property, since defining a
>> getter and setter for those attributes without doing anything else but
>> getting and setting the value provides no benefit of just exposing the
>> public attributes in the first place. More likely I would expect to see
>> something like this:
>>
>> class Person(object):
>>
>> def __init__(self, name, lastName):
>> self.name = name
>> self.lastName = lastName
>>
>> @property
>> def fullName(self):
>> return self.name + " " + self.lastName
>>
>> Then you can access the very inexpensive, but dynamic, fullName computed
>> property.
>>
>> The use of the read-only specie property is something I would use.
>> Also, property setters don't need to return a value.
>>
>> @marcus
>> I completely agree with you about avoiding properties that are expensive
>> and pretend to look like normal attribute access. In a particular API, I
>> recently did something like this:
>>
>> obj.attr1.attr2.foo()
>>
>> But it turns out that attr1 is a property and on its first access it does
>> a big expensive resolve operation, with various side effects. That kind of
>> thing should not be hidden behind a property that will look like a simple
>> attribute access. It should be a method.
>>
>> About the dictionary usage, where you gain flexibility I think you lose
>> safety. It would be easier to make a typo when using string literals
>> constantly to access the dictionary, and an IDE won't be able to help you
>> catch that. So then if you end up defining the keys as constants then you
>> are right back to just having actual attributes. But I get that in certain
>> situations you don't know the shape of the data and dict would be the right
>> kind of field.
>>
>> On Fri, Aug 7, 2020 at 6:52 AM Marcus Ottosson <konstr...@gmail.com>
>> wrote:
>>
>>> Nowadays, when I get the chance, I tend to prefer accessing data either
>>> via a dictionary, or a dictionary-like interface.
>>>
>>> data = {}
>>> data["name"] = "Marcus"
>>>
>>> For classes, that would then look like..
>>>
>>> self._data["name"] = "Marcus"
>>>
>>> For example..
>>>
>>> widgets["button"].clicked.connect(self.on_clicked)
>>>
>>> layout = QtWidgets.QHBoxLayout(panels["footer"])
>>> layout.addWidget(widgets["button"])
>>>
>>> I find this extends well to Maya attributes.
>>>
>>> import cmdx
>>> node, = cmdx.selection()
>>> node["translateX"] = 5.0
>>> print(node["rx"])
>>> node["newAttribute"] = cmdx.Double(default=6.0)
>>> print(node.path(namespace=True))
>>>
>>> That way, I can have this rule.
>>>
>>> node.doSomething()
>>> node["storeSomething"]
>>>
>>> I mostly avoid @property actually, I haven’t really had a good
>>> experience with those. They’re good on paper.. I like that they prevent
>>> accidental assignment when you e.g. misspell.
>>>
>>> node.misspeled = "Bad"# Error
>>>
>>> But I don’t like how much extra typing you need (like your example
>>> above), and I most of all don’t like not knowing whether calling your
>>> @property incurs a cost or not.
>>>
>>> print(some_class.distance)
>>>
>>> Did this return a precomputed distance, or was one computed as I
>>> requested it?
>>>
>>> At the end of the day though, most of the time I work in a code base
>>> that isn’t mine and follow whatever convention is already established.
>>> Other times I know the code I write will be edited by others and pick a
>>> convention I expect will be the least surprising and the least distracting.
>>>
>>> Your mileage may vary, as they say. :)
>>>
>>> On Thu, 6 Aug 2020 at 15:10, Rudi Hammad <rudih...@gmail.com> wrote:
>>>
>>>> Uppss, I pasted the code as a text, sorry, and deleted my coment about
>>>> it.
>>>> I was saying that I use properties as you do I think. And I posted the
>>>> example above with the cases you described to see if I understood you well.
>>>>
>>>> Cheers
>>>>
>>>> --
>>>> 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 python_inside_maya+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/python_inside_maya/b9f25e83-e9b3-485f-b8f6-831a43432550o%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/python_inside_maya/b9f25e83-e9b3-485f-b8f6-831a43432550o%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>>> 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 python_inside_maya+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBx4ysUspDmV5gYNKOQ4GHBrShzwkD%2BnqqoSHFjHi1ceQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBx4ysUspDmV5gYNKOQ4GHBrShzwkD%2BnqqoSHFjHi1ceQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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 python_inside_maya+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/7f1f0385-417c-4895-936d-0426c2ccd7c7o%40googlegroups.com
> <https://groups.google.com/d/msgid/python_inside_maya/7f1f0385-417c-4895-936d-0426c2ccd7c7o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 python_inside_maya+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2m7sfTXY%3D88knS6JvFNzEao73f-ZNhuffOdKEcxVfrVw%40mail.gmail.com.
