[Bf-committers] Python RNA Type Registration

[Campbell Barton]

Hi again Mart'i'n, this is a more general reply on how Id like to move
forward on this.

Discussed with Brecht yesterday.
- We agree class enumeration is ugly and should be replaced.
- We agree it would be acceptable to collect classes automatically and
register all with 1 or 2 lines at the bottom of the script.
- At some point it doesn't make sense to discuss if something is
complicated or not, harder to debug etc. I just need to test it, try
make changes, see what happens when things go wrong etc.
- At the moment the spare time I have gets interrupted a lot, so I
don't think this is something I can do short term (probably before
durian ends though).
- As well as reviewing your patch Id like to test alternatives,
probably isn't even a lot of code to write, but just to see how it can
be done.
- Its very important that I understand this if I'm to keep maintaining
this area, at the moment bugs that exist are 99% my fault or from
Brecht's initial registration commit which I know well.


Registration sucks at the moment but I think there are more important
things, for example, many important API functions will need changing,
loading an image, need to review animation editing from py,
conventions for rna function names are a mess too (and register bugs
which I keep banging on about).
Operators also need a lot of work but thats a bigger problem we cant
solve so easy.

Nevertheless this MUST be fixed before release, My impression is that
you are worried the current system will stick if we don't replace
soon, which is why you want to get this in?

After this mail I'm left thinking this might be more important then I
originally thought, will see of I can get time to work on it.
Otherwise it can be put on hold.

- Campbell

On Wed, Mar 3, 2010 at 10:28 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
> 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
>



-- 
- Campbell