Prev: Pool Module: iterator does not yield consistently with differentchunksizes
Next: drag & drop in a python GUI application
From: kedra marbun on 4 Jul 2010 06:26
i'm confused which part that doesn't make sense?
this is my 2nd attempt to py, the 1st was on april this year, it was
just a month, i'm afraid i haven't got the fundamentals right yet. so
i'm gonna lay out how i got to this conclusion, CMIIW

**explanation of feeling (0) on my 1st post**
to me, descriptor is a particular kind of delegation, it takes the job
of coding the delegation by having a contract with programmers that
the tree meta operations (get, set, del) on attr are delegated to the
obj that is bound to the attr
are we agree that descriptor is a kind of delegation?

the mechanism that makes descriptor works is in __getattribute__,
__setattr__, __delattr__ of 'object' & 'type'

now, if i want a single descriptor obj to be delegated to multiple
tasks, i can't do it since __get__ doesn't get info that can be used
to determine which task to do
i must have diff descriptor obj for each task

class Helper:
def __init__(self, name):
self.name = name
def __get__(self, ins, cls):
if self.name == 'task0': ...
elif self.name == 'task1': ...
else: ...

class a:
task0 = Helper('task0')
task1 = Helper('task1')

if __get__ receives the name, then i could do

class Helper:
def __get__(self, ins, cls, name):
...

class a:
task0 = task1 = Helper()

but after explaining this, i have more doubt on my own stmt in the 1st
post "not passing name strengthens the coupling between delegator &
delegate". now i think it's more likely the opposite, it weakens the
coupling at the expense of more objs. moreover, is it wrong to justify
that descriptor is a kind of delegation?

