131

I have a module whose purpose is to define a class called "nib". (and a few related classes too.) How should I call the module itself? "nib"? "nibmodule"? Anything else?

Ram Rachum
  • 84,019
  • 84
  • 236
  • 374

5 Answers5

128

Just nib. Name the class Nib, with a capital N. For more on naming conventions and other style advice, see PEP 8, the Python style guide.

Amir
  • 631
  • 6
  • 17
Stephan202
  • 59,965
  • 13
  • 127
  • 133
  • 3
    Do most Python projects follow this convention? Because I notice the built-in classes are in lowercase, e.g. list, string, etc. – Ram Rachum Apr 02 '09 at 23:54
  • 4
    You observation w.r.t. the build-in types is correct. These are decidedly exceptions, though. Most other classes defined in the standard library *are* capitalized. – Stephan202 Apr 03 '09 at 00:51
  • 7
    I thought this was the correct convention, but there is an inherent problem with it, at least it seems to me. Say I have a class called `Client`, and understandably I'd often make instances of it that I want to call `client`. But according to your convention, the module name would be `client`, and so I'd always have to name my instances something unnatural like `client_instance`. What do you think of this problem? – Ray Jun 01 '16 at 10:59
  • 3
    @Ray But say the convention were to name the module `Client`, then it would clash with the class name `Client`. Since there are only 3 possible naming variants (`client`, `Client` or `CLIENT`) there'll always be a clash between two of instances, classes, modules or constants. I believe there are fewer times you name your module the same as an instance or constant than the class, and therefore is the better naming convention of the other possibilities. It'll also make importing from modules more readable since you generally import classes and constants rather than variables. – Ted Klein Bergman Nov 08 '16 at 18:53
  • 2
    The reason why builtins are lowercase is to imply that they are implemented in C rather than python. – Har Apr 21 '17 at 13:40
  • @Har PEP 8: "The naming convention for functions may be used instead in cases where the interface is documented and used primarily as a callable." – Alan Jan 19 '19 at 21:36
44

I would call it nib.py. And I would also name the class Nib.

In a larger python project I'm working on, we have lots of modules defining basically one important class. Classes are named beginning with a capital letter. The modules are named like the class in lowercase. This leads to imports like the following:

from nib import Nib
from foo import Foo
from spam.eggs import Eggs, FriedEggs

It's a bit like emulating the Java way. One class per file. But with the added flexibility, that you can allways add another class to a single file if it makes sense.

rincewind
  • 2,502
  • 19
  • 26
31

I know my solution is not very popular from the pythonic point of view, but I prefer to use the Java approach of one module->one class, with the module named as the class. I do understand the reason behind the python style, but I am not too fond of having a very large file containing a lot of classes. I find it difficult to browse, despite folding.

Another reason is version control: having a large file means that your commits tend to concentrate on that file. This can potentially lead to a higher quantity of conflicts to be resolved. You also loose the additional log information that your commit modifies specific files (therefore involving specific classes). Instead you see a modification to the module file, with only the commit comment to understand what modification has been done.

Summing up, if you prefer the python philosophy, go for the suggestions of the other posts. If you instead prefer the java-like philosophy, create a Nib.py containing class Nib.

Stefano Borini
  • 138,652
  • 96
  • 297
  • 431
  • 5
    The issues mentioned are caused by limitations in the editor, and in the use of version control tools, not by the language or programming style. One class per file is detrimental to the code structure. Use `spyder` or a similar editor to see a summary of your classes to aid navigation, and two panes with the same file open on both. Also, please read PEP8. Python is for writing Python, and Java for Java, but Python is *not* for writing Java. – 0 _ Apr 07 '15 at 23:26
  • 11
    @IoannisFilippidis: If I had to put all classes for a module in a single file in the code sizes I normally manage, I would not even be able to open the file, collisions with other colleagues would skyrocket, and my boss would spit in my face (figuratively, that's it) for proposing it. A single file approach does not scale, PEP-8 or not. – Stefano Borini Apr 11 '15 at 11:50
  • 5
    @StefanoBorini: PEP8 doesn't call for a single file approach. One class per module and one file per (code unit) are two extremes of a very wide spectrum. If you're seeing unmanageably large file sizes with one file per module, you should perhaps consider revising your approach to breaking up a package into modules. – Chintalagiri Shashank Sep 27 '15 at 20:21
27

nib is fine. If in doubt, refer to the Python style guide.

From PEP 8:

Package and Module Names Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.

Since module names are mapped to file names, and some file systems are case insensitive and truncate long names, it is important that module names be chosen to be fairly short -- this won't be a problem on Unix, but it may be a problem when the code is transported to older Mac or Windows versions, or DOS.

When an extension module written in C or C++ has an accompanying Python module that provides a higher level (e.g. more object oriented) interface, the C/C++ module has a leading underscore (e.g. _socket).

thedz
  • 5,496
  • 3
  • 25
  • 29
12

From PEP-8: Package and Module Names:

Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability.

Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.

When an extension module written in C or C++ has an accompanying Python module that provides a higher level (e.g. more object oriented) interface, the C/C++ module has a leading underscore (e.g. _socket).

Community
  • 1
  • 1
Ehsan
  • 604
  • 7
  • 21