Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Python

About one class/function per module

 

 

First page Previous page 1 2 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded


steve at REMOVE-THIS-cybersource

Nov 2, 2009, 9:17 PM

Post #26 of 33 (82 views)
Permalink
Re: About one class/function per module [In reply to]

On Mon, 02 Nov 2009 07:24:59 -0600, Peng Yu wrote:

> Suppose I have class A and class B in a file, I can not easily figure
> out which class depends on which class by a simple script.

How about looking at the classes?

>>> class A:
... pass
...
>>> class B(A):
... pass
...
>>>
>>> B.__bases__
(<class __main__.A at 0xb7caccbc>,)

Classes know their own dependencies. Just ask them:

import module
for superclass in module.A.__bases__:
print superclass, "is a dependency for class A"



> However, if
> they are in two separate files, for example B depends on A, then I will
> have 'import A' in file B. This dependency can be easily figured out by
> a script.


If they are in the same file, you can just look at the class definition:

class B(A):

And now you know with 100% accuracy that B depends on A, instead of
guessing that just because you import a module, that means you must have
used a class from that module.


> The following scenario also demonstrate why the maintenance cost is
> lower with one class/function per file, because it decouples
> dependences. Let's suppose class A and B are in the same file. Now I'm
> changing class B. But while I'm changing class B, I just realize that I
> have to change A. But since the change in B is half way done
> (syntactical not correct), I will not be able to run the test case for
> A, because the test case import the file that has class B. In contrast,
> if A and B are in different files, even if B is half way done, I can
> still run test case for A.

Assuming A and B are independent, or that B depends on A but not the
opposite, failing tests for B won't cause tests for A to fail. This
doesn't change whether A and B are in the same file or not.

The one exception to this is syntax errors. But if your project contains
syntax errors, why are you trying to run test suites?



--
Steven
--
http://mail.python.org/mailman/listinfo/python-list


deets at nospam

Nov 3, 2009, 3:52 AM

Post #27 of 33 (71 views)
Permalink
Re: About one class/function per module [In reply to]

Peng Yu wrote:

> On Mon, Nov 2, 2009 at 9:39 PM, alex23 <wuwei23[at]gmail.com> wrote:
>> Peng Yu <pengyu...@gmail.com> wrote:
>>> I don't think that this is a problem that can not be overcome. A
>>> simple solution might be to associate a unique identifier to each
>>> file, so that even the filename has been changed, the new version and
>>> the old version can still be identified as actually the same file.
>>
>> Or, again, you could work _with_ the tools you're using in the way
>> they're meant to be used, rather than re-inventing the whole process
>> of version control yourself.
>
> I'm not trying to reinvent a new version control. But due to this
> drawback, I avoid use a version control system. Rather, I compressed
> my source code in a tar file whenever necessary. But if a version
> control system has this capability, I'd love to use it. And I don't
> think that no version control system support this is because of any
> technical difficult but rather because of practical issue (maybe it
> takes a lot efforts to add this feature to an existing version control
> system?).

There are those people who realize if *everything* they encounter needs
adjustment to fit their needs, their needs need adjustment.

Others fight an uphill battle & bicker about things not being as they want
them.

Don't get me wrong - innovation often comes from scratching ones personal
itch. But you seem to be suffering from a rather bad case of
neurodermatitis.

Diez


--
http://mail.python.org/mailman/listinfo/python-list


ben+python at benfinney

Nov 3, 2009, 4:02 AM

Post #28 of 33 (71 views)
Permalink
Re: About one class/function per module [In reply to]

"Diez B. Roggisch" <deets[at]nospam.web.de> writes:

> Don't get me wrong - innovation often comes from scratching ones
> personal itch. But you seem to be suffering from a rather bad case of
> neurodermatitis.

+1 QOTW

