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


pengyu.ut at gmail

Nov 1, 2009, 2:11 PM

Post #1 of 33 (786 views)
Permalink
About one class/function per module
I recently asked how to support one class/function per module under
the title 'How to import only one module in a package when the package
__init__.py has already imports the modules?' I summarize my key
points below. In particular, I have to two questions:
1. What disadvantages there are to enforce one class/function per file?
2. How to better support one class/function per file in python?

------------------------------------------------------------------------------
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.

The advantages of one-function/class-per-file that I am aware of are
the following items (maybe incomplete).
1. It is easy to see what functions and classes there are just by
browsing the source directory, without the need of opening the file by
an editor.
2. Testing code for a function/class can be organized along with the
module for the function/class, which also makes it easier to keep
track of the testing code for any function/class.
3. It is easy to move a function/class from one package to another
by just moving files around.
4. It is easy change variable names, etc., for a function/class by
replacement in a file without worrying accidentally change variable
names in other functions.
I have used the above approach on a C++ project. And I use vim + ctags
to navigate from a reference of a class/funciton to its definition. So
far it works fine.

Some people mentioned an good IDE can do 1 and 4. But I'm not aware of
an IDE that can allow me to change file name freely. I tried Visual
Studio long time ago, I have to delete a file, change the file name
and add the file back in order to change the file.


Now let us consider how well python can support one function/class per
file style. I encounter the following problems. Suppose that the
parent directory of 'test' is in $PYTHONPATH and __init__.py is empty,

