Thanks for the clarification Alex. Take care.
On Feb 8, 8:09 am, Alex Holkner <[email protected]> wrote:
> On Mon, Feb 9, 2009 at 12:01 AM, sol <[email protected]> wrote:
>
> > Hi Alex,
>
> > Would you mind commenting on my followup comment about the @event. I
> > just would like to know if this is really a doc error or an
> > implementation error.
>
> Sorry about that..
>
> > Is it really a doc error though? Now that I think about it, would the
> > @event not be much more useful for pushing than setting?
>
> Possibly, but I'm not in favour of backward-incompatible changes,
> until there's a backward-incompatible pyglet release (none planned at
> this stage). It's not difficult to write your own decorator that
> works this way and either monkey-patch it onto EventDispatcher or call
> it with the dispatcher as an argument.
>
> > Also, has it always been this way, I 'think' that it used to push in a
> > earlier release, but that may be me dreaming. ;)
>
> In pyglet-1.0-maintenance, @event called setattr(dispatcher, event,
> handler) -- equivalent to set_handler unless a handler was already
> pushed on, in which case the @event handler would be inserted behind
> the pushed one (a defect, not desirable).
>
> In pyglet-1.1-maintenance and trunk, @event calls set_handler. I
> didn't check the alpha or beta or in-between releases, there may have
> been a time when the behaviour was different; I don't recall.
>
> Alex.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