--
\ “For my birthday I got a humidifier and a de-humidifier. I put |
`\ them in the same room and let them fight it out.” —Steven Wright |
_o__) |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list


bruno.42.desthuilliers at websiteburo

Nov 4, 2009, 7:53 AM

Post #29 of 33 (59 views)
Permalink
Re: About one class/function per module [In reply to]

Ben Finney a écrit :
> "Diez B. Roggisch" <deets[at]nospam.web.de> writes:
>
>> Don't get me wrong - innovation often comes from scratching ones
>> personal itch. But you seem to be suffering from a rather bad case of
>> neurodermatitis.
>
> +1 QOTW
>
Make it +2 QOTW !-)
--
http://mail.python.org/mailman/listinfo/python-list


bruno.42.desthuilliers at websiteburo

Nov 4, 2009, 8:07 AM

Post #30 of 33 (59 views)
Permalink
Re: About one class/function per module [In reply to]

Peng Yu a crit :
> On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
> <bruno.42.desthuilliers[at]websiteburo.invalid> wrote:
>> Peng Yu a crit :
>> (snip)
>>> I prefer organized my code one class/function per file (i.e per module
>>> in python). I know the majority of programmers don't use this
>>> approach. Therefore, I'm wondering what its disadvantage is.
>> Hmmm... As far as I'm concerned, you already answered your own question:
>> "the majority of programmers don't use this approach".
>>
>> Now, for a much more practical answer:
>> 1/ having to handle thousands of files for even a simple project is a
>> king-size PITA for the maintainer.
>> 2/ having to load thousands of modules will add quite a lot of overhead when
>> actually running the code.
>> 3/ as a result, the poor guy that will end up maintaining your code will
>> positively hate you. Beware : this poor guy might as well be you.
>
> I still don't understand why it is a nightmare to maintain the code.

Been here, done that.

You obviously don't have enough experience with Python to understand why
your "organization" suck. And given your apparent tendency to insist on
imposing your own views / preconceptions on the language instead of
learning how to use it properly (the canonical "I can write Java in any
language" syndrom), it will probably take a long time before you get
there - if you ever get there at all.

My friendly (really) advice is to stop fighting the langage and start
going with the flow.

(snip lots of stuff that require neither "one line of code per file" nor
fancy scripts)

--
http://mail.python.org/mailman/listinfo/python-list


jeanmichel at sequans

Nov 4, 2009, 10:15 AM

Post #31 of 33 (57 views)
Permalink
Re: About one class/function per module [In reply to]

Peng Yu wrote:
> With some automated script, I don't think it is a nightmare to change
> function names. I can change function names and filenames and their
> reference with a simple command.
>
> I'd think that this is the limitation of current version control
> system. I don't aware of any version control system that allows easy
> change of filenames. But why such features can not be implemented in
> the version control system?
>

So one function per files bring so many problems that you need an
automated script to change one function name and complain about version
control systems messing up with your file history.
Still you insist on stating that this is the solution and that version
control system have to adapt.
It has already been told to you, and you should really consider the
following advice:
When everything is wrong except you, it may happen that *your* are
somehow wrong.

Among all the responses you got, I don't remember any one that would
suggest you are in the right way. So what is your conclusion now ?

JM

--
http://mail.python.org/mailman/listinfo/python-list


deets at nospam

Nov 5, 2009, 3:08 AM

Post #32 of 33 (48 views)
Permalink
Re: About one class/function per module [In reply to]

Jean-Michel Pichavant wrote:

> Peng Yu wrote:
>> With some automated script, I don't think it is a nightmare to change
>> function names. I can change function names and filenames and their
>> reference with a simple command.
>>
>> I'd think that this is the limitation of current version control
>> system. I don't aware of any version control system that allows easy
>> change of filenames. But why such features can not be implemented in
>> the version control system?
>>
>
> So one function per files bring so many problems that you need an
> automated script to change one function name and complain about version
> control systems messing up with your file history.
> Still you insist on stating that this is the solution and that version
> control system have to adapt.
> It has already been told to you, and you should really consider the
> following advice:
> When everything is wrong except you, it may happen that *your* are
> somehow wrong.
>
> Among all the responses you got, I don't remember any one that would
> suggest you are in the right way. So what is your conclusion now ?

Simple: not only are the languages he uses not proper, nor the revision
control systems, and neither the editors/IDEs out there - the whole
communities are of course also dysfunctional, not supporting his cause :)

Diez
--
http://mail.python.org/mailman/listinfo/python-list


hpj at urpla

Nov 12, 2009, 5:10 AM

Post #33 of 33 (11 views)
Permalink
Re: About one class/function per module [In reply to]

On Tuesday 03 November 2009, 12:52:20 Diez B. Roggisch wrote:
> Peng Yu wrote:
> > On Mon, Nov 2, 2009 at 9:39 PM, alex23 <wuwei23[at]gmail.com> wrote:
> >> Peng Yu <pengyu...@gmail.com> wrote:
> >>> I don't think that this is a problem that can not be overcome. A
> >>> simple solution might be to associate a unique identifier to each
> >>> file, so that even the filename has been changed, the new version and
> >>> the old version can still be identified as actually the same file.
> >>
> >> Or, again, you could work _with_ the tools you're using in the way
> >> they're meant to be used, rather than re-inventing the whole process
> >> of version control yourself.
> >
> > I'm not trying to reinvent a new version control. But due to this
> > drawback, I avoid use a version control system. Rather, I compressed
> > my source code in a tar file whenever necessary. But if a version
> > control system has this capability, I'd love to use it. And I don't
> > think that no version control system support this is because of any
> > technical difficult but rather because of practical issue (maybe it
> > takes a lot efforts to add this feature to an existing version control
> > system?).
>
> There are those people who realize if *everything* they encounter needs
> adjustment to fit their needs, their needs need adjustment.
>
> Others fight an uphill battle & bicker about things not being as they
> want them.
>
> Don't get me wrong - innovation often comes from scratching ones personal
> itch. But you seem to be suffering from a rather bad case of
> neurodermatitis.

Diez, sorry for chiming in that lately, but while the whole thread is
spilled over for no good reason, your QOTW remembered me on a quote of
R.A.W., that sounds like a perfect fit:

Whatever the Thinker thinks, the Prover will prove.

And if the Thinker thinks passionately enough, the Prover will prove the
thought so conclusively that you will never talk a person out of such a
belief, even if it is something as remarkable as the notion that there is a
gaseous vertebrate of astronomical heft ("GOD") who will spend all eternity
torturing people who do not believe in his religion.

>From "Prometheus Rising" by Robert Anton Wilson

Pete

http://en.wikiquote.org/wiki/Robert_Anton_Wilson
--
http://mail.python.org/mailman/listinfo/python-list

First page Previous page 1 2 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.