What to name a python file and it's module?

Coding
1

Hi guys,

I wanted to know, what would be best to name a python script file and it’s module?

I read somewhere that it gets buggy if name a module after it’s .py file, is it right? then what should we name a module?

For example my folder structure is like this:

pyScripts package
jointUtility package
[INDENT][INDENT]orientJoint.py[/INDENT][/INDENT]
[INDENT][INDENT][INDENT]( name of the module = ?)[/INDENT][/INDENT][/INDENT]
[INDENT][INDENT]insetJoint.py[/INDENT][/INDENT]
[INDENT][INDENT][INDENT]( name of the module = ?)[/INDENT][/INDENT][/INDENT]
curveUtility package
[INDENT][INDENT]rebuildCurve.py[/INDENT][/INDENT]
[INDENT][INDENT][INDENT]( name of the module = ?)[/INDENT][/INDENT][/INDENT]
[INDENT][INDENT]closeCurve.py[/INDENT][/INDENT]
[INDENT][INDENT][INDENT]( name of the module = ?)[/INDENT][/INDENT][/INDENT]

Thanks a lot

2

I’ve typically seen people name a file with lowercase start letter and with module/class with uppercase first letter.
ie
orientJoint.py (file)

  • OrientJoint (class)

perhaps people with more experience will have a better solution?

3

Thanks for the answer Lee,

May naming your module same as .py file cause errors like this?

Error: AttributeError: ‘module’ object has no attribute ‘…’#

Where … is a package name.

4

I try to stick with:

just cause it’s something other people will have seen and tend to interpret correctly. Part of the pep-8-y way is to use more nesting and less maya-style camelCapping, so maybe:
pyScripts (folder)
init.py
joints(folder)
[INDENT]init.py[/INDENT]
[INDENT][INDENT]def orient()…[/INDENT][/INDENT]
[INDENT][INDENT]def insert()…[/INDENT][/INDENT]
[INDENT]jointFinder.py[/INDENT]
[INDENT][INDENT]class JointFinder()…[/INDENT][/INDENT]
[INDENT][INDENT]def find_yzx_joints()…[/INDENT][/INDENT]
curves(folder)
[INDENT]init.py[/INDENT]
[INDENT][INDENT]def rebuild()…[/INDENT][/INDENT]
[INDENT][INDENT]def rebuild()…[/INDENT][/INDENT]

Pep-8 does get kind of irksome for modules that are really exposing just a single class:

new_joint = pyScripts.joints.jointFinder.JointFinder()

is just atrocious, but hard to avoid. It’s often cleaner to put these kind of objects into a package’s root namespace (ie, inside of init.py) so they are nested less deeply and need less redundant typing.

[QUOTE=roham;17236]Hi guys,

I wanted to know, what would be best to name a python script file and it’s module?

I read somewhere that it gets buggy if name a module after it’s .py file, is it right? then what should we name a module?

For example my folder structure is like this:

pyScripts package
jointUtility package
[INDENT][INDENT]orientJoint.py[/INDENT][/INDENT]
[INDENT][INDENT][INDENT]( name of the module = ?)[/INDENT][/INDENT][/INDENT]
[INDENT][INDENT]insetJoint.py[/INDENT][/INDENT]
[INDENT][INDENT][INDENT]( name of the module = ?)[/INDENT][/INDENT][/INDENT]
curveUtility package
[INDENT][INDENT]rebuildCurve.py[/INDENT][/INDENT]
[INDENT][INDENT][INDENT]( name of the module = ?)[/INDENT][/INDENT][/INDENT]
[INDENT][INDENT]closeCurve.py[/INDENT][/INDENT]
[INDENT][INDENT][INDENT]( name of the module = ?)[/INDENT][/INDENT][/INDENT]

Thanks a lot[/QUOTE]

5

[QUOTE=Theodox;17240]I try to stick with:

pyScripts (folder)
init.py
joints(folder)
[INDENT]init.py[/INDENT]
[INDENT][INDENT]def orient()…[/INDENT][/INDENT]
[INDENT][INDENT]def insert()…[/INDENT][/INDENT]

[/QUOTE]

Thanks a lot,

