[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Pylint false positives

On Tue, 21 Aug 2018 00:36:56 +0000, Dan Sommers wrote:

>>>> (Not that I do this using "inner classes", but I do often want to use
>>>> a class as a container for functions, without caring about "self" or
>>>> wrapping everything in staticmethod.)
>>> Isn't that what modules are for?  (I suspect that I'm missing
>>> something, because I also suspect that you knew/know that.)
>> What's the syntax for creating an inner module...?
> Why does it have to be an inner anything?  An ordinary, top-level,
> "outer" module is a perfectly good "container for functions, without
> caring about "self.""

And what if you want to subdivide those functions (or other objects) into 
categories that are finer than the module, without introducing a package 

We can design the structure of our program into *outward* hierarchies, by 
adding packages with subpackages and sub-subpackages:

import spam.eggs.cheese.tomato.aardvark

So using the file system and packages, we can logically nest modules 
inside modules inside modules 'til the cows come home. But that's a 
fairly heavyweight solution, in the sense that it requires separate 
directory for each level of the hierarchy.

Sometimes a package is too much. I want a single module file, but still 
want to pull out a collection of related functions and other objects and 
put them in their own namespace, but without creating a new module.

The Zen says:

    Namespaces are one honking great idea -- let's do more of those!

but Python's namespaces are relatively impoverished. We have packages, 
modules, classes and instances, and that's it.

Classes and instances come with inheritance, self etc which is great if 
you want a class, but if you just want a simple module-like namespace 
without the extra file, classes are a pretty poor alternative. But 
they're all we've got.

Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson