Page MenuHome

Depsgraph examples: don't assign to names of built-in Python objects
ClosedPublic

Authored by Sybren A. Stüvel (sybren) on May 22 2019, 10:38 AM.

Details

Summary

object is the superclass of all objects. Old-style code could still be using class SomeClass(object) and assigning something else to object could have unexpected results.
IMO the examples in our documentation shouldn't have any common anti-patterns.

Diff Detail

Repository
rB Blender

Event Timeline

I do not see this as anti-pattern, this is what the name scopes are for. Same you can argue for not using file, open and other names as variables in Python. Same you can argue for not using min, max, index, select in C code.

To me it is ridiculous to let stupidity of language to dictate you how or how not to call your variables.

Just to make it less opinionated, is there an official non-EOL PEP about this? If not and you really want to enforce this, make a section in coding style (maybe create practices) on Wiki listing this.

Otherwise just ignore this. Trying to avoid all collisions and shadowing is not easily achievable, and is never possible without sacrificing readability/understandability of own code.

(I abandoned this revision before I saw your 2nd comment)

Just to make it less opinionated, is there an official non-EOL PEP about this?

I haven't been able to find an official source.

If not and you really want to enforce this, make a section in coding style (maybe create practices) on Wiki listing this.

IMO that would be a good idea, and I'm all up for enforcing this. Assigning to built-in names is generally considered a bad practice in the Python community. Also, many IDEs (and syntax-highlighting libraries) colour built-in names differently; you can also see this in Phabricator, so reusing built-in names for other purposes actively causes confusion.

Otherwise just ignore this. Trying to avoid all collisions and shadowing is not easily achievable, and is never possible without sacrificing readability/understandability of own code.

It's not that bad, as it can actually improve readability. The built-ins are often very generic, so instead of list = some_func() a possible solution could be to change it to imported_objects = some_func(), which would drastically improve readability.

The only place where it conflicts with Blender, because we have our own Object type, is indeed the name object. Replacing object with obj is IMO fine and perfectly readable. At least it's less confusing for people who know Python built-ins and get the wrong colour in their IDE.

And yes, I also feel that Python's built-in should have been named Object instead of object... That's not something we have any influence on, though.

It's not that bad, as it can actually improve readability. The built-ins are often very generic, so instead of list = some_func() a possible solution could be to change it to imported_objects = some_func(), which would drastically improve readability.

In the application logic -- sure. Sometimes it could hurt as well, especially when talking some lower level generic utilities. Not sure it's stat common in the addons.

The only place where it conflicts with Blender, because we have our own Object type, is indeed the name object. Replacing object with obj is IMO fine and perfectly readable. At least it's less confusing for people who know Python built-ins and get the wrong colour in their IDE.

Lazy way in Blender is to use ob. But then it becomes like a de-facto standard and everything: cu, mb, me and so on. Those shortenings are confusing for new-comers and more often than never confusion (i.e. me as a mesh or me as an medge).

I would really love to at least encourage typing the full name (which isn't too long even). But then obj in an official example welcomes everyone to start shortening. At least it feels so. And it's not something what makes me happy.

And yes, I also feel that Python's built-in should have been named Object instead of object... That's not something we have any influence on, though.

True. But maybe eventually object will be deprecated. In Python 4 :)

Naming guidelines have been documented at the wiki.

This revision is now accepted and ready to land.May 22 2019, 5:12 PM
This revision was automatically updated to reflect the committed changes.