Does it mean, I have to put my def orient() in init.py ? What if I want every def to be in a different .py file so that it’s easier to access and edit?

6

[QUOTE=roham;17244]Thanks a lot,

Does it mean, I have to put my def orient() in init.py ? What if I want every def to be in a different .py file so that it’s easier to access and edit?[/QUOTE]

Yes, in my example i was assuming that simple-sounding defs like ‘orient’ would be right in init.py. I often write ‘packages’ that are really just modules with their guts in an init.py, assuming that I’ll need more room in the namespace later.

The standard thing to do would be to group functions into related chunks as individual modules in the package. You can simplify outside access by importing them into the package’s __init__py, which will mean that they get defined for anybody importing the package (although if you do that you have to make sure you’re not doing any expensive initializations in the sub-modules).

An important part of the job of namespaces is to help you (or your teammates!) navigate the complexity of a toolset, which eventually will get very big and complex. Think of it like a file system – you want to keep the number of names in any particular folder fairly low, probably less than 10. You want to provide access at an appropriate level for potential users – a function that is used to format arguments from one particular dialog box is of no interest to anybody but the rest of the dialog box’s code ( or maybe not even there – maybe only the UI portion of the dialog) so it should not live in a big, populous names spaces where it’s competing for attention with commonly used functions)

In that context, one def per file is extremely granular, probably too much so. You’ll find there are lots of not-to-important defs you’ll want to share and keeping them all in individual files will make it harder for you to keep remember them or make synchronized edits. Also, chunkier organization lets you share constants (so, for example, your curves module could define constants like CURVE_DEGREE = 3 or USE_BEZIER=False and all your curve functions would share those constants without recourse to global variables).

as the PEP-8 sayeth, ‘nested namespaces are a great honking big idea - lets do more of those!’ :slight_smile:

7

[QUOTE=Theodox;17247]Yes, in my example i was assuming that simple-sounding defs like ‘orient’ would be right in init.py. I often write ‘packages’ that are really just modules with their guts in an init.py, assuming that I’ll need more room in the namespace later.
[/QUOTE]

Thanks for the comprehensive answer.

What if our defs are not that simple and there are a lot of them. Say there are 50 different defs, some of them small, some bigger. Also, some defs are using smaller ones in them?

For example:

I have findDeformer.py which has a findDeformer def in it and another file called duplicateDeformer.py with a dupDeform def in it. I need to import and use findDeformer in duplicateDeformer but they both are in the same package called rigging. I don’t want to put all scripts like this in init.py cause there are a lot of them and I want to keep them organized.

What would be best to do then?

Thanks a lot for your time.

8

And regarding the naming of your files, I wrote this up just for you: always lowercase py files, always | RobG3d

9

Thank you all

10

The short answer to your last q is that you could make your defs as single files, store them in packages, and promote them into their package namespace. If your rigging package’s init.py looked like this, and your defs were in their single files in the same folder:


from .findDeformer import findDef #note leading period
from .duplicateDeformer import dupDeform

other code does not need to know why it’s set up that ways, it just calls


import rigging
rigging.findDef (.....)

This works (i use this sort of tricks for plugin-like setups where it’s nice to keep code in files organized around the different plugin, even though the outside code doesn’t want to know which plugins are present).

However, it’s not a great way to work on any significant scale. If you accidentally omit an import in init.py, your defs will vanish without a trace.

Moreover you’ll be asking python to import and compile hundreds or possible thousands of individual scripts (I just grepped for ‘def’ in my source tree and got 6,305 hits). Since the compilation is disk-IO bound you’ll probably see noticeable slowdowns (and you’ll have to compile every one of those defs just to get at one of them in a big namespace like ‘rigging’.

And, of course, you’ll have trouble nesting things effectively, since moving defs around will require un-importing them in one place and re-importing them in another. You’ll need to invent a bunch of private naming conventions to avoid re-using obvious words in your def names, leading to funky code that’s hard to read. And, worst of all when you debug you’ll need to make multiple stops to get to the real source of your code.

As an aside, if you’re worried about finding things and staying organized, use a real IDE (Eclipse or Wing) which will show you how your project is organized graphically (and autocomplete makes accessing.nested.names a breeze!).