[Bf-committers] Python RNA Type Registration

[Campbell Barton]

Hey Marton, reply to specific points inline.

On Tue, Mar 2, 2010 at 1:54 AM, Martin Poirier <theeth at yahoo.com> wrote:
>
>
> --- On Mon, 3/1/10, Campbell Barton <ideasman42 at gmail.com> wrote:
>
>> one thing I forgot to mention is:
>> How do we keep Alt+P running scripts in the text editor,
>> register it
>> looks like this...
>>
>> ... script body ...
>>
>> def register():
>>     ....
>> def unregister()
>>    ....
>> if __name__ == "__main__":
>>    register()
>>
>>
>> Its nice to be able to open a script in the text editor,
>> press "Run"
>> and see the updates immediate.
>> I really prefer we don't drop this.
>
> There's no reason to.
>
> I mean, beside the whole argument that reregistration of rna type is broken in the internal api, an argument you used earlier for NOT doing the change.

good.

>> Bringing this up because your method relies on setting a
>> context and
>> collecting classes from an external module, is there some
>> way to allow
>> direct execution to register also?
>
> Of course there is. We went over this on IRC.
>
> It's entirely possible to make the metaclass ask the api if it's running in "import" mode or in "execute" mode and to either fill in a list of types or register on definition.
>
> On the other hand, registering automatically like that, even with the __main__ method is entirely shaky, since the unregister method will never get called and it's entirely reliant on reregister not breaking up.

the existing function to register with __main__ is incorrect but just
added for convince so Alt+P runs scripts, it will need to be replaced.

>> Glad this is added, but I'm not totally convinced, read
>> on.
>
> Can you stop moving the goalpost, it's getting tiring.
>
> Just list what you think the problems are and I'll answer. Going back and forth is a major waste of time.

will answer in another mail...

>> > Modules are already loaded externally with a loader in
>> utils.py, that you wrote.
>> >
>> > This isn't added complexity, if anything, it
>> centralizes it instead or relying on module authors to write
>> their own.
>>
>> Technically they are loaded by an external loader but all
>> it does is
>> import and run the register function, which will give
>> errors in the
>> authors code. also makes running script call register very
>> easy,
>> something Im not sure about with your patch (as stated
>> above).
>
> Answered above and twice before on IRC.
>
>> yes & no, they do have something to do with the
>> registration method in
>> that when trying to fix the bugs you must understand whats
>> going on
>> with registering pretty well. (what order, whats
>> registered, double
>> registered, whats freed etc)
>
> And I've told you many times that a centralized registration makes this easier to track.

Ill want to test this first but. ok.

>> But your right in that its not directly related, I say this
>> more to
>> show the current system is not in control so Im not happy
>> to add code
>> that confuses me more if I have to spend a lot of time
>> debugging.
>
> I can go over the new code more in details if you think that will make you understand.
> There's nothing confusing, the process is rather straightforward.
>
> It's like a decorator, but without the extra syntax.
>
>> for users no, but its not uncommon to reload scripts while
>> testing (I
>> did this last week for fixing the BVH importer).
>
> I thought you said earlier that reloading was full of internal problems. Why would I want to struggle with internal RNA problems when developping a script?
>
> I'm not saying we shouldn't support this, short turnaround time is great for development, but you can't say that reregistration is broken internally so we shouldn't change the registration process and then say that you use it a lot so we shouldn't change it either. Is it broken or is it not?!

Re-Registration is broken but works well enough to load/unload addons.

>> > Inspecting the namespace is nasty and has so many
>> corner cases, I can't believe you think it would be actually
>> better.
>>
>> yep, its not pretty, but an option to keep in mind.
>
> Parsing the namespace would be even worse in complexity than the metaclass solution.
>
> If that doesn't rule it right out, you're not being consistent here.

The only reason I keep this as an option is that it can be used/not
used per script as a convenience function, but Im sure there are
better ways

>> notice I didn't say other 3D software :), already looked
>> into this and
>> was pretty shocked at the quality of their pyAPI's.
>
> Their Py api is pretty much a port of the MEL API. It's like wrapping a shit in christmas gift paper, it's still poo.
>
> What other API did you look at? Did the have the same kind of extension capabilities that we do?
Only XSI which registers its classes, this uses "win32com" which seems
to be cross language but not that pretty.
Also looked at the gimp but this doesnt to register/unregister, its
more like what we used to have.

Id not be surprised if we're the only application doing this kind of
integration.



> --- On Mon, 3/1/10, Dalai Felinto <dfelinto at gmail.com> wrote:
>
>> From: Dalai Felinto <dfelinto at gmail.com>
>>
>> Same for "Live Edit" . Maybe this is not highly needed, but
>> it'll be nice if
>> we can maintain it.
>
> Agreed. I don't think it would be very hard, I can think of 3 or 4 ways to do it nicely.
>
> The problem now is more with internal registration and dangling references than the registration process on the python side itself.
>
>
>
> Anyone else wants to chip in with opinions, please do so. I'd like to hear especially from people who've used the 2.5 API (for UI, Import/Export, Render Engine, ...).
>
> Martin
>
>
>      __________________________________________________________________
> Get the name you've always wanted @ymail.com or @rocketmail.com! Go to http://ca.promos.yahoo.com/jacko/
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell