API changes

Tips & Tricks
#21

As a last-minute modification, I’m considering adding arbitrary arguments to create_instance.

# Before
instance = context.create_instance(name="MyInstance")
instance.set_data("family", "myFamily")

# After
instance = context.create_instance(name="MyInstance", family="myFamily")

Where name is a first positional, required argument, and everything after are arbitrary keyword arguments.

def create_instance(name, **kwargs):
  instance = Instance(name)
  for key, value in kwargs.items():
    instance.set_data(key, value)

Allowing us to do things a bit more succinctly and flexibly.

instance = context.create_instance(
    name="MyInstance",
    family="myFamily",
    data1="more",
    data2="even more")

It’s a non-breaking change, but would be difficult to turn back from. Considering 1.1 is a large adjustment already, I’d say we’d either implement it now or at 2.0.

Thoughts?

1 Like
#22

I’d go for it. Look like it would make the code tiny bit cleaner, which is always a good thing

1 Like
#23

Sounds good. Since it’s a non-breaking change I think implementing it right away should be fine. +1

#24

Cool, consider it done.

#25

This is currently implemented.

Just wondering whether this change is there to stay. Both issues seem to be closed on Github for Collector and Integrator. Everyone seems to be on board for Collector. Feedback on Integrator has been limited, but seems to be accepted as a possible option.

At this moment Collector is an alias to Selector and Integrator is an alias to Conformer. Some points to discuss:

  • Will Collector stay? If so will Selector go away?
  • Will Integrator stay? If so will Conformer go away?
  • If Collector stays than it might be good to swap Conformer to Integrator so its name is a bit more separate. Or it might not bother people?
  • If both Collector and Selector stay and/or both Integrator and Conformer stay might it become confusing to users that both are synonyms/aliases. When mixing extensions you might find yourself having both Collectors and Selectors?

I also noticed you explained the selection/collecting part as Collect in the Learning Pyblish by Example topic. I think it makes sense for starters so maybe make Collector the (only?) standard?

I’d be happy to start refactoring Selector to Collector! And I guess I’m on the same boat for Conformer to Integrator.

#26

At the moment, the official description of Selectors are that they are “also known as Collectors”, and the same for Integrators.

My only compelling reason to not replace Selectors and Conformers today is historical, as SVEC has been what they were called since it was born. :frowning: Apart from that it rolls better off the tounge than CVEI.

Other than that, technically and in terms of clarity it makes for a step forward I think and it would probably be a good idea to make the shift 100%.

#27

Personally I don’t mind what we call them. I’ve gotten used to SVEC, but I could also do CVEI. Think the main thing is just to commit completely.

#28

I think so too. CVEI it is, let’s never look back.

If another stack appears in the future, it will be in the form of an extension. Something SVEC should probably have been to begin with.

1 Like