[Bf-committers] Python RNA Type Registration

[Ton Roosendaal]

Hi,

I propose to move to the meta level of "how to get to a decision".
Reason and rationales can be relative too... even though it doesn't  
always appear as such. :)

In cases like this, the maintainer team should have a final say in  
consensis. If Brecht/Campbell/Martin cannot reach consensis, they  
could allow Campbell to have a final word, since he's the chief  
maintainer and will probably work on this code for many years anyway.

Hopefully Martin can accept this? Maybe Campbell just has to get used  
to the idea and finds out next year. And further, the Canadians won  
enough already! ;)

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 2 Mar, 2010, at 1:54, Martin Poirier 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.
>
>> 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.
>
>> 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.
>
>>> 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.
>
>> 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?!
>
>>> 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.
>
>> 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?
>
> --- 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