0

PEP8 says:

Use one leading underscore only for non-public methods and instance variables.

If a class has methods that are intended for usage inside the current package, however not intended for usage in other packages, how do you name them? (i.e. not interface methods, however, they are used inside a package)

Leading underscore describes such a method as "private" which is not true. Name without leading underscore describes it as "free to use for everybody" which is misleading too.

So how to name them? How do you deal with it?

In my projects, this question usually pops ups, but I can't find answers at stack overflow. How others avoid it?

Thanks

124bit
  • 496
  • 1
  • 3
  • 13
  • 1
    I don't know of any convention for this case. Why don't you name them with leading underscore so that users of your package will know not to use them outside of the package. Then inside your package you use these "private" (or non-public) variables/methods. It is not perfect, but better than having "public" methods for this case; at least in my opinion. – Ralf Jun 26 '19 at 16:15
  • 1
    There's no convention for "package private" method and variables. If parts of a package are referencing the the non-public parts of classes in other modules in the package, encapsulation is being broken and you might as well make them public, IMO. – martineau Jun 26 '19 at 17:05
  • Is such a question generally relevant? Or I'm doing something wrong from project organization perspective? Thanks – 124bit Jun 26 '19 at 17:35
  • 1
    are you already using `__all__` in your modules as described [here](https://stackoverflow.com/questions/44834/can-someone-explain-all-in-python)? – jeschwar Jun 26 '19 at 18:12
  • 124bit: Relevant to what? Regardless, asking it there's a convention or preferred way to do something not mentioned in the PEP 8 guidelines seems reasonable — even if the practice violates encapsulation `;¬)`. – martineau Jun 27 '19 at 21:49

0 Answers0