Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #66623 > unrolled thread

Re: Import order question

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Import order question Ben Finney <ben+python@benfinney.id.au> - 2014-02-18 06:40 +1100
    Re: Import order question Rick Johnson <rantingrickjohnson@gmail.com> - 2014-02-18 12:41 -0800
      Re: Import order question Chris Angelico <rosuav@gmail.com> - 2014-02-19 08:02 +1100
        Re: Import order question Rick Johnson <rantingrickjohnson@gmail.com> - 2014-02-18 13:44 -0800
          Re: Import order question Chris Angelico <rosuav@gmail.com> - 2014-02-19 08:49 +1100
            Re: Import order question Grant Edwards <invalid@invalid.invalid> - 2014-02-18 22:44 +0000
          Re: Import order question Tim Chase <python.list@tim.thechases.com> - 2014-02-18 16:17 -0600
            Re: Import order question Grant Edwards <invalid@invalid.invalid> - 2014-02-18 22:45 +0000
            Re: Import order question Rick Johnson <rantingrickjohnson@gmail.com> - 2014-02-18 14:49 -0800
          Re: Import order question Rotwang <sg552@hotmail.co.uk> - 2014-02-18 23:28 +0000
            Re: Import order question Rick Johnson <rantingrickjohnson@gmail.com> - 2014-02-18 15:41 -0800
              Re: Import order question Rotwang <sg552@hotmail.co.uk> - 2014-02-19 01:09 +0000
              Re: Import order question Steven D'Aprano <steve@pearwood.info> - 2014-02-19 07:32 +0000
            Re: Import order question MRAB <python@mrabarnett.plus.com> - 2014-02-19 00:18 +0000
          Re: Import order question Chris Angelico <rosuav@gmail.com> - 2014-02-19 12:57 +1100
          Re: Import order question Steven D'Aprano <steve@pearwood.info> - 2014-02-19 07:32 +0000
            Re: Import order question Chris Angelico <rosuav@gmail.com> - 2014-02-19 18:59 +1100
            Re: Import order question Roy Smith <roy@panix.com> - 2014-02-19 08:28 -0500

#66623 — Re: Import order question

Nagy László Zsolt <gandalf@shopzeus.com> writes:

> > Use modules to group your class definitions conceptually. There is
> > no need whatever to separate every class into a different module.

> If there is a consensus, and it is really desireable to put all these
> related classes into the same module, then this is what I'm going to
> do.

You should use multiple modules to separate the code where it makes
sense, along *conceptual* lines. Make separate modules that each
represent a conceptually-separate area of functionality in your
application, and put the classes which implement that functionality in
that module.

> I never know when to put classes in different modules. I usually draw
> an UML diagram and group classes into packages. Wich makes sense
> because there can be sub-groups with subpackages. But I'm always
> confused with modules, I don't know why.

You can start by making one module for each of those groupings. (The
term “package” already has a specific technical meaning in Python, and
I'm not sure whether that's what you meant here.)

> Thanks for the help.

Welcome to Python!