test/
|-- __init__.py
|-- A.py
`-- B.py

where A.py has only class A and B.py has only class B.

The end user of the test package has to either

import test.A
a=test.A.A()

or

from test.A import A
a=A()

Both of the two cases are not satisfactory. In the first case, a end
user has to type A twice in test.A.A(), which is a burden to the end
user. In the second case, 'from test.A import A' screws up the
namespace, which might cause potential conflicts with classes of the
same name but from different packages.

I was also suggested to put the following line in __init__.py.

from A import A
from B import B

Then the end user can use the following code.

import test
test.A()

But the disadvantage is that I can not import individule file test.A
and test.B any more. Suppose that A is modified but not done yet, then
I modify B. Since the modification of A is not finished yet, the test
code of B won't run because the test code import test.A.

I'm looking for if there is a solution, so that a end user can use the
following code

import test.A
test.A()

So far, I haven't find one. It seems impossible in python, but I want
to double check if there is one solution.
--
http://mail.python.org/mailman/listinfo/python-list


deets at nospam

Nov 1, 2009, 2:32 PM

Post #2 of 33 (771 views)
Permalink
Re: About one class/function per module [In reply to]
Peng Yu schrieb:
> I recently asked how to support one class/function per module under
> the title 'How to import only one module in a package when the package
> __init__.py has already imports the modules?' I summarize my key
> points below. In particular, I have to two questions:
> 1. What disadvantages there are to enforce one class/function per file?
> 2. How to better support one class/function per file in python?

Are you aware that it's much easier to just let go about your
preconceptions about how things should work, and instead adapt for
*Pythocode* to the way *Python* works? The energy you've invested in
coming up with contrived reasons for why e.g. one file per function is a
good idea is better spent actually programming Python - and ejoying it.

Diez


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


robert.kern at gmail

Nov 1, 2009, 2:46 PM

Post #3 of 33 (770 views)
Permalink
Re: About one class/function per module [In reply to]
Peng Yu wrote:

> So far, I haven't find one. It seems impossible in python, but I want
> to double check if there is one solution.

We have already told you more than twice that the answer is "No." Please don't
triple check.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

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


wuwei23 at gmail

Nov 1, 2009, 5:02 PM

Post #4 of 33 (769 views)
Permalink
Re: About one class/function per module [In reply to]
On Nov 2, 8:11燼m, Peng Yu <pengyu...@gmail.com> wrote:
> 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.

You mean, what disadvantages it has _other_ than the ones you've been
experiencing?

Aren't those enough to warrant actually working with Python's import
mechanism rather than against it?

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


pengyu.ut at gmail

Nov 1, 2009, 5:27 PM

Post #5 of 33 (765 views)
Permalink
Re: About one class/function per module [In reply to]
On Sun, Nov 1, 2009 at 7:02 PM, alex23 <wuwei23 [at] gmail> wrote:
> On Nov 2, 8:11燼m, Peng Yu <pengyu...@gmail.com> wrote:
>> 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.
>
> You mean, what disadvantages it has _other_ than the ones you've been
> experiencing?
>
> Aren't those enough to warrant actually working with Python's import
> mechanism rather than against it?

At least, I can use the following for now with one class/function per
module. Unless this one class/function per module style have other
disadvantages in term software engineering, I still can live with
typing the class name (e.g. 'A') twice.

import test.A
a=test.A.A()

So I am asking disadvantages besides python import mechanism is not
friendly to it.
--
http://mail.python.org/mailman/listinfo/python-list


metal29a at gmail

Nov 1, 2009, 6:00 PM

Post #6 of 33 (764 views)
Permalink
Re: About one class/function per module [In reply to]
On 11月2日, 上午9时27分, Peng Yu <pengyu...@gmail.com> wrote:
> On Sun, Nov 1, 2009 at 7:02 PM, alex23 <wuwe...@gmail.com> wrote:
> > On Nov 2, 8:11 am, Peng Yu <pengyu...@gmail.com> wrote:
> >> 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.
>
> > You mean, what disadvantages it has _other_ than the ones you've been
> > experiencing?
>
> > Aren't those enough to warrant actually working with Python's import
> > mechanism rather than against it?
>
> At least, I can use the following for now with one class/function per
> module. Unless this one class/function per module style have other
> disadvantages in term software engineering, I still can live with
> typing the class name (e.g. 'A') twice.
>
> import test.A
> a=test.A.A()
>
> So I am asking disadvantages besides python import mechanism is not
> friendly to it.

I recommand you double check django project, to learn how to organize
python project
--
http://mail.python.org/mailman/listinfo/python-list


wuwei23 at gmail

Nov 1, 2009, 6:33 PM

Post #7 of 33 (763 views)
Permalink
Re: About one class/function per module [In reply to]
Peng Yu <pengyu...@gmail.com> wrote:
> So I am asking disadvantages besides python import mechanism is not
> friendly to it.

Which part of "name collisions have to be resolved somehow" isn't
explicit enough for you?

You can't keep saying "this works in C++" while refusing to accept
that this is an implementation decision with Python.

At least be honest about what you're asking for, which is confirmation
of your existing bias.
--
http://mail.python.org/mailman/listinfo/python-list


davea at ieee

Nov 1, 2009, 6:52 PM

Post #8 of 33 (759 views)
Permalink
Re: About one class/function per module [In reply to]
Peng Yu wrote:
> <snip>
>
> Some people mentioned an good IDE can do 1 and 4. But I'm not aware of
> an IDE that can allow me to change file name freely. I tried Visual
> Studio long time ago, I have to delete a file, change the file name
> and add the file back in order to change the file.
>
>
I use Komodo IDE version 5, where right-click->Rename works fine on
files within a project.
> Now let us consider how well python can support one function/class per
> file style. I encounter the following problems. Suppose that the
> parent directory of 'test' is in $PYTHONPATH and __init__.py is empty,
>
> test/
> |-- __init__.py
> |-- A.py
> `-- B.py
>
> where A.py has only class A and B.py has only class B.
>
> The end user of the test package has to either
>
> import test.A
> a=test.A.A()
>
> or
>
> from test.A import A
> a=A()
>
> <snip>
I'm neither agreeing nor disagreeing with the self-imposed restriction
of one class per module. But I'd like to jump in with an idea on
dealing with the namespaces involved.

How about a two-line import, where the second line is a simple assignment?


import test.A
test.A = test.A.A

Now, you can use the class A just as you wanted --
obj = test.A()

This has the disadvantage that the module itself is no longer
addressable from here. But since the only symbol you apparently want
from the module is the one class, it should be fine. And you could
presumably have saved it in a module-specific global anyway.

Note that I did not test whether other modules that also import test.A
are affected. So some further study would be necessary. Also, I tried
it only in CPython 2.6.2


DaveA

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


rustompmody at gmail

Nov 1, 2009, 7:12 PM

Post #9 of 33 (761 views)
Permalink
Re: About one class/function per module [In reply to]
On Nov 2, 3:11燼m, Peng Yu <pengyu...@gmail.com> wrote:
> I recently asked how to support one class/function per module under
> the title 'How to import only one module in a package when the package
> __init__.py has already imports the modules?' I summarize my key
> points below. In particular, I have to two questions:
> 1. What disadvantages there are to enforce one class/function per file?
> 2. How to better support one class/function per file in python?

Others have told you to discard your biases.
I would tell you to suspend them for a while (including our biases
against your biases)
and try to use emacs+ecb

>
> ------------------------------------------------------------------------------
> 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.
>
> The advantages of one-function/class-per-file that I am aware of are
> the following items (maybe incomplete).
> 1. It is easy to see what functions and classes there are just by
> browsing the source directory, without the need of opening the file by
> an editor.

Primary intention of ecb

> 2. Testing code for a function/class can be organized along with the
> module for the function/class, which also makes it easier to keep
> track of the testing code for any function/class.
> 3. It is easy to move a function/class from one package to another
> by just moving files around.
If an editing task is found hard it just means youve never used emacs!

> 4. It is easy change variable names, etc., for a function/class by
> replacement in a file without worrying accidentally change variable
> names in other functions.
> I have used the above approach on a C++ project. And I use vim + ctags
> to navigate from a reference of a class/funciton to its definition. So
> far it works fine.
Should be possible to code this up in about 10 lines of emacs
Simple workaround is to select the function/class and run search-
replace on the selection
--
http://mail.python.org/mailman/listinfo/python-list


steven at REMOVE

Nov 1, 2009, 8:01 PM

Post #10 of 33 (767 views)
Permalink
Re: About one class/function per module [In reply to]
On Sun, 01 Nov 2009 18:33:57 -0800, alex23 wrote:

> Peng Yu <pengyu...@gmail.com> wrote:
>> So I am asking disadvantages besides python import mechanism is not
>> friendly to it.
>
> Which part of "name collisions have to be resolved somehow" isn't
> explicit enough for you?
>
> You can't keep saying "this works in C++" while refusing to accept that
> this is an implementation decision with Python.

Oh, it doesn't work to Peng Yu's satisfaction in C++ either. In an
earlier email, he wrote:


"I'm not complaining. I just wish there is a walkaround. In C++, I
still have to write some script to make sure the directory hierarchy
is consistent with the namespace, because C++ doesn't impose the
constraint that the directory hierarchy is the same as the namespace.
But it seems that is no such walkaround in python for my case, because
python binds namespace to directory hierarchy."

You got that? In Python, which forces the namespace and directory
hierarchy to be the same, he wants them to be independent; in C++, which
relaxes that restriction, he writes scripts to force them to be the same.


[.Aside: the word is "work-around" not "walk-around". Easy mistake to
make.]



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


gagsl-py2 at yahoo

Nov 1, 2009, 10:12 PM

Post #11 of 33 (761 views)
Permalink
Re: About one class/function per module [In reply to]
En Sun, 01 Nov 2009 22:27:32 -0300, Peng Yu <pengyu.ut [at] gmail> escribi:
> On Sun, Nov 1, 2009 at 7:02 PM, alex23 <wuwei23 [at] gmail> wrote:
>> On Nov 2, 8:11 am, Peng Yu <pengyu...@gmail.com> wrote:

>>> 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.
>>
>> You mean, what disadvantages it has _other_ than the ones you've been
>> experiencing?
>>
>> Aren't those enough to warrant actually working with Python's import
>> mechanism rather than against it?
>
> At least, I can use the following for now with one class/function per
> module. Unless this one class/function per module style have other
> disadvantages in term software engineering, I still can live with
> typing the class name (e.g. 'A') twice.
>
> import test.A
> a=test.A.A()
>
> So I am asking disadvantages besides python import mechanism is not
> friendly to it.