my ego speaks:
- i think, if the name is passed on, programmers can choose to use it
or not (i don't know if it brokes any py principle, i only know KISS)
- i realize that using name as the info that descriptors use to
determine which task to do, is going to strongly couple the descriptor
& the classes that use it, meaning that the descriptor & the user
classes must agree on attr names to be used. a simple solution to it
is by mapping attr names & names used in the descriptor

class Helper:
def __init__(self, name_map=None):
self.name_map = name_map
def __get__(self, ins, cls, name):
if self.name_map is None:
if name == 'task0': ...
...
else:
if self.name_map[name] == 'task0': ...
...


class a:
do_this = do_that = Helper({'do_this':'task0', 'do_that':'task1'})

finally, like all shared things, shared descriptor objs require more
effort for synchronization
From: kedra marbun on 4 Jul 2010 06:35
thanks Greg,
you get most of what i meant
like i said before, i suspect descriptor encourages dedicated / not
shared descriptor obj. this encouragement is expressed in the design,
and the reasons behind the design were the ones that i was asking
about, not how to get around it

now, i'm asking another favor, what about the 2nd point in my 1st post?
From: Gregory Ewing on 4 Jul 2010 20:49
kedra marbun wrote:

> now, i'm asking another favor, what about the 2nd point in my 1st post?

Your original post has dropped off my newsscope, so
you'll have to remind me what the 2nd point was.

--
Greg
From: Bruno Desthuilliers on 5 Jul 2010 04:42
kedra marbun a �crit :
> i'm confused which part that doesn't make sense?
> this is my 2nd attempt to py, the 1st was on april this year, it was
> just a month, i'm afraid i haven't got the fundamentals right yet. so
> i'm gonna lay out how i got to this conclusion, CMIIW
>
> **explanation of feeling (0) on my 1st post**
> to me, descriptor is a particular kind of delegation, it takes the job
> of coding the delegation by having a contract with programmers that
> the tree meta operations (get, set, del) on attr are delegated to the
> obj that is bound to the attr
> are we agree that descriptor is a kind of delegation?
>
> the mechanism that makes descriptor works is in __getattribute__,
> __setattr__, __delattr__ of 'object' & 'type'
>
> now, if i want a single descriptor obj to be delegated to multiple
> tasks, i can't do it since __get__ doesn't get info that can be used
> to determine which task to do
> i must have diff descriptor obj for each task
>
> class Helper:
> def __init__(self, name):
> self.name = name
> def __get__(self, ins, cls):
> if self.name == 'task0': ...
> elif self.name == 'task1': ...
> else: ...


Replacing such "big switch" code with polymorphic dispatch is one of the
goals (and feature) of OO. This should be:


class Task0(object):
def __get__(self, obj, cls):
# code here


class Task1(object):
def __get__(self, obj, cls):
# code here


class A(object):
task0 = Task0()
task1 = Task1()


If you have common code to share between TaskO and Task1 then factor it
out into a base class.


> if __get__ receives the name, then i could do
>
> class Helper:
> def __get__(self, ins, cls, name):
> ...
>
> class a:
> task0 = task1 = Helper()


Yuck.

From: kedra marbun on 6 Jul 2010 00:10
On Jul 5, 3:42 pm, Bruno Desthuilliers <bruno.
42.desthuilli...(a)websiteburo.invalid> wrote:
> kedra marbun a écrit :
>
>
>
> > i'm confused which part that doesn't make sense?
> > this is my 2nd attempt to py, the 1st was on april this year, it was
> > just a month, i'm afraid i haven't got the fundamentals right yet. so
> > i'm gonna lay out how i got to this conclusion, CMIIW
>
> > **explanation of feeling (0) on my 1st post**
> > to me, descriptor is a particular kind of delegation, it takes the job
> > of coding the delegation by having a contract with programmers that
> > the tree meta operations (get, set, del) on attr are delegated to the
> > obj that is bound to the attr
> > are we agree that descriptor is a kind of delegation?
>
> > the mechanism that makes descriptor works is in __getattribute__,
> > __setattr__, __delattr__ of 'object' & 'type'
>
> > now, if i want a single descriptor obj to be delegated to multiple
> > tasks, i can't do it since __get__ doesn't get info that can be used
> > to determine which task to do
> > i must have diff descriptor obj for each task
>
> > class Helper:
> >    def __init__(self, name):
> >            self.name = name
> >    def __get__(self, ins, cls):
> >            if self.name == 'task0': ...
> >            elif self.name == 'task1': ...
> >            else: ...
>
> Replacing such "big switch" code with polymorphic dispatch is one of the
>   goals (and feature) of OO. This should be:
>
> class Task0(object):
>      def __get__(self, obj, cls):
>          # code here
>
> class Task1(object):
>      def __get__(self, obj, cls):
>          # code here
>
> class A(object):
>      task0 = Task0()
>      task1 = Task1()
>
> If you have common code to share between TaskO and Task1 then factor it
> out into a base class.
>
> > if __get__ receives the name, then i could do
>
> > class Helper:
> >    def __get__(self, ins, cls, name):
> >            ...
>
> > class a:
> >    task0 = task1 = Helper()
>
> Yuck.

what's so 'Yuck' about it? ;)
i guess i need a strong stmt: is descriptor a kind of delegation? or
is it not?
* if it is a kind of delegation, then the code that you labeled as
'Yuck' is just a result of applying delegation
what's wrong with delegating multiple tasks to a single obj?

that code is similar to this

class Helper:
def do_this(self, ins): ...
def do_that(self, ins): ...

class a:
delegate = Helper()
def task0(self): self.delegate.do_that(self)
def task1(self): self.delegate.do_this(self)

the diff is that this code manually code the delegation, that's why it
can branches to 2 funcs. while descriptor takes all to __get__,
because it works on more meta lv

* if it's not, then there's nothing to be argued, the name
'descriptor' is perfectly fit: descriptor obj describes attr of class,
with 'describe' translates to: . = del, in py vocabularies. then, to
think a single descriptor obj describing a single attr is acceptable,
it's a common sense
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Pool Module: iterator does not yield consistently with differentchunksizes
Next: drag & drop in a python GUI application