[Bf-committers] I volunteer to maintain the 'deprecated' BGE python methods

[Campbell Barton]

Im against keeping these old methods... answers to each of your points.

>> 1) increased compatibility with recent BGE books.
- Blender2.5 will be different enough in user interface that a new
user would have trouble following tutorials from blender 2.4x
- Ipo's are removed in 2.5,
- Python 3 means the print functon works differently, divide also.

...of course a smart person could figure out all this but it means
picking up a book on the BGE written for 2.4x and trying to follow a
tutorial will be difficult - some sections wont apply, for a new user
this would be very confusing so their better off using blender 2.49x.

Also - how many books are there on the BGE?, <3?, we have this problem
for many more non-BGE blender books and still will go ahead with big
changes for blender 2.5 so I think this is a minor concern.

>> 2) it is easier to upgrade old scripts to Blender 2.5 and later
>From my experience scripters are lazy and will only update their
scripts when they stop working.
For example quite a few of blenders scripts use deprecated NMesh.
If people really want to wait years between writing and upgrading
their games then they will also need to deal with changes to the
physics system and dynamics that often end up breaking games between
release (as we have for 2.48->2.49).

>> 3) always the option to using methods is more consistent: rather then having
>> to remember which parts of the API are properties in disguise and which
>> still use methods
We agreed to move to attributes a while ago. If you want to change
this decision it should be a separate discussion.

>> 4) there are no big gains of removing the deprecated methods: the new API
>> will be tested by all regression tests
- Subjective but currently the BGE code is quite hard to read,
removing duplicate functions means there is less code to wade through.
- Bugs in the API slip through a lot more easily when there are 4
access functions to the same variable. (getFoo, setFoo, setattr_foo,
getattr_foo), this is a problem with blenders python api, some bugs
are not found for years because they are only in one of the functions.

>> 5) keep the deprecated methods as an undocumented/unofficial feature.
Undocumented means we can clear out a whole lot of duplicate docs
which is an advantage but Im sure people will just keep using the
deprecated functions until they are forced to update, which means at
the end of the day there are people distributing blends with
undocumented api calls which makes it harder for new users to figure
out other peoples work. (sure they can look up old docs but its just
another stumbling block).

>> 6) I'm volunteering myself to maintain them for the time being
To me this does not solve the issue - its not like a single person
"maintains get/set functions",
- It's like saying - "lets keep verse/yafray/oops/bitmap-fonts in 2.5
and I will maintain",
The problem is having a lot of duplicate functionality makes an api
harder to maintain in general.

I'd be more inclined to go along with your request if you offered to
maintain the API, fix bugs, maintain docs, review patches, listen to
user request etc.
not just propping up the get/set functions if they break.

Currently there are parts of the api that are simply broken but nobody
has time to fix.. to run examples off the top of my head.
* CValue, Expression modules? - Why do we have these, what do they do,
were are they documented.
* VehicleWrapper, BL_Shader, PhysicsConstraints - no docs in
source/gameengine/PyDoc/
* VehicleWrapper no error checking on input, would be very easy to
crash blender using this module.
* CListValue - has append(), but no way to remove items... do we care?
does anyone use this to manipulate list data with anyway?

Further we took this approach with the blender/python api and just
ended up never removing any deprecated functions. Agreeing to keep
these for a while makes me think they will just end up staying there
until blender 3.0. to me this is a step backwards for reasons
mentioned above.

- Campbell

> 2009/5/6 <blender at erwincoumans.com>
>
>> I am against the plans to remove the deprecated methods in the BGE python
>> API (setPosition etc.), and volunteer to maintain those methods myself.
>>
>> (new members have been introduced to the Blender game engine python API, to
>> make it easier to access and assign data. obA.position = [1,2,3] instead of
>> method obA.setPosition(1,2,3)
>>
>> 1) increased compatibility with recent BGE books.
>> 2) it is easier to upgrade old scripts to Blender 2.5 and later
>> 3) always the option to using methods is more consistent: rather then
>> having
>> to remember which parts of the API are properties in disguise and which
>> still use methods
>> 4) there are no big gains of removing the deprecated methods: the new API
>> will be tested by all regression tests
>> 5) keep the deprecated methods as an undocumented/unofficial feature.
>> 6) I'm volunteering myself to maintain them for the time being
>>
>> I'm more happy to slowly let this API fade away, and remove them from the
>> python self-documentation, and make it an undocumented/unofficial feature.
>>
>> So unless there are big objections, please let me just maintain this
>> existing BGE python API as an undocumented/unofficial feature. If someone
>> is
>> tempted to removing the deprecated API, can you please get in touch we me?
>>
>> Thanks,
>> Erwin
>>