[Bf-committers] Python RNA Type Registration
theeth at yahoo.com
Fri Mar 5 01:13:44 CET 2010
--- On Wed, 3/3/10, Campbell Barton <ideasman42 at gmail.com> wrote:
> Discussed with Brecht yesterday.
> - We agree class enumeration is ugly and should be
> - We agree it would be acceptable to collect classes
> automatically and
> register all with 1 or 2 lines at the bottom of the
> - 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.
I think it's also important to consider that this isn't just something that is used by people doing a lot of python dev but also by casual coders. Dalai raised a good point, but I wished we had more input from others.
> - 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).
This isn't something you *have* to do.
If I know what the required additional changes are, I can do them on my time. I can document and submit for approval before applying them.
> - As well as reviewing your patch Id like to test
> probably isn't even a lot of code to write, but just to see
> how it can be done.
And I'd be available to discuss them, you can be sure of that.
> - Its very important that I understand this if I'm to keep
> this area, at the moment bugs that exist are 99% my fault
> or from
> Brecht's initial registration commit which I know well.
I don't believe it's as big a change as you make it. Nothing changes on the RNA side, the only thing that changes is how and when the registration function gets called. It's all under 40-50 lines of code (most of the patch is removing things and moving some stuff around).
> Registration sucks at the moment but I think there are more
> things, for example, many important API functions will need
> loading an image, need to review animation editing from
> 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.
Indeed, there are a lot of other problems.
But as I said, I think you're making this a bigger change than it is and since I'm offering to do the grunt work (most of it is done already), all you'd have to do is understand what's going on, which I can explain in another email if that's needed.
> Nevertheless this MUST be fixed before release, My
> impression is that
> you are worried the current system will stick if we don't
> soon, which is why you want to get this in?
Mostly that and the fact that I find the explicit registration method prone to errors and bad boilerplate code.
Maintaining the patch (conflicts every time someone modifies the stupid class lists) is an annoyance but not really an issue.
> 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
> Otherwise it can be put on hold.
I know what happens with things that are put on hold, so you can expect me to keep insisting.
Looking for the perfect gift? Give the gift of Flickr!
More information about the Bf-committers