Prev: per-function jit compiler
Next: Loading an imported module (C API)
From: Tim Arnold on 7 Apr 2010 12:50
On Apr 6, 11:19 am, Jean-Michel Pichavant <jeanmic...(a)sequans.com>
wrote:
> Tim Arnold wrote:
> > Hi,
> > I have a few classes that manipulate documents. One is really a
> > process that I use a class for just to bundle a bunch of functions
> > together (and to keep my call signatures the same for each of my
> > manipulator classes).
>
> > So my question is whether it's bad practice to set things up so each
> > method operates on self.document or should I pass document around from
> > one function to the next?
> > pseudo code:
>
> > class ManipulatorA(object):
> >     def process(self, document):
> >         document = self.do_one_thing(document)
> >         document = self.do_another_thing(document)
> >         # bunch of similar lines
> >         return document
>
> > or
>
> > class ManipulatorA(object):
> >     def process(self, document):
> >         self.document = document
> >         self.do_one_thing() # operates on self.document
> >         self.do_another_thing()
> >         # bunch of similar lines
> >         return self.document
>
> > I ask because I've been told that the first case is easier to
> > understand. I never thought of it before, so I'd appreciate any
> > comments.
> > thanks,
> > --Tim
>
> Usually, when using classes as namespace, functions are declared as
> static (or as classmethod if required).
> e.g.
>
> class Foo:
>     @classmethod
>     def process(cls, document):
>         print 'process of'
>         cls.foo(document)
>
>     @staticmethod
>     def foo(document):
>         print document
>
> In [5]: Foo.process('my document')
> process of
> my document
>
> There is no more question about self, 'cause there is no more self. You
> don't need to create any instance of Foo neither.
>
> JM

Thanks for the input. I had always wondered about static methods; I'd
ask myself "why don't they just write a function in the first place?"

Now I see why. My situation poses a problem that I guess static
methods were invented to solve. And it settles the question about
using self.document since there is no longer any self. And as Bruno
says, it's easier to understand and refactor.

thanks,
--Tim
From: Lie Ryan on 7 Apr 2010 19:31
On 04/07/10 18:34, Bruno Desthuilliers wrote:
> Lie Ryan a �crit :
> (snip)
>
>> Since in function in python is a first-class object, you can instead do
>> something like:
>>
>> def process(document):
>> # note: document should encapsulate its own logic
>> document.do_one_thing()
>
> Obvious case of encapsulation abuse here. Should a file object
> encapsulate all the csv parsing logic ? (and the html parsing, xml
> parsing, image manipulation etc...) ? Should a "model" object
> encapsulate the presentation logic ? I could go on for hours here...

Yes, but no; you're taking it out of context. Is {csv|html|xml|image}
parsing logic a document's logic? Is presentation a document's logic? If
they're not, then they do not belong in document.
From: Bruno Desthuilliers on 8 Apr 2010 04:20
Lie Ryan a �crit :
> On 04/07/10 18:34, Bruno Desthuilliers wrote:
>> Lie Ryan a �crit :
>> (snip)
>>
>>> Since in function in python is a first-class object, you can instead do
>>> something like:
>>>
>>> def process(document):
>>> # note: document should encapsulate its own logic
>>> document.do_one_thing()
>> Obvious case of encapsulation abuse here. Should a file object
>> encapsulate all the csv parsing logic ? (and the html parsing, xml
>> parsing, image manipulation etc...) ? Should a "model" object
>> encapsulate the presentation logic ? I could go on for hours here...
>
> Yes, but no; you're taking it out of context. Is {csv|html|xml|image}
> parsing logic a document's logic? Is presentation a document's logic? If
> they're not, then they do not belong in document.

Is len() a list logic ? If yes, it should belong to list !-)

There are two points here : the first is that we (that is, at least, you
and me) just don't know enough about the OP's project to tell whether
something should belong to the document or not. period. The second point
is that objects don't live in a splendid isolation, and it's perfectly
ok to have code outside an object's method working on the object.

wrt/ these two points, your "document should encapsulate its own logic"
note seems a bit dogmatic (and not necessarily right) to me - hence my
answer.

From: Tim Arnold on 8 Apr 2010 14:25
On Apr 8, 4:20 am, Bruno Desthuilliers <bruno.
42.desthuilli...(a)websiteburo.invalid> wrote:
> Lie Ryan a écrit :
>
>
>
>
>
> > On 04/07/10 18:34, Bruno Desthuilliers wrote:
> >> Lie Ryan a écrit :
> >> (snip)
>
> >>> Since in function in python is a first-class object, you can instead do
> >>> something like:
>
> >>> def process(document):
> >>>     # note: document should encapsulate its own logic
> >>>     document.do_one_thing()
> >> Obvious case of encapsulation abuse here. Should a file object
> >> encapsulate all the csv parsing logic ? (and the html parsing, xml
> >> parsing, image manipulation etc...) ? Should a "model" object
> >> encapsulate the presentation logic ? I could go on for hours here...
>
> > Yes, but no; you're taking it out of context. Is {csv|html|xml|image}
> > parsing logic a document's logic? Is presentation a document's logic? If
> > they're not, then they do not belong in document.
>
> Is len() a list logic ? If yes, it should belong to list !-)
>
> There are two points here : the first is that we (that is, at least, you
> and me) just don't know enough about the OP's project to tell whether
> something should belong to the document or not. period. The second point
> is that objects don't live in a splendid isolation, and it's perfectly
> ok to have code outside an object's method working on the object.
>
> wrt/ these two points, your "document should encapsulate its own logic"
> note seems a bit dogmatic (and not necessarily right) to me - hence my
> answer.

The 'document' in this case is an lxml Elementtree, so I think it
makes sense to have code outside the object (e.g. static methods)
working on the object.
thanks,
--Tim
From: Lie Ryan on 8 Apr 2010 21:05
On 04/08/10 18:20, Bruno Desthuilliers wrote:
> Lie Ryan a �crit :
>> On 04/07/10 18:34, Bruno Desthuilliers wrote:
>>> Lie Ryan a �crit :
>>> (snip)
>>>
>>>> Since in function in python is a first-class object, you can instead do
>>>> something like:
>>>>
>>>> def process(document):
>>>> # note: document should encapsulate its own logic
>>>> document.do_one_thing()
>>> Obvious case of encapsulation abuse here. Should a file object
>>> encapsulate all the csv parsing logic ? (and the html parsing, xml
>>> parsing, image manipulation etc...) ? Should a "model" object
>>> encapsulate the presentation logic ? I could go on for hours here...
>>
>> Yes, but no; you're taking it out of context. Is {csv|html|xml|image}
>> parsing logic a document's logic? Is presentation a document's logic? If
>> they're not, then they do not belong in document.
>
> Is len() a list logic ? If yes, it should belong to list !-)

Yes, that's why list.__len__() belongs to list while len() is a
convenience function that doesn't carry any concrete implementation.

> There are two points here : the first is that we (that is, at least, you
> and me) just don't know enough about the OP's project to tell whether
> something should belong to the document or not. period.

I think I see your point here. I retract my suggestion that it is
suitable for OP's purpose since I just realized OP is in a better
position to make the decision.

> The second point
> is that objects don't live in a splendid isolation, and it's perfectly
> ok to have code outside an object's method working on the object.
> wrt/ these two points, your "document should encapsulate its own logic"
> note seems a bit dogmatic (and not necessarily right) to me - hence my
> answer.

I agree with you about there are certain logics that should not be
inside the object (that's why I qualify the statement with `should`).
Glue logic, by definition, cannot be inside an object. I don't think we
are actually in disagreement here. But I think the dogma, followed with
caution, is generally good.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: per-function jit compiler
Next: Loading an imported module (C API)