@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 <[email protected]>
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 <[email protected]> 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 [email protected].
>> 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 [email protected].
> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2TJ2JDnMMSngHbR8K5nD%3DeB-j3jg49YXUciHOctp3zCw%40mail.gmail.com.
