About one class/function per module
Peng Yu
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.
Diez B. Roggisch
> 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
Robert Kern
> 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
alex23
> 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?
Peng Yu
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.
metal
I recommand you double check django project, to learn how to organize
python project
alex23
> 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.
Dave Angel
> <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.
>
>
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()
>
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
rustom
> 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
Steven D'Aprano
> 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
Gabriel Genellina
> 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
Bruno Desthuilliers
>>> 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 may put one class per file, nobody forbids that
But anyone having to work on your code will hate you.
Bruno Desthuilliers
(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.
Ben Finney
> 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.
--
\ “We 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.” —Jack Handey |
Ben Finney
Peng Yu
<bruno.42.de...@websiteburo.invalid> wrote:
> Peng Yu a écrit :
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?
Peng Yu
> On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
> <bruno.42.de...@websiteburo.invalid> wrote:
>> Peng Yu a écrit :
> 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.
Diez B. Roggisch
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
Jean-Michel Pichavant
> Peng Yu wrote:
>
>> I can navigate to the definition of
>> class and function by vim + ctags,
>>
>
> with all of your perceived "problems"
>
>
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
Ben Finney
> 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.
--
\ “Be careless in your dress if you must, but keep a tidy soul.” |
`\ —Mark Twain, _Following the Equator_ |
_o__) |
Ben Finney
Rhodri James
> 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
Peng Yu
<jeanm...@sequans.com> wrote:
> Diez B. Roggisch wrote:
>>
>> Peng Yu wrote:
>>
>>>
>>> class and function by vim + ctags,
>>>
>>
>> with all of your perceived "problems"
>>
>
> This is a declaration of war against the vi community. We won't give up,
> prepare for vengeance !
> 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?
Peng Yu
> 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.
alex23
> 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.
Peng Yu
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?).
Gabriel Genellina
> On Mon, Nov 2, 2009 at 9:39 PM, alex23 <wuw...@gmail.com> 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
Steven D'Aprano
> 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
Diez B. Roggisch
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
Ben Finney
> 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
Bruno Desthuilliers
> "Diez B. Roggisch" <de...@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
>
Bruno Desthuilliers
> On Mon, Nov 2, 2009 at 3:03 AM, Bruno Desthuilliers
> <bruno.42.de...@websiteburo.invalid> wrote:
>> (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)
Jean-Michel Pichavant
> 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
Diez B. Roggisch
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
Hans-Peter Jansen
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