----- Original Message -----
> On 10/10/2013 11:52 AM, Jiri Zupka wrote:
> > Hi Chris,
> > in attachment is proposal for decorator version of propcan as we talked
> > before.
> > From the line 48 is decorator implementation.
> > pproperty is compatible with python 2.4.3 which is in rhel 5.
> > When later version of the python is used it is be possible use build-in
> > property.
> > Please take a look a let me know what you mean about this implementation.
> >
> > only problem which I could see is the need to define wildcard slots _x
> > instead of x.
> > Example:
> > class D(PropCan, CopySlots):
> > __slots__ = ['_x', 'y']
> >
> > @pproperty
> > def x(self):
> > """ aaaa """
> > print "Get"
> > return self._x
> >
> > @x.setter
> > def x(self, value):
> > print "Set"
> > self._x = value
> >
> > @x.deleter
> > def x(self):
> > del self._x
> >
> > regards,
> > Jiří Župka
> >
>
> Woops, sorry I didn't notice this, I was looking for a pull-request.
> TBH, I really don't know much about writing decorators, but I'll try to
> understand...
>
> Hmm, ahh, is this a kind of back-port of how property-decorators work in
> 2.6?
>
> ---
>
> I'm not sure the '_x' is actually needed since PropCan itself is a
> dict-subclass, couldn't we replace the '_x' reference with a
> self.__dict_get__(whatever)?
>
> ---
>
> Not sure, but this could present a problem:
>
> class Propcan(object):
> __slots__ = ('__doc__', "fset", "fget", "fdel")
>
> There are some users (like Virsh class) that are sometimes passed around
> as dictionaries. If the interface itself is exposed at all in
> __slots__, doesn't that mean it could get passed around as well?
> Couldn't that lead to operation-order problems with the referant and
> referer?
>
> ---
>
> class PropCan(object):
>
> *head scratch* I think we need different naming so 'Propcan' is
> distinguished from 'PropCan' more.
>
> ---
>
> Hmmm, this seems like a really big change. While it seems to work, I'm
> nervous about how it will play with all the existing code. It may turn
> out to be much more work than fixing our first attempt.
I agree is reasonable. We could repair only new version of PropCan.
>
> Have you looked at what the problem was? I though it was just a simple
> typo '__all_slots' vs '__all_slots__', no? Was it a big
> gooie-hairry-hairball?
I think yes it was only typo in bug report. And I hope that I found that
problem too and I fix it in this commit
https://github.com/jzupka/virt-test/commit/6de20d4e8c6d74f3816dc97b53df97fe62d8e53a
But new version of propcan creates another problem with resolution of VM.
VM reboot during migration as Lucas said because there is problem with VM
comparing.
But with
https://github.com/jzupka/virt-test/commit/6de20d4e8c6d74f3816dc97b53df97fe62d8e53a
fix
I was never got problem with reboot VM during migration.
I'll try get more investigation on that and ...
>
> --
> Chris Evich, RHCA, RHCE, RHCDS, RHCSS
> Quality Assurance Engineer
> e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214
>
Thanks for your response and have a nice day,
Jiří Župka
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
