j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
Antoine Pitrou wrote:
On Mon, 28 Jun 2010 15:29:25 +0200 "M.-A. Lemburg" email@example.com wrote:
Antoine Pitrou wrote:
On Mon, 28 Jun 2010 13:14:21 +0200 "M.-A. Lemburg" firstname.lastname@example.org wrote: >
BTW: I wonder why proxy objects don't provide a direct access to the weakref object they are using. That would make keeping that extra variable around unnecessary.
Probably because the proxy would then have an additional attribute which isn't on the proxied object. Or, worse, it could also shadow one of the proxied object's existing attributes.
That's a very weak argument, IMHO. It all depends on the naming of the attribute.
What name do you suggest that isn't cumbersome or awkward, and yet doesn't present any risk of conflict with attributes of the proxied object?
If you want to play safe, use something like '__weakref_object__'.
In mxProxy, we simply reserved all methods and attributes that start with 'proxy_' for use by the proxy object itself. That hasn't caused a conflict so far.
We've used such an approach on our mxProxy object for years without any problems or naming conflicts so far:
Well, if some features of mxProxy are useful, perhaps it would be worth integrating them in the stdlib.
We mainly use mxProxy for low-level access control to objects, and as a way to implement a cleanup protocol for breaking circular references early.
The weak reference feature was a later add-on and also serves as an additional way to prevent creation of circular references.
All this was designed prior to Python implementing the GC protocol which now implements something similar to the cleanup protocol we have in mxProxy.
Unlike the standard Python weakref implementation, mxProxy doesn't require changes to the proxy objects in order to create a weak reference. It works for all objects.
I don't know why Fred used a different approach.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Jun 28 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/