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 <[EMAIL PROTECTED]> 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@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@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@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. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
