ObjectRemovedEvent is sent *before* the object is removed

[Jan Wijbrand Kolman]

The ObjectRemovedEvent is fired when an contained item is removed from its container.

The current container implementations in zope.app.container fire this event *before* actually removing the item. Subscribers to this event will thus find the item still in its container (for example through the oldParent attribute on the event object).

So either the event's name is misleading and should be something like "ObjectAboutToBeRemovedEvent", or the event should be actually fired after the delete.

The latter solution would need a bit of work, since the helper functions (in zope.app.container.contained) that create and fire the event need access to the __parent__ of the item-to-be-deleted. One possibility could be, to have the uncontained function do the actual delete just after having constructed the event.

[Fred Drake (fdrake)]

I'm sure there's a way to say "Not a bug" or "Won't fix" in Launchpad, but I can't find it in this UI.

This has always been this way; the behavior can't be changed; that would be a backward compatibility failure. I vaguely recall this being discussed when this was first designed, and it was decided this was reasonable *because* subscribers would want to be able to use __parent__.

If you really need both the existing event *and* ObjectHasAlreadyBeenRemoved, present a feature request with a use case. Seems unlikely to be valuable IMO.