-- 
 \      “If sharing a thing in no way diminishes it, it is not rightly |
  `\                   owned if it is not shared.” —Augustine of Hippo |
_o__)                                                                  |
Ben Finney

[toc] | [next] | [standalone]

#66641

On Monday, February 17, 2014 1:40:41 PM UTC-6, Ben Finney wrote:
> Nagy László Zsolt ... writes:
> > > Use modules to group your class definitions conceptually. There is
> > > no need whatever to separate every class into a different module.
> > If there is a consensus, and it is really desireable to put all these
> > related classes into the same module, then this is what I'm going to
> > do.

It is not desirable to me, and i would argue truthfully,
to many others either.

> You should use multiple modules to separate the code where it makes
> sense, along *conceptual* lines. Make separate modules that each
> represent a conceptually-separate area of functionality in your
> application, and put the classes which implement that functionality in
> that module.

Classes with an "s"? As in many classes in one source file?
Are you insane man? Why oh why would you torture yourself
and others with such advice? Are you some sort of hard disc
neat freak? Do you fear cluttering your hard-drive with too
many files will overwork it? What of yourself?

I'm continually amazed by you "Java haters" who will
willingly place burdens on yourself just to spite that "mean
old Java". Splitting code into small source files is wise,
whereas, creating single monolithic monstrosities like
Tkinter should be a sin! A sin that should be punishable by
the Exception!

As the lines of code increase, so does the complexity of
navigating and maintaining large modules. Classes should
naturally exist in their own module with the exception of
small utility or special use classes that are not exposed
publicly.

Then you go and intermix the areas of "module source code"
and "module API". These are two distinct areas that need not
follow the same patterns. You can have 20 classes contained
in 20 different source files and then combine them
transparently at run-time so that as far as the client is
concerned, all the classes exist under one namespace.

    # ui_mod1.py
    class One():pass

    # ui_mod2.py
    class Two():pass

    # ui_mod3.py
    class Three():pass

    # ui_mod4.py
    class Four():pass

    # ui_main.py
    from ui_mod1 import *
    from ui_mod2 import *
    from ui_mod3 import *
    from ui_mod4 import *

At least by this method i can maintain the code base without
wearing-out my scroll finger and eventually loosing my mind.
THE MORAL: With very few exceptions, please put EVERY class
in it's own module.

[toc] | [prev] | [next] | [standalone]

#66644

On Wed, Feb 19, 2014 at 7:41 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
>     # ui_main.py
>     from ui_mod1 import *
>     from ui_mod2 import *
>     from ui_mod3 import *
>     from ui_mod4 import *
>
> At least by this method i can maintain the code base without
> wearing-out my scroll finger and eventually loosing my mind.
> THE MORAL: With very few exceptions, please put EVERY class
> in it's own module.

Absolutely definitely not. If you're going to import * into every
module, just write it all in a single source file. Otherwise, when
someone tries to find the source code for some particular class or
function, s/he has to go digging through all five source files - first
the utterly useless merge-point, then the four others, because there's
no way to know which one has it.

Python could make this easier for us, by retaining the origin of every
function and class. And maybe it's already there, but I don't know
about it. But even if it did exist (by the way, it would be useful for
other things than just taming a mad layout like this), it'd still be
better to keep everything combined, because the origin of a
function/class could just as easily go to the exact line as to the
file.

A module is a namespace. It should be used as such. If you want a
package, use a package. There's no point putting each class out
separate unless you really need that.

ChrisA

[toc] | [prev] | [next] | [standalone]

#66649

On Tuesday, February 18, 2014 3:02:26 PM UTC-6, Chris Angelico wrote:
> On Wed, Feb 19, 2014 at 7:41 AM, Rick Johnson wrote:
> >     # ui_main.py
> >     from ui_mod1 import *
> >     from ui_mod2 import *
> >     from ui_mod3 import *
> >     from ui_mod4 import *
> > At least by this method i can maintain the code base without
> > wearing-out my scroll finger and eventually loosing my mind.
> > THE MORAL: With very few exceptions, please put EVERY class
> > in it's own module.
> Absolutely definitely not. If you're going to import * into every
> module, just write it all in a single source file.

Writing multiple individual classes in multiple individual
modules, and then importing those individual classes under a
single namespace at run-time is key to exposing a monolithic
API to a client without storing all the source code in a
monolithic file. The "Tkinter" folks would be wise to follow
my advise!

But I'm not suggesting this is the solution to EVERY
problem, or even that this is the solution to the OP's
current problem, what i am suggesting is that source files
should be kept as short as possible so as to accommodate easy
maintenance.

You see, unlike other languages, Python does not give us a
choice of the start and end of a Python module, there is no
keyword or delimiting chars that we can use to EXPLICITLY
define the start and end of a Python module. No, EVERY
Python script IS a module by default, and that is the law of
the land.

> Otherwise, when
> someone tries to find the source code for some particular class or
> function, s/he has to go digging through all five source files - first
> the utterly useless merge-point, then the four others, because there's
> no way to know which one has it.

Only if you're blind, or your source code was written by
people lacking even a modicum of common sense about how to
name a module. Most modules can simply be the name of the
containing class. Heck, even an idiot can manage that!

> Python could make this easier for us, by retaining the origin of every
> function and class. And maybe it's already there, but I don't know
> about it.

Google "inspect" and be enlightened. But Chris, if you have
to use the inspect module to find a class then sir, you need
lack: simple search tools, and/or motivation.

Are you telling me you're willing to search through a single
file containing 3,734 lines of code (yes, Tkinter) looking
for a method named "destroy" of a class named "OptionMenu"
(of which three other classes contain a method of the same
exact name!), when all you needed to do was open one single
module named "tk_optionmenu.py" and do a single search for
"def destroy"?

You must be trolling!

> But even if it did exist (by the way, it would be useful for
> other things than just taming a mad layout like this), it'd still be
> better to keep everything combined, because the origin of a
> function/class could just as easily go to the exact line as to the
> file.
> A module is a namespace. It should be used as such. If you want a
> package, use a package. There's no point putting each class out
> separate unless you really need that.

But in many cases you do! Chris, i think you missed the
entire crux of this thread. The OP is not writing a single
monolithic program where the code will ONLY be investigated
by the developers, no, he's creating an API, and API's
require structure.

But even if this were not an API, breaking large chunks of
code up and spreading them across individual files is the
key to managing code bases.

[toc] | [prev] | [next] | [standalone]

#66650

On Wed, Feb 19, 2014 at 8:44 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Are you telling me you're willing to search through a single
> file containing 3,734 lines of code (yes, Tkinter) looking
> for a method named "destroy" of a class named "OptionMenu"

Yeah, actually I am. At my last job, I had a single C++ file of
roughly 5K lines, and it wasn't at all unmanageable. Probably wouldn't
have been a problem to have another order of magnitude on that. What
sort of wimpy text editor are you using that you can't find what
you're looking for in a single large file? Less steps to get to the
file, more searching within the file. Much easier.

ChrisA

[toc] | [prev] | [next] | [standalone]

#66653

On 2014-02-18, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Feb 19, 2014 at 8:44 AM, Rick Johnson
><rantingrickjohnson@gmail.com> wrote:
>> Are you telling me you're willing to search through a single
>> file containing 3,734 lines of code (yes, Tkinter) looking
>> for a method named "destroy" of a class named "OptionMenu"
>
> Yeah, actually I am.

Yup.  And there are new-fangled tools like grep and vi/emacs that even
make it easy!

> At my last job, I had a single C++ file of roughly 5K lines, and it
> wasn't at all unmanageable. Probably wouldn't have been a problem to
> have another order of magnitude on that. What sort of wimpy text
> editor are you using that you can't find what you're looking for in a
> single large file? Less steps to get to the file, more searching
> within the file. Much easier.

Definitely.  I've worked on a number C projects where the source code
was pointlessly split up into a whole slew of files.  AFAICT, it
wasn't done to provide separate namespaces or for information hiding
or code reuse. It was just done to piss me off when I'm trying to find
something...

-- 
Grant Edwards               grant.b.edwards        Yow! Maybe I should have
                                  at               asked for my Neutron Bomb
                              gmail.com            in PAISLEY --

[toc] | [prev] | [next] | [standalone]

#66652

On 2014-02-19 08:49, Chris Angelico wrote:
> > Are you telling me you're willing to search through a single
> > file containing 3,734 lines of code (yes, Tkinter) looking
> > for a method named "destroy" of a class named "OptionMenu"  
> 
> At my last job, I had a single C++ file of roughly 5K lines, and
> it wasn't at all unmanageable. Probably wouldn't have been a
> problem to have another order of magnitude on that. What sort of
> wimpy text editor are you using that you can't find what you're
> looking for in a single large file?

Even the venerable "ed" handles files of those sizes without batting
an eye.  I just opened a 2MB XML file (50k lines) in ed and jumped
all around in it with no trouble at all.  It's as simple as

  1;/class OptionMenu/;/def destroy/

in most cases.  If your editor can't help you do simple things like
that, I recommend you find an editor that is at least as good as
ed. :-)

-tkc

[toc] | [prev] | [next] | [standalone]

#66654

On 2014-02-18, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2014-02-19 08:49, Chris Angelico wrote:
>> > Are you telling me you're willing to search through a single
>> > file containing 3,734 lines of code (yes, Tkinter) looking
>> > for a method named "destroy" of a class named "OptionMenu"  
>> 
>> At my last job, I had a single C++ file of roughly 5K lines, and
>> it wasn't at all unmanageable. Probably wouldn't have been a
>> problem to have another order of magnitude on that. What sort of
>> wimpy text editor are you using that you can't find what you're
>> looking for in a single large file?
>
> Even the venerable "ed" handles files of those sizes without batting
> an eye.  I just opened a 2MB XML file (50k lines) in ed and jumped
> all around in it with no trouble at all.  It's as simple as
>
>   1;/class OptionMenu/;/def destroy/
>
> in most cases.  If your editor can't help you do simple things like
> that, I recommend you find an editor that is at least as good as
> ed. :-)

You think you're joking, but there are lot of editors that aren't.

-- 
Grant Edwards               grant.b.edwards        Yow! RELATIVES!!
                                  at               
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#66655

On Tuesday, February 18, 2014 4:17:48 PM UTC-6, Tim Chase wrote:
> On 2014-02-19 08:49, Chris Angelico wrote:
> > At my last job, I had a single C++ file of roughly 5K lines, and
> > it wasn't at all unmanageable. Probably wouldn't have been a
> > problem to have another order of magnitude on that. What sort of
> > wimpy text editor are you using that you can't find what you're
> > looking for in a single large file?
> Even the venerable "ed" handles files of those sizes without batting
> an eye.  I just opened a 2MB XML file (50k lines) in ed and jumped
> all around in it with no trouble at all.  It's as simple as
>   1;/class OptionMenu/;/def destroy/
> in most cases.  If your editor can't help you do simple things like
> that, I recommend you find an editor that is at least as good as
> ed. :-)

SarcasticSam: Who needs directories anyway when the
hard-drive is already one gigantic directory... THOSE IDIOTS!

Yes Sam, it seems this thread has degenerated into a testosterone
induced contest to determine who can open the largest file,
climb inside, and then jump around the fastest -- MAY THE
BEST MEAT-HEAD WIN!

For the rest of us --of which who respect brains over
brawn-- we'll swallow our foolish pride and wield the
technology of sane structures.

[toc] | [prev] | [next] | [standalone]

#66656

On 18/02/2014 21:44, Rick Johnson wrote:
> [...]
>
> Are you telling me you're willing to search through a single
> file containing 3,734 lines of code (yes, Tkinter) looking
> for a method named "destroy" of a class named "OptionMenu"
> (of which three other classes contain a method of the same
> exact name!), when all you needed to do was open one single
> module named "tk_optionmenu.py" and do a single search for
> "def destroy"?
>
> You must be trolling!

I have music software that's a single 9K-line Python module, which I 
edit using Notepad++ or gedit. If I wish to find e.g. the method "edit" 
of class "sequence" I can type

     <Ctrl-f>class seq<Return>def edit(<Return>

[toc] | [prev] | [next] | [standalone]

#66657

On Tuesday, February 18, 2014 5:28:21 PM UTC-6, Rotwang wrote:
> I have music software that's a single 9K-line Python module, which I 
> edit using Notepad++ or gedit. If I wish to find e.g. the method "edit" 
> of class "sequence" I can type
>      <Ctrl-f>class seq<Return>def edit(<Return

This is not about "how to use a search function"[1], because
even modules that contain ONLY *one* class can be many
hundreds or even thousands of lines, thereby demanding the
use of search functions/dialogs. 

Heck, when a class gets too big i even export some of the
methods to outside modules and load the methods dynamically
at run-time just to cut down on the length. I suppose my
detractors would find that surprising also!

[1] Red Herring, Red Herring!

[toc] | [prev] | [next] | [standalone]

#66659

On 18/02/2014 23:41, Rick Johnson wrote:
> On Tuesday, February 18, 2014 5:28:21 PM UTC-6, Rotwang wrote:

[snipped material restored for context]

>> On 18/02/2014 21:44, Rick Johnson wrote:
>>> [...]
>>>
>>> Are you telling me you're willing to search through a single
>>> file containing 3,734 lines of code (yes, Tkinter) looking
>>> for a method named "destroy" of a class named "OptionMenu"
>>> (of which three other classes contain a method of the same
>>> exact name!), when all you needed to do was open one single
>>> module named "tk_optionmenu.py" and do a single search for
>>> "def destroy"?
>>>
>>> You must be trolling!
>>
>> I have music software that's a single 9K-line Python module, which I
>> edit using Notepad++ or gedit. If I wish to find e.g. the method "edit"
>> of class "sequence" I can type
>>       <Ctrl-f>class seq<Return>def edit(<Return
>
> This is not about "how to use a search function"

No, it's about your incredulity that someone would search for a method 
in a large file that contains several methods of the same name. However, 
the existence of search functions makes this completely trivial.

[toc] | [prev] | [next] | [standalone]

#66670

On Tue, 18 Feb 2014 15:41:32 -0800, Rick Johnson wrote:

> Heck, when a class gets too big i even export some of the methods to
> outside modules and load the methods dynamically at run-time just to cut
> down on the length. I suppose my detractors would find that surprising
> also!

Not in the least bit surprising. I expected nothing less from you.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#66658

On 2014-02-18 23:28, Rotwang wrote:
> On 18/02/2014 21:44, Rick Johnson wrote:
>> [...]
>>
>> Are you telling me you're willing to search through a single
>> file containing 3,734 lines of code (yes, Tkinter) looking
>> for a method named "destroy" of a class named "OptionMenu"
>> (of which three other classes contain a method of the same
>> exact name!), when all you needed to do was open one single
>> module named "tk_optionmenu.py" and do a single search for
>> "def destroy"?
>>
>> You must be trolling!
>
> I have music software that's a single 9K-line Python module, which I
> edit using Notepad++ or gedit. If I wish to find e.g. the method "edit"
> of class "sequence" I can type
>
>       <Ctrl-f>class seq<Return>def edit(<Return>
>
I use EditPad Pro. It has a File Navigator, which gives a hierarchical
view of functions, classes and methods.

[toc] | [prev] | [next] | [standalone]

#66662

On Wed, Feb 19, 2014 at 9:17 AM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 2014-02-19 08:49, Chris Angelico wrote:
>> > Are you telling me you're willing to search through a single
>> > file containing 3,734 lines of code (yes, Tkinter) looking
>> > for a method named "destroy" of a class named "OptionMenu"
>>
>> At my last job, I had a single C++ file of roughly 5K lines, and
>> it wasn't at all unmanageable. Probably wouldn't have been a
>> problem to have another order of magnitude on that. What sort of
>> wimpy text editor are you using that you can't find what you're
>> looking for in a single large file?
>
> Even the venerable "ed" handles files of those sizes without batting
> an eye.  I just opened a 2MB XML file (50k lines) in ed and jumped
> all around in it with no trouble at all.

It's not just about whether your editor can handle a file of that
size, of course [1], but how well they help you find your way around
the codebase.

But ultimately, you're going to have those KLOC somewhere. Whether
they're in one file, a small handful of files, or eight hundred
separate tiny .PHP files (UGH UGH UGH UGH! and yes that was a real
thing and yes I had to search through it wince wince!), you somehow
need to find the one line you want out of, let's say, 50K. That's a
fairly small project by a lot of standards. Somehow, you need to find
one particular function. It might be named beautifully, in which case
a grep-across-files will do the job, or it might not. Maybe you can
see, as a human, that one of the subbranches MUST contain what you're
looking for (one file, or one directory, or something); but that often
requires knowledge of the codebase, which you mightn't have. So
splitting into files doesn't solve anything, and it introduces its own
set of problems.

Just for reference, here are a few line counts. They're based on "find
-name \*.FILE_EXT|xargs wc -l" in the base directories of several
projects (using an appropriate extension, as listed).

Small projects:
Proprietary project at my last job, *.cpp: 4782 (one file)
Same project, *.pike: 6559
Gypsum (open source MUD client), *.pike: 5083

Medium size projects:
CPython/Python, *.c: 55329
alsa-lib, *.c: 91131
SciTE, *.cxx: 114785 (34876 + Scintilla's 79909)
Pike, *.pike: 138705

Large projects:
Pike, *.c: 298773
CPython/Lib, *.py: 318232

(See how much of Python is written in Python? Although I can't help
feeling that my figures are wrong somehow. And that figure is ignoring
the test/ subdirectory with another 267872 lines for a total of
586104.)

I've done "search across files" in all of these, bar alsa-lib which I
line-counted just because it happened to be there. (Incidentally, I'm
fully aware that some of those figures are unfair. overall, I'd say
Pike and Python are comparable-sized projects, but Python's more
heavily written in Python and Pike's more heavily written in C, partly
by using a precompiler that's somewhat along the lines of Cython.
Scintilla includes a whole bunch of individual language lexers, and
it's usually pretty clear that you don't need to look in any of those.
Etc, etc.) It's usually been easy enough to find what I want; in fact,
the few times when it _hasn't_ have generally turned out to be because
of bugs (something had "desrtuct" instead of "destruct" in its name
and I of course couldn't find it). SciTE's search-across-files isn't
the best, but it covers 99%+ of my use cases. For anything else, well,
there's always popping up a terminal and using primitives like grep,
find, and so on.

ChrisA

[1] But as Grant hinted, some do have issues.

[toc] | [prev] | [next] | [standalone]

#66669

On Tue, 18 Feb 2014 13:44:47 -0800, Rick Johnson wrote:

> Are you telling me you're willing to search through a single file
> containing 3,734 lines of code (yes, Tkinter) looking for a method named
> "destroy" of a class named "OptionMenu" (of which three other classes
> contain a method of the same exact name!), when all you needed to do was
> open one single module named "tk_optionmenu.py" and do a single search
> for "def destroy"?

How do you know that the module tk_optionmenu.py contains the class 
OptionMenu? Perhaps it contains the function optionmenu. Or the class 
TK_OptionMenu. 

For a mere 4000 lines of code, yes, I'd rather have it all in the one 
file, presuming that they are all related pieces of code. Much, much, 
much easier to search, edit and maintain; avoids circular imports and 
other dependency problems.

If there are parts of that module that stand alone, then arguably they 
ought to be extracted out into a separate module. But other than that, 
4000 lines of code isn't so big that we should be splitting the file 
apart merely for the size.


[...]
> But even if this were not an API, breaking large chunks of code up and
> spreading them across individual files is the key to managing code
> bases.

You left out the word "badly".


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#66672

On Wed, Feb 19, 2014 at 6:32 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 18 Feb 2014 13:44:47 -0800, Rick Johnson wrote:
>
>> Are you telling me you're willing to search through a single file
>> containing 3,734 lines of code (yes, Tkinter) ...
>
> For a mere 4000 lines of code, yes, I'd rather have it all in the one
> file, presuming that they are all related pieces of code.

If Tkinter were horribly unreadable, I would figure it as being
because of the multiple languages involved. But I just pulled up
tkinter/__init__.py to try to find OptionMenu, and it's 35 lines of
easy-to-read code. And there's a destroy method. Not at all hard to
find.

ChrisA

[toc] | [prev] | [next] | [standalone]

#66687

In article <53045df2$0$2788$c3e8da3$76491128@news.astraweb.com>,
 Steven D'Aprano <steve@pearwood.info> wrote:

> How do you know that the module tk_optionmenu.py contains the class 
> OptionMenu? Perhaps it contains the function optionmenu. Or the class 
> TK_OptionMenu. 

Stuff like this is a really important issue once a codebase gets large 
enough that nobody has it all memorized.  If I'm looking at a piece of 
code:

    foo = Frobnicator()
    foo.flamozilate()

and I want to get a better understanding of what flamozilation involves, 
it saves me a bunch of time if I can look at the class name and guess 
where it lives.  Otherwise, I'm reduced to:

$ cd $BASE_DIR; find . -name '*.py' | xargs grep "class Frobnicator"

In the Songza codebase, we often deal with triples of related names.  A 
class FooBar should live in a file models/foo_bar.py, and the name of 
the related database collection (think: SQL table name) should be 
"foo_bar".  When any of those assumptions are broken (and, sadly, 
sometimes they are), the cost of maintenance goes up.

Sometimes we'll put a small collection of very closely related classes 
in one file.  So, FrobnicatorIndexHelper would probably be in the same 
file as Frobnicator.

I once worked on a huge C++ project that had thousands of classes spread 
out over about 50 modules.  They had adopted the convention that *every* 
class name was something like CI_Frobnicator; the prefix told you where 
the class lived.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web