On Sep 27, 1:44 am, "Dmitry S. Makovey" <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
> > Although this works, the second argument to ProxyMethod shouldn't be
> > necessary, it's semantically redundant; ideally you would like to
> > write it as "bmethod = ProxyMethod('b')".
>
> since I'm already on exploratory trail (what about that rug being pulled
> from under....?) With my code I can do really dirty tricks like this (not
> necessary that I'm going to):
>
> class B_base:
> def bmethod(self):
> print 'B_base'
>
> class B(B_base):
> def bmethod(self):
> print 'B'
>
> class A:
> bmethod=ProxyMethod('b',B_base.bmethod)
Yes, that's indeed dirty; don't do it :)
> > As before, I don't think
> > that's doable without metaclasses (or worse, stack frame hacking).
> > Below is the update of my original recipe; interestingly, it's
> > (slightly) simpler than before:
>
> Out of curiosity (and trying to understand): why do you insist on
> dictionaries with strings contents ( {'bmethod' : 'b1' } ) rather than
> something more explicit ? Again, I can see that your code is working and I
> can even understand what it's doing, just trying to explore alternatives :)
>
> I guess my bias is towards more explicit declarations thus
>
> bmethod=ProxyMethod('b',B.bmethod)
>
> looks more attractive to me, but I stand to be corrected/educated why is
> that not the right thing to do?
I see where you're coming from and I also prefer explicit reflection
mechanisms instead of strings (e.g. avoid eval/exec as much as
possible). As I mentioned, the second argument to ProxyMethod is (for
all sane purposes) redundant, so if you could implement it in a way
that "bmethod = ProxyMethod('b')" worked, I would be all for it, but
AFAIK it's not possible without a metaclass. A dict with string keys
and values to be consumed by a metaclass is perhaps the simplest thing
that could possibly work. It contains all the relevant information for
hooking the proxy to the delegate methods and nothing more; zero
boilerplate code overhead. Also note that it's not that big of a
difference; you have to provide the attribute name as a string anyway.
> Another thing that turns me away from string dictionaries is that those are
> the ones causing me more trouble hunting down typos. Maybe it's just "my
> thing" so I'm not going to insist on it. I'm open to arguments against that
> theory.
>From my experience, I am equally prone to typos for both strings and
regular attributes; I agree though that the traceback information is
often more helpful when you mistype an attribute.
> One argument I can bring in defence of more explicit declarations is IDE
> parsing when autocompletion for B.bme... pops up (suggesting bmethod and
> bmethod2) and with 'b':'bmethod' it never happens.
I don't rely on autocompleting IDEs, at least in dynamic languages, so
it's not much of an issue for me but yes, it's another small argument
against strings.
George
--
http://mail.python.org/mailman/listinfo/python-list