You don't type the class name twice. One 'A' is a module name, the other
'A' is the class name.
In C++, a source file is just a compilation unit, only relevant for
certain rules regarding visibility; it doesn't matter really in which
source file the code is written in.
In Python, a source file becomes a module. A module is an object: it is
created (usually by importing it), it has attributes, there are module
hierarchies (packages), contains other objects... A module is an important
object in Python. You should not confuse the module with the class (or
classes) that are defined inside it. In your example above, test.A is a
module, test.A.A is a class; they're not the same thing. You may put one
class per file, nobody forbids that - but remember that the class and the
module are different objects.
If you follow PEP8 conventions, module names are all in lowercase, and
class names use TitleCase. This helps avoid confusion.

--
Gabriel Genellina

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


bruno.42.desthuilliers at websiteburo

Nov 2, 2009, 12:55 AM

Post #12 of 33 (755 views)
Permalink
Re: About one class/function per module [In reply to]
Gabriel Genellina a 閏rit :
>>> On Nov 2, 8:11 am, Peng Yu <pengyu...@gmail.com> wrote:
>
>>>> 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.
>>>
(snip)
> You may put one class per file, nobody forbids that

But anyone having to work on your code will hate you.
--
http://mail.python.org/mailman/listinfo/python-list


bruno.42.desthuilliers at websiteburo

Nov 2, 2009, 1:03 AM

Post #13 of 33 (755 views)
Permalink
Re: About one class/function per module [In reply to]
Peng Yu a 閏rit :
(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.
--
http://mail.python.org/mailman/listinfo/python-list


ben+python at benfinney

Nov 2, 2009, 2:03 AM

Post #14 of 33 (754 views)
Permalink
Re: About one class/function per module [In reply to]
Bruno Desthuilliers <bruno.42.desthuilliers [at] websiteburo> writes:

> Gabriel Genellina a 茅crit :
> > You may put one class per file, nobody forbids that
>
> But anyone having to work on your code will hate you.

And if you can find anyone to collaborate with who can stand your
insistence on putting one *function* per file, you should probably marry
them as being your soul mate.

--
\ 鈥淲e tend to scoff at the beliefs of the ancients. But we can't |
`\ scoff at them personally, to their faces, and this is what |
_o__) annoys me.鈥 鈥擩ack Handey |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list


pengyu.ut at gmail

Nov 2, 2009, 5:11 AM

Post #15 of 33 (751 views)
Permalink
Re: About one class/function per module [In reply to]
On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
<bruno.42.desthuilliers [at] websiteburo> wrote:
> Peng Yu a 閏rit :
> (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.
For my C++ project, so far so good.

I can easily change filenames (that is class name or function name), I
can easily find them, I can easily move things around, all with just
the corresponding script command. I can navigate to the definition of
class and function by vim + ctags, I can see example code that calls
the class/function. Whenever I suspect there is a bug, I can easily go
to the right level of class/function in the directory hierarchy to
write a test case to trace down the bug without having to use gdb.

Would you please let me why it is a nightmare?
--
http://mail.python.org/mailman/listinfo/python-list


pengyu.ut at gmail

Nov 2, 2009, 5:24 AM

Post #16 of 33 (750 views)
Permalink
Re: About one class/function per module [In reply to]
On Mon, Nov 2, 2009 at 7:11 AM, Peng Yu <pengyu.ut [at] gmail> wrote:
> On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
> <bruno.42.desthuilliers [at] websiteburo> wrote:
>> Peng Yu a 閏rit :
>> (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.
> For my C++ project, so far so good.
>
> I can easily change filenames (that is class name or function name), I
> can easily find them, I can easily move things around, all with just
> the corresponding script command. I can navigate to the definition of
> class and function by vim + ctags, I can see example code that calls
> the class/function. Whenever I suspect there is a bug, I can easily go
> to the right level of class/function in the directory hierarchy to
> write a test case to trace down the bug without having to use gdb.
>
> Would you please let me why it is a nightmare?

Another advantage one of class/function per file is that the syntax
clearly tell the dependence relation between classes and functions.

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. 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.

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.
--
http://mail.python.org/mailman/listinfo/python-list


deets at nospam

Nov 2, 2009, 5:27 AM

Post #17 of 33 (750 views)
Permalink
Re: About one class/function per module [In reply to]
Peng Yu wrote:

> On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
> <bruno.42.desthuilliers [at] websiteburo> 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.
> For my C++ project, so far so good.
>
> I can easily change filenames (that is class name or function name), I
> can easily find them, I can easily move things around, all with just
> the corresponding script command. I can navigate to the definition of
> class and function by vim + ctags, I can see example code that calls
> the class/function. Whenever I suspect there is a bug, I can easily go
> to the right level of class/function in the directory hierarchy to
> write a test case to trace down the bug without having to use gdb.
>
> Would you please let me why it is a nightmare?

My current project has about 1300 source-files (luckily *not* laid out in
your preferred way), which contain 1900 function-definitions (most probably
even more so) and about 1700 classes. So your "approach" more than doubles
the number of files to juggle around - in my head, in my editor, and so on.

Not to speak about the inability to rename a function or class just in
source-code. No, I'd also have to rename the file, causing all kinds of
extra issues when using version-control-systems (which of course I do).

It's simply a braindead idea. Get over it. Get rid of your "useful" scripts.
Start learning a decent editor (emacs is mine) which allows you to deal
with all of your perceived "problems" without making even small projects a
nightmare of a bazillion files.

Again: *program* in python, don't fantasize about something that's not
there, and writing shoehorning-scripts. That's just an excuse to be
ineffective.

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


jeanmichel at sequans

Nov 2, 2009, 7:02 AM

Post #18 of 33 (753 views)
Permalink
Re: About one class/function per module [In reply to]
Diez B. Roggisch wrote:
> Peng Yu wrote:
>
>> I can navigate to the definition of
>> class and function by vim + ctags,
>>
>
> Start learning a decent editor (emacs is mine) which allows you to deal
> with all of your perceived "problems"
>
> Diez
>

This is a declaration of war against the vi community. We won't give up,
prepare for vengeance !
By the way, why the hell would someone wants to limit itself to one
function per file, file names would be probably related to the function
name, that would make changing function name a nightmare, not mentiong
the history issues when using version control systems. Definitely a bad
idea.

JM


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


ben+python at benfinney

Nov 2, 2009, 2:21 PM

Post #19 of 33 (709 views)
Permalink
Re: About one class/function per module [In reply to]
Jean-Michel Pichavant <jeanmichel [at] sequans> writes:

> Diez B. Roggisch wrote:
> > Start learning a decent editor (emacs is mine) which allows you to
> > deal with all of your perceived "problems"
>
> This is a declaration of war against the vi community. We won't give
> up, prepare for vengeance !

Bah. Saying that Emacs is a decent text editor doesn't preclude other
decent text editors. You and your pugilistic editor wars...

Of course, vi is *not* a decent text editor (which, to my reckoning,
requires all of: free software, mature, widely used, powerful,
extensible and 鈥 because of all the preceding points 鈥 extensive support
for a huge range of editing tasks).

The only text editors that make the bar are Emacs and Vim. Anyone who
disagrees had better be prepared for vengeance.

--
\ 鈥淏e careless in your dress if you must, but keep a tidy soul.鈥 |
`\ 鈥擬ark Twain, _Following the Equator_ |
_o__) |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list


