Zac Burns a écrit :
To Bruno's first e-mail: Everything you said was correct but largely
off topic.
for a definition of "off topic" equals to "didn't fit your expectations".
I did already understand these things as well.
Sorry - but it was not necessarily obvious from your post, and it's near
to impossible to guess someone's background on a single post basis. So
please don't hold it against me. Anyway, you're not the only people
reading this group, and some readers might not have the same knowledge.
To Bruno's second email
quote:
"""
Nope. He's relying on (part of) the interface(s) implemented by the
first argument. The class object itself has nothing to do with is
(well... it does, but only as far as it contribute to the
implementation of the interface expected by the decorator).
"""
Yes - this is exactly what I was trying to communicate. In addition -
perhaps what I should have made clear all along is that the interface
I'm relying on isn't as much of an interface as it is an
implementation. The attributes that I will be accessing are 'local'
(starting with underscores, let's not get into a discussion about this
- I know they aren't really local) and are subject to change as the
implementation of the class changes.
Ok.
The class provides a 'service' for the inherited classes with
differing behaviors for different method via the decorators it
provides.
Not sure it's quite clear to me, but I think I get the whole picture.
The details of which I can't get into because it's
proprietary.
No problem - the above precisions are enough IMHO.
If this use case is objectionable to you then fine, I've implemented
my own staticdecorator.
What I still find questionable is the "necessity" to make your
decorators part of the base class. OO is about objects - not classes -
and Python's functions _are_ objects (just like modules, classes and
everything else FWIW), so even if your decorators are bound to a
specific implementation, well, what's the problem ? (BTW, please read
until the end of the post before replying). Just document the fact that
they only accept instances of your base class, and that's enough - well,
IMHO at least !-).
Anyway, given Python's highly dynamic nature, being an instance of a
given class _at a given moment in time_ doesn't garantee you have this
or this _implementation attribute - at best, it makes it highly
plausible, but that's all you can expect, really.
(which simply inherits from staticmethod and
implements call).
If it makes you feel better - no judgement call on this, I personnaly
care a lot about feeling good with my own code, and perfectly understand
we don't all have the same feeling about what looks right or wrong -,
then go for it. FWIW, I might even agree with your choice if I saw the
real code and knew the whole context. My point was just that it was not
*technically* necessary to make the decorators part of the base class !-)
But to those who the use case makes sense for it may
be worth thinking about implementing the call method in the main
distribution.
Python is a free, opensource software, so feel free to send the patch -
who knows, it might even be accepted if don't break anything. But
prepare to make your point, the BDFL tends to be very conservative
(which is a very GoodThing(tm) IMHO).
--
http://mail.python.org/mailman/listinfo/python-list
