[Bf-python] API overhaul - irc meeting?

[Gilbert, Joseph T.]

1) should read degrees vs. radians! Lol this is the 2nd time if done
that.

-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Gilbert,
Joseph T.
Sent: Friday, January 06, 2006 11:26 AM
To: Blender Foundation Python list
Subject: RE: [Bf-python] API overhaul - irc meeting?

Forgot 1.

9) Start using True/False instead of 1/0.

-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Gilbert,
Joseph T.
Sent: Friday, January 06, 2006 11:24 AM
To: Blender Foundation Python list
Subject: RE: [Bf-python] API overhaul - irc meeting?

Here's my laundry list:
1) Eulers vs. Radians debate. Which do we go with for the mathutils
module and throughout the api.

2) Module level constants. Blender.Module.CONSTANT. The code in genutils
for getting/setting this stuff needs cleaning. Module level constants
need a naming schema. i.e. ModuleXY.XY_CONSTANT possibly.

3) tp_new/tp_init - get rid of factory generators where applicable and
expand the typeobjects to support class initialization.

4) Removed the Types module and move objects to their respective
modules. PyType_Ready is used to initialize this typeobject.

5) OOP list/dict interfaces. Where list/dict are returned - put the
list/dict as part of the BPy struct and return a copy of list/dict
instead of a new list/dict where applicable. Could use 2 subclassable
typeobjects for list and dict that support tp_method/tp_member
subclassing and strict member add/remove ability.

6) Possibly implement GC on typeobjects

7) Organize module hierarchy if needed. I'm thinking
Blender.Object.Armature here, etc. NLA is in this category.

8) finish tp_getset project

That's all I can think of for now.

==documentation==
I've tried A LOT of source code generation stuff to see if I could get
it to run with out C source file and couldn't do it. Most source
documenters are written for C source file and document for programmers.
I was hoping doxygen would work but it was a bit too complex for me lol.

If we can't get a system working maybe we need to write something
ourself. Personally I'd like to see the stupid .py doc file go. It would
be so much easier for me to document the source code.
If nothing works then epydoc does a good job.

==create docs before coding==
I don't know if this is a good idea. For the most part our modules will
look the same because what is exposed is what is exposed. We can rename
stuff or get some naming conventions but rewriting the entire api as
documentation will generate an api that looks a lot like the one we
have. Is this really worth the effort?


-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Willian
Padovani Germano
Sent: Friday, January 06, 2006 8:19 AM
To: Blender Foundation Python list
Subject: [Bf-python] API overhaul - irc meeting?

Hi,

It'd be good to have an IRC meeting about our planned BPy face-lifting.

It could be one hour earlier than Blender's meeting this Sunday 
(Saturday I'm busy, sorry) or right after it. We can also choose any 
weekday.

The idea is to put the whole team in sync about what we can and will do.

A few suggested topics to discuss:

1) It's an overhaul, we're cleaning, not creating a new API. What will 
be done exactly?

2) There are some tools we can use: doxygen to document the C source 
code, still epydoc for the API (what to do about the doc strings in the 
C files?), splint, ??

3) Where will we work? New dir, probably.

4) How fast?

5) Communication: wiki, list, forum.

6) The start: define API before coding it, create (epy)docs and tests,
etc.

Of course we can reuse a lot of what we already have. Some modules will 
be kept (almost?) intact, like BGL, lots of existing code will stay. And

our current docs will only need updates.

====
Doxygen: www.doxygen.org
Splint: www.splint.org (nice tool, can be a simple helper for each
coder)

--
Willian
_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python
_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python
_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python