Aha! Thanks for this info, Greg and Lenard!!
Also, thanks, Lendard, I do think this is worth opening an issue about.
It seems that it is not a .dict() method, but a .dict attribute. It appears
to be almost the equivalent of dir(), lacking the .type entry, but including
the other attributes that matter:
Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit (Intel)]
on win32
Type "copyright", "credits" or "license()" for more information.
>>> import pygame
>>> ev = pygame.event.Event( pygame.USEREVENT, {'id':'test',
'internal':False} )
>>> dict(ev)
Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
dict(ev)
TypeError: 'Event' object is not iterable
>>> ev.dict()
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
ev.dict()
TypeError: 'dict' object is not callable
>>> ev.__dict__
Traceback (most recent call last):
File "<pyshell#6>", line 1, in <module>
ev.__dict__
AttributeError: event member not defined
>>> ev.dict
{'internal': False, 'id': 'test'}
>>>
On Sun, Feb 6, 2011 at 2:19 PM, Lenard Lindstrom <le...@telus.net> wrote:
> Hi David,
>
> On 05/02/11 08:01 PM, David Burton wrote:
>
>> **
>> *
>> *
>> *..., I have noticed that pygame events are somewhat weird. They are
>> objects, but they don't always behave like proper Python objects. There's
>> no __dict__ attribute, and dir() doesn't work, which I find annoying:*
>>
>>
>> Python 3.1.3 (r313:86834, Nov 27 2010, 18:30:53) [MSC v.1500 32 bit
>> (Intel)] on win32
>> Type "copyright", "credits" or "license()" for more information.
>> >>> import pygame
>> >>> ev = pygame.event.Event( pygame.USEREVENT, {'id':'test',
>> 'internal':False} )
>> >>> dir(ev)
>> []
>> >>> ev.__dict__
>> Traceback (most recent call last):
>> File "<pyshell#6>", line 1, in <module>
>> ev.__dict__
>> AttributeError: event member not defined
>> >>> ev.type
>> 24
>> >>> ev.id <http://ev.id>
>>
>> 'test'
>> >>> ev.internal
>> False
>> >>> repr(ev)
>> "<Event(24-UserEvent {'internal': False, 'id': 'test'})>"
>> >>>
>>
>> *Contrast that with how other Python objects behave:*
>>
>> >>> class junk:
>> fee = 1
>> fie = True
>> foe = 'giant'
>> fum = (1,2,3)
>>
>> >>> j1 = junk()
>> >>> repr(j1)
>> '<__main__.junk object at 0x034FA870>'
>> >>> dir(j1)
>> ['__class__', '__delattr__', '__dict__', '__doc__', '__eq__',
>> '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
>> '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__',
>> '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
>> '__str__', '__subclasshook__', '__weakref__', 'fee', 'fie', 'foe', 'fum']
>>
>>
>> *See what I mean? With other Python objects, it is easy to enumerate the
>> attributes of an object. But it is not obvious how to do that for pygame
>> event objects (though repr() somehow manages it).*
>> *
>> *
>> *Does anyone know how repr() manages to find the attributes for the pygame
>> event, since dir() doesn't work?*
>> *
>> *
>>
>> Pygame predates Python 2.2, when types became classes. I suppose the
> Event type was never updated. Also, the Event attributes may be read-only
> intentionally. I don't know for sure. If you are requesting a __dict__ for
> Event types I will add an issue to the Pygame tracker at Motherhamster and
> have a look. Even if system generated events need to keep their attributes
> immutable, I see no problem with mutable attibutes on user generated events.
>
> repr() uses a different mechanism from Python attribute access, a separate
> tp slot function. This function directly accesses the event's dictionary at
> C level, even when it is hidden from dir() at the Python level.
>
> Lenard Lindstrom
>
>
On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing <greg.ew...@canterbury.ac.nz>
wrote:
> David Burton wrote:
> ...
>
>> *However, I have noticed that pygame events are somewhat weird. They are
>> objects, but they don't always behave like proper Python objects. There's
>> no __dict__ attribute, and dir() doesn't work,
>>
>
> According to the docs, they have a dict() method instead.
>
> --
> Greg
>