rhodri at wildebst

Nov 2, 2009, 4:04 PM

Post #20 of 33 (741 views)
Permalink
Re: About one class/function per module [In reply to]
On Mon, 02 Nov 2009 13:24:59 -0000, Peng Yu <pengyu.ut [at] gmail> wrote:

> Another advantage one of class/function per file is that the syntax
> clearly tell the dependence relation between classes and functions.

Um, no. Grepping for "import" now tells you that there is a dependency
between the file contents, but it leaves you with no clue as to what
that relationship is. You've thrown away the strong relationship
information that comes from collecting your source into a single file.

> 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. 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.

You could always try searching for the class name, which will tell you
a whole lot more about how it's being used.

> 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.

Provided, of course, that the test case is still meaningful given the
changes being made to B, and that you don't forget what you were doing
with B while your attention is on A. Not my favorite way of working,
though sometimes you just can't avoid it.

Of course, given that A and B are in different files, your chances
of realising that you needed to change A at all dropped dramatically.

--
Rhodri James *-* Wildebeest Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list


pengyu.ut at gmail

Nov 2, 2009, 5:06 PM

Post #21 of 33 (730 views)
Permalink
Re: About one class/function per module [In reply to]
On Mon, Nov 2, 2009 at 9:02 AM, Jean-Michel Pichavant
<jeanmichel [at] sequans> wrote:
> Diez B. Roggisch wrote:
>>
>> Peng Yu wrote:
>>
>>>
>>> 營 can navigate to the definition of
>>> class and function by vim + ctags,
>>>
>>
>> Start learning a decent editor (emacs is mine) which allows you to deal
>> with all of your perceived "problems"
>> Diez
>>
>
> This is a declaration of war against the vi community. We won't give up,
> prepare for vengeance !
> By the way, why the hell would someone wants to limit itself to one function
> per file, file names would be probably related to the function name, that
> would make changing function name a nightmare, not mentiong the history
> issues when using version control systems. Definitely a bad idea.

