dippim wrote:
On Aug 14, 10:48 am, Dave Angel <da...@ieee.org> wrote:
dippim wrote:
On Aug 14, 2:34 am, Raymond Hettinger <pyt...@rcn.com> wrote:
[David]
I am new to Python and I have a question about descriptors. If I have
a class as written below, is there a way to use descriptors to be
certain that the datetime in start is always before the one in end?
class foo(object):
def __init__(self,a =e,b = None)
self.start > >>> self.end >
from datetime import datetime
c =etime(2009,8,13,6,15,0)
d =etime(2009,8,14,12,0,0)
afoo =(c,d)
For instance, if the following code were run, I would like to instance
of foo to switch the start and end times.
afoo.start =etime(2010,8,13,6,15,0)
I was thinking of using the __set__ descriptor to catch the assignment
and reverse the values if necessary, but I can't figure out how to
determine which values is being set.
You're on the right track, but it is easier to use property() than to
write your own custom descriptor with __get__ and __set__.
class foo(object):
def __init__(self,a =e,b = None):
self._start > >> self._end > >> def get_start(self):
return self._start
def set_start(self, value):
if self._end is None or value < self._end:
self._start =ue
else:
self._end =ue
start =perty(get_start, set_start)
def get_end(self):
return self._end
def set_end(self, value):
if self._start is None or value > self._start:
self._end =ue
else:
self._start =ue
end =perty(get_end, set_end)
Raymond
Raymond,
This functionality is exactly what I was looking for. Thanks! I'll
be using this to solve my problem.
Now that I'm on the right track, I'm still a bit confused about how
__get__ and __set__ are useful. Admittedly, I don't need to
understand them to solve this problem, but perhaps they may be useful
in the future. If I wanted to solve this problem using __get__ and
__set__ could it be done?
Thanks Again!
DANGER- WILL ROBINSON!
Don't use this code as-is. There is a nasty surprise waiting for the
caller when he sets start and end, and discovers that one of them gets
thrown out, and an old value still remains.
obj=oo(3, 5)
obj.start = 8
obj.end = 12
print obj.start, obj.end
will print out 3, 12. Not what the caller expected.
You're right about this and I appreciate the warning, but I think what
Raymond was going for was directional accuracy without a great deal of
his time wasted on details. The explanation served the purpose of
moving me forward using property() and I'm thankful for it.
Four fixes, in order of preference:
0) Trust your user to read and obey your docstrings. This was what JM
was implying, by changing the names of the formal parameters.
Considering I am not the sharpest knife in the drawer, I don't wish to
start a philosophical discussion about the relative aptitude and
capabilities of the people who might use a class I build. However, I
will say that as this particular requirement is imposed on this class
by the writer, shouldn't it be the writer's responsibility to enforce
it, especially, when the cost of enforcement is so low?
1) make a new method that sets both values, making these two properties
readonly. That new method would make sure the two parameters are
self-consistent. Making the actual values readonly can be done with a
descriptor as well, or even a decorator.
2) Raise an exception in the getter methods if they're out of order
3) do the min/max logic on the getter methods, but I don't like that one
at all.
DaveA
I'm going to assume by "writer" you mean yourself? In other words, the
interface isn't being forced upon you by someone else? So I'll continue
to push for a cleaner/clearer interface.
I'm not going to make any judgment about the relative abilities of you
and the caller of your class. You make the final judgment call on how
much you want to bulletproof your interface.
But occasionally the "automatic fix" causes more problems than it
solves. Now, this time you use the word "enforce," which is much
different than the original implied "fix up." So I'll assume you mean
it literally, that you want to detect when the caller has broken the
rules, and raise an exception in that case. In either case, you need to
define what "the rules" are. And normally this is done by specifying
invariants.
I think you're declaring an invariant that, at all times, the object has
two datetime attributes, and that obj.start is no greater than obj.end.
If the attributes are individually writable, and you do the swap at that
time, you get into the trouble I described above. On the other hand, if
you just do a raise, then your caller would still get into trouble for
the same sequence of calls.
So the cure is to either make a new method that explicitly changes both,
or don't do the actual check for order till he tries to read the
values. In that latter case, you're changing the invariant subtly, to
say that if the object is temporarily in an invalid state, one cannot
call any other methods or fetch values till the state has been
corrected. A real pain to describe, but occasionally useful.
This problem of an object temporarily being in an invalid state is not
an uncommon one. But most of us have fallen into one of the pitfalls at
one time or another.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
