[Bf-committers] Idea: deprecate the attribute access for user properties in the BGE

Campbell Barton ideasman42 at gmail.com
Mon May 25 23:55:53 CEST 2009


This is the reaction I was expecting from users,
Some things to consider...

* allowing properties to be accessed through attributes always allows
conflicts if we add new attributes since SOME game may use the
attributes as names, you could argue that we should use get/set funcs
always however attributes have been in the BGE for a long time
along-side get/set's too.

* its less obvious to read, what are built in attributes and what are
user defined ones.

* typo's in setting attributes will fail silently

* even though gameOb.someAttr is less typing then gameOb["someAttr"],
I often see things like this...
  getattr(gameOb, "someAttr" + str(i))
  # With getitem style access it looks like this which I find less cumbersome...
  gameOb["someAttr" + str(i)]
... same for setattr, hasattr

* GameObject properties are a closer match to python dictionaries then
class attributes, (they could have spaces in the name for instance).

* I don't see python (or lua) coders complain that dictionary access
is 'hard', or 'ugly'

* Including both methods is OK but I prefer not to be sloppy in
allowing multiple conventions, I never saw this before in a python API
before and for good reason, separating the methods out also speeds up
access (not by a huge amount but since people are writing games it
doesn't hurt).

The ONLY reason I can think to keep attribute access is that its
slightly easier to type, but from most other reasonings Id prefer to
drop it.


On Mon, May 25, 2009 at 10:51 AM,  <blender at erwincoumans.com> wrote:
>
>  -1, it will make writing scripts very ugly.
>
> I rather would like to leave all options available to the user, and let them
> choose what they prefer, including the original methods.
>
> Thanks,
> Erwin
>
>
>
>
>
>
>
>
> Campbell Barton writes:
>
>> +1, practically this isn't a very bug change to 2.49
>> it only means adding a warning since both access methods are currently
>> supported.
>>
>> Wasn't sure if we should deprecate attribute style access because I
>> taught users would complain, interesting ZanQdo and yourself asked for
>> this change separately, Blengine is ok about it too (as an example of
>> a BGE user who isn't a total python/correctness pendent :) ).
>>
>> On 5/25/09, José Ignacio <jose.cyborg at gmail.com> wrote:
>>> On Mon, May 25, 2009 at 1:16 PM, José Ignacio <jose.cyborg at gmail.com> wrote:
>>>  > Proposal:
>>>  > Deprecate & remove attribute access for user properties in
>>>  > KX_GameObject in favor of the recently introduced dictionary syntax.
>>>  > this: obj.userprop would become: obj["userprop"]
>>>  >
>>>  > Rationale:
>>>  > - Dictionary access allows the used of reserved or even illegal python
>>>  > names (like "for" and "class"), like the GUI and the logic bricks let
>>>  > you do now (thus being consistent with them), plus preventing name
>>>  > clashes between these and current/future class attributes. This is
>>>  > very important for beginners (and maybe even people with some
>>>  > experience), that would start wondering "why cant i access this
>>>  > property in python while i can use it perfectly with logic bricks?"
>>>  > - It is way faster, since it doesn't have to go trough all the python
>>>  > getattr system and dicts have very fast lookups.
>>>  > - Also, since names are python strings lets you do things would have
>>>  > to do with a __getattr() hack
>>>  > - Typing a class attribute wrong assignation would raise an exception
>>>  > instead of failing silently. For example, typing
>>>  > # -----------------------------
>>>  > obj.poistion = [1, 2.5, 3] # notice the typo
>>>  > # -----------------------------
>>>  > would create a property called "poistion" instead of raising an
>>>  > exception, thus leading to headaches and a lot of time wasting trying
>>>  > to find the issue. More if we are talking about beginners.
>>>  >
>>>  sorry, the last argument has some mistakes, should read as follows:
>>>
>>>  - With the attribute access removed, typing a class attribute wrong
>>>  in an assignation operation would raise an exception instead of
>>>  failing silently.
>>>  For example, typing in the current engine:
>>>  # -----------------------------
>>>  obj.poistion = [1, 2.5, 3] # notice the typo
>>>  # -----------------------------
>>>  would create a property called "poistion" instead of raising an
>>>  exception, thus leading to headaches and a lot of time wasting trying
>>>  to find the issue. More if we are talking about beginners.
>>>
>>>  > -- love
>>>  > cyborg_ar
>>>  >
>>>  _______________________________________________
>>>  Bf-committers mailing list
>>>  Bf-committers at blender.org
>>>  http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>>
>> --
>> - Campbell
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell


More information about the Bf-committers mailing list