I use vi rather than emacs. I stick to vi because I stated with vi and
I don't what to use both editors but only at an amateur level.

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?
--
http://mail.python.org/mailman/listinfo/python-list


pengyu.ut at gmail

Nov 2, 2009, 7:22 PM

Post #22 of 33 (726 views)
Permalink
Re: About one class/function per module [In reply to]
On Mon, Nov 2, 2009 at 7:41 PM, Lee <leeyuan123 [at] gmail> wrote:
> On Nov 2, 7:06爌m, Peng Yu <pengyu...@gmail.com> wrote:
>> On Mon, Nov 2, 2009 at 9:02 AM, Jean-Michel Pichavant
>>
>>
>>
>>
>>
>> <jeanmic...@sequans.com> wrote:
>> > Diez B. Roggisch wrote:
>>
>> >> Peng Yu wrote:
>>
>> >>> 營 can navigate to the definition of
>> >>> class and function by vim + ctags,
>>
>> >> Start learning a decent editor (emacs is mine) which allows you to deal
>> >> with all of your perceived "problems"
>> >> Diez
>>
>> > This is a declaration of war against the vi community. We won't give up,
>> > prepare for vengeance !
>> > By the way, why the hell would someone wants to limit itself to one function
>> > per file, file names would be probably related to the function name, that
>> > would make changing function name a nightmare, not mentiong the history
>> > issues when using version control systems. Definitely a bad idea.
>>
>> I use vi rather than emacs. I stick to vi because I stated with vi and
>> I don't what to use both editors but only at an amateur level.
>>
>> 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?
>
> Because then the version control system would have to implicitly
> identify the original names for files that have changed names...
> Think about it, if you change the name of one file, the system should
> theoretically be able to accurately identify the original filename and
> make the corresponding changes to its database. But if you were to
> simultaneously change the names of many files, then there's no
> possible way for the system to determine which names belongs where...
> I think you can see where I'm going with this.

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.
--
http://mail.python.org/mailman/listinfo/python-list


wuwei23 at gmail

Nov 2, 2009, 7:39 PM

Post #23 of 33 (730 views)
Permalink
Re: About one class/function per module [In reply to]
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.
--
http://mail.python.org/mailman/listinfo/python-list


pengyu.ut at gmail

Nov 2, 2009, 7:50 PM

Post #24 of 33 (730 views)
Permalink
Re: About one class/function per module [In reply to]
On Mon, Nov 2, 2009 at 9:39 PM, alex23 <wuwei23 [at] gmail> 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?).
--
http://mail.python.org/mailman/listinfo/python-list


gagsl-py2 at yahoo

Nov 2, 2009, 8:20 PM

Post #25 of 33 (721 views)
Permalink
Re: About one class/function per module [In reply to]
En Tue, 03 Nov 2009 00:50:56 -0300, Peng Yu <pengyu.ut [at] gmail> escribi:
> On Mon, Nov 2, 2009 at 9:39 PM, alex23 <wuwei23 [at] gmail> wrote:
>> Peng Yu <pengyu...@gmail.com> wrote:

>>> 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?).

All version control systems that I know of support, at least, renaming
files in the same directory. (Old CVS did not, but CVSNT does). svn, hg,
darcs and bzr all have renaming support, although bzr seems to be the most
robust, specially in non trivial cases.

--
Gabriel Genellina

--
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 Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.