[Tutor] Re: How do you share a method (function) among several objects?

Liam Clarke cyresse at gmail.com
Sun Feb 27 23:04:13 CET 2005


yeah, I do the same thing for those useful functions that don't really
fit anywhere else.
I call it helperFunctions or something, so when your're importing
helperFunctions and calling helperFunctions.getCells() it's pretty
obvious what's happening.


Liam Clarke


On Sun, 27 Feb 2005 20:39:41 +0100, Pierre Barbier de Reuille
<pierre.barbier at cirad.fr> wrote:
> The position to put it is a design choice and there is no single best
> solution. What I'd do is to gather all the small "homeless" functions in
> a single separate module. And if they come to be too numerous, I'll sort
> them in some modules, ...
> 
> But that's because I don't like having a single function in a module ^_^
> Of course, if this is a complex function, that can make sense ...
> 
> I hope I helped and didn't make things worst ;)
> 
> Pierre
> 
> Xif a écrit :
> > Ok, so keeping getCells() as an external function makes sense.
> >
> > But where exactly do you recommend I'd put it?
> >
> > In a seperate module, like I currently do, even though it's going to be
> > the only piece of code contained inside that module?
> >
> > Xif
> >
> > Pierre Barbier de Reuille wrote:
> >
> >> Well, for me, the more logical answer is : multi-inheritance !
> >> If part of your class is the same, (same semantic, same
> >> implementation), then you want to have a base class for that.
> >>
> >> If you dislike this kindof inheritance, then your function should be
> >> an external one. Even more because it's 'just' an implementation
> >> function. The user don't need it as a method ... So why bother add it
> >> to your object ?
> >>
> >> Pierre
> >>
> >> Xif a יcrit :
> >>
> >>> Javier Ruere wrote:
> >>>
> >>>> Xif wrote:
> >>>>
> >>>>> Hello
> >>>>>
> >>>>> There are several different objects. However, they all share the same
> >>>>> function.
> >>>>>
> >>>>> Since they are not the same or similar, it's not logical to use a
> >>>>> common superclass.
> >>>>>
> >>>>> So I'm asking, what's a good way to allow those objects to share that
> >>>>> function?
> >>>>>
> >>>>> The best solution I've found so far is to put that function in a
> >>>>> module, and have all objects import and use it. But I doubt that's a
> >>>>> good use-case for modules; writing and importing a module that
> >>>>> contains
> >>>>> just a single function seems like an abuse.
> >>>>>
> >>>>> Thanks,
> >>>>> Xif
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>   Could you give an example?
> >>>>
> >>>> Javier
> >>>>
> >>>> _______________________________________________
> >>>> Tutor maillist  -  Tutor at python.org
> >>>> http://mail.python.org/mailman/listinfo/tutor
> >>>>
> >>>> +++++++++++++++++++++++++++++++++++++++++++
> >>>> This Mail Was Scanned By Mail-seCure System
> >>>> at the Tel-Aviv University CC.
> >>>>
> >>> Sure, I can describe my particular case.
> >>>
> >>> It's a program that retrieves / updates Microsoft Excel spreadsheet
> >>> data.
> >>>
> >>> There are two major classes:
> >>>
> >>> 1) an Excel class, that represents of the whole Excel program
> >>> 2) a Cells class, that abstracts retrieval  and editing of cells.
> >>>
> >>> Both classes use a function called getCells() as part of their
> >>> __getitem__() methods.
> >>>
> >>> getCells() parses the __getitem__() call arguments, and returns an
> >>> iterator over the appropriate cells.
> >>>
> >>> The difference between the 2 classes is that a Cells instance just
> >>> converts the generator into a list and returns it:
> >>>
> >>> #<code>
> >>> return list(getCells(self.sheet, cells))
> >>> #</code>
> >>>
> >>> while an Excel instance returns the values of the cells:
> >>>
> >>> #<code>
> >>> return [cell.Value for cell in getCells(self.sheet, cells)]
> >>> #</code>
> >>>
> >>> As you can see, both use the getCells() function.
> >>>
> >>> So my question is, where is the best way to put it so instances of
> >>> both classes can use it?
> >>>
> >>> Xif
> >>> _______________________________________________
> >>> Tutor maillist  -  Tutor at python.org
> >>> http://mail.python.org/mailman/listinfo/tutor
> >>>
> >>
> >
> 
> --
> Pierre Barbier de Reuille
> 
> INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
> Botanique et Bio-informatique de l'Architecture des Plantes
> TA40/PSII, Boulevard de la Lironde
> 34398 MONTPELLIER CEDEX 5, France
> 
> tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
> 


-- 
'There is only one basic human right, and that is to do as you damn well please.
And with it comes the only basic human duty, to take the consequences.


More information about the Tutor mailing list