Empty files are perfectly fine:

The __init__.py files are required to make Python treat the directories as containing packages; this is done to prevent directories with a common name, such as string, from unintentionally hiding valid modules that occur later on the module search path. In the simplest case, __init__.py can just be an empty file, but it can also execute initialization code for the package or set the __all__ variable, described later.

Depending on what you plan to do it's a good place to import public stuff from the modules in your package so people can simply use from yourpackage import whatever instead of having to use from yourpackage.somemodule import whatever.

class Point:
    def __init__(self):
        pass

The empty __init__.py files are needed by Python (up to version 3.2) ideintify a directory as a Python package - and its contents as modules/sub-packages.

If you did not create them, PyDev created them for you - and they need not contain anything.

If your mates can't import code.engine asstated, it ismore likely the directory containing code itself is not part of Python's path (PYTHONPATH environment variable) - so it can't find from where do descend into the code package.

You can use the builtin __len__ method:

class rand:
   def __init__(self):
      self.c = []
   def __len__(self):
      return len(self.c)

c = rand()
print(len(c))

Output:

0

The top-level package suggested by your folder layout is our_project. That means the folder containing it should be in the Python search path.

Then you can do absolute imports from anywhere with from our_project.directory1.file1 import my_function.

From the my_project.directory3.file7 module, you could instead use a relative import, from ..directory1.file1 import my_function.

The relative import might not work though if you're running file7.py as a script (with e.g. python file7.py on the command line). It's generally a bad idea to run scripts that are in a package by filename, as the interpreter won't be able to tell where they're supposed to be put in the package hierarchy. Instead, use python -m our_project.directory4.file7 to run the module by its absolute name.

Here is an link to the python docs which has a nice tutorial where all of it is explained.

The __init__.py has two main functions:

• Marking packages: It marks a directory as a Python package, and the inner .py files as Python modules.

• Initialization code: As its name suggests, any code inside the __init__.py is automatically executed when the package is imported. This is the right place to run initialization code required for a certain package; however, it's perfectly OK to leave the __init__.py file empty.

Basically the __init__.py file makes Python treat directories containing it as modules.

So by deleting that file Django doesn't treat it as a module and it will stop working.

So it is bad idea to delete those files.

Option 1: Don't declare them at all

It seems that you come from a static language (Java, C#, C++) and you have difficulty adapting to Python. Since Python is dynamic, you can add and delete attributes from it any time you want, both inside and outside the class' methods. If you don't have an appropriate value, you don't declare it in __init__, declare it in some other method, that's perfectly fine.

Option 2. Set some default value

What exactly do you mean by an "existing but empty" value? What does it mean to be empty? In (some) statically typed languages, member values that you don't initialize explicitly are initialized automatically to their default value (integers initialized to 0, pointers/ references to null, etc). If you know an appropriate default value, just initialize your arg to that value; if there is no appropriate default, go to option 1.

2a. Assign 'manually'

def __init__(self):
    self.arg1 = 0
    self.arg2 = 'a'
    self.arg3 = None

2b. Through default function arguments

def __init__(self, arg1=0, arg2='a', arg3=None):
    self.arg1 = arg1
    self.arg2 = arg2
    self.arg3 = arg3

2c. Use properties (read more)

class ClassName(object):
    @property
    def arg1(self):
        return self._arg1 if hasattr(self, '_arg1') else 0

    @arg1.setter
    def arg1(self, value):
        self._arg1 = value

Conftest file is used by pytest to provide fixtures : Official doc

For __init__.py, it is used to declare packages, and ca be used to search modules in your directories. It can also be used to initialise code (this is the first thing that is executed when you import a module): doc

So, both are useful.

Consult: "Least Astonishment" and the Mutable Default Argument

But to solve your problem do this:

def __init__(self,l=None):
    self.list = l if l else []

alternatively, as has been suggested by an edit, (which should have been a comment). you can use or:

def __init__(self, l=None):
    self.list = l or []

The problem is you're running pylint in your workdir (pylint .). Pylint will expect an init.py file there.

Take a look at this discussion.

Your best shot is to select the directories you want to lint. If you can't do so (ie: Django project). You'll have to make a custom workaround like in the thread.

I think you should avoid both solutions. Simply because you should avoid to create uninitialized or partially initialized objects, except in one case I will outline later.

Look at two slightly modified version of your class, with a setter and a getter:

class MyClass1:
    def __init__(self, df):
          self.df = df
          self.results = None

    def set_results(self, df_results):
         self.results = df_results

    def get_results(self):
         return self.results

And

class MyClass2:
    def __init__(self, df):
          self.df = df

    def set_results(self, df_results):
         self.results = df_results

    def get_results(self):
         return self.results

The only difference between MyClass1 and MyClass2 is that the first one initializes results in the constructor while the second does it in set_results. Here comes the user of your class (usually you, but not always). Everyone knows you can't trust the user (even if it's you):

MyClass1("df").get_results()
# returns None

Or

MyClass2("df").get_results()
# Traceback (most recent call last):
# ...
# AttributeError: 'MyClass2' object has no attribute 'results'

You might think that the first case is better because it does not fail, but I do not agree. I would like the program to fail fast in this case, rather than do a long debugging session to find what happened. Hence, the first part of first answer is: do not set the uninitialized fields to None, because you loose a fail-fast hint.

But that's not the whole answer. Whichever version you choose, you have an issue: the object was not used and it shouldn't have been, because it was not fully initialized. You can add a docstring to get_results: """Always use set_results **BEFORE** this method""". Unfortunately the user doesn't read docstrings either.

You have two main reasons for uninitialized fields in your object: 1. you don't know (for now) the value of the field; 2. you want to avoid an expansive operation (computation, file access, network, ...), aka "lazy initialization". Both situations are met in real world, and collide the need of using only fully initialized objects.

Happily, there is a well documented solution to this problem: Design Patterns, and more precisely Creational patterns. In your case, the Factory pattern or the Builder pattern might be the answer. E.g.:

class MyClassBuilder:
    def __init__(self, df):
          self._df = df # df is known immediately
          # GIVE A DEFAULT VALUE TO OTHER FIELDS to avoid the possibility of a partially uninitialized object.
          # The default value should be either:
          # * a value passed as a parameter of the constructor ;
          # * a sensible value (eg. an empty list, 0, etc.)

    def results(self, df_results):
         self._results = df_results
         return self # for fluent style
         
    ... other field initializers

    def build(self):
        return MyClass(self._df, self._results, ...)

class MyClass:
    def __init__(self, df, results, ...):
          self.df = df
          self.results = results
          ...
          
    def get_results(self):
         return self.results
    
    ... other getters
         

(You can use a Factory too, but I find the Builder more flexible). Let's give a second chance to the user:

>>> b = MyClassBuilder("df").build()
Traceback (most recent call last):
...
AttributeError: 'MyClassBuilder' object has no attribute '_results'
>>> b = MyClassBuilder("df")
>>> b.results("r")
... other fields iniialization
>>> x = b.build()
>>> x
<__main__.MyClass object at ...>
>>> x.get_results()
'r'

The advantages are clear:

1. It's easier to detect and fix a creation failure than a late use failure;
2. You do not release in the wild a uninitialized (and thus potentially damaging) version of your object.

The presence of uninitialized fields in the Builder is not a contradiction: those fields are uninitialized by design, because the Builder's role is to initialize them. (Actually, those fields are some kind of forein fields to the Builder.) This is the case I was talking about in my introduction. They should, in my mind, be set to a default value (if it exists) or left uninitialized to raise an exception if you try to create an uncomplete object.

Second part of my answer: use a Creational pattern to ensure the object is correctly initialized.

Side note: I'm very suspicious when I see a class with getters and setters. My rule of thumb is: always try to separate them because when they meet, objects become unstable.

It used to be a required part of a package (old, pre-3.3 "regular package", not newer 3.3+ "namespace package").

Here's the documentation.

Python defines two types of packages, regular packages and namespace packages. Regular packages are traditional packages as they existed in Python 3.2 and earlier. A regular package is typically implemented as a directory containing an __init__.py file. When a regular package is imported, this __init__.py file is implicitly executed, and the objects it defines are bound to names in the package’s namespace. The __init__.py file can contain the same Python code that any other module can contain, and Python will add some additional attributes to the module when it is imported.

But just click the link, it contains an example, more information, and an explanation of namespace packages, the kind of packages without __init__.py.

The sole purpose of __init__.py is to indicate that the folder containing this file is a package, and to treat this folder as package, that's why it is recommended to leave it empty.

Consider following hierarchy:

foo
    __init__.py
    bar.py

When you use from foo import bar or import foo.bar, Python interpreter will look for __init__.py in foo folder, if it finds it, the bar module will be imported else it won't; however, this behavior has changed over the time, and it may be able to successfully import the modules/packages even if __init__.py is missing, but remember Zen of Python: Explicit is better than implicit, so it's always safe to have it.

But in case, if you need some package level variables to be defined, you can do it inside the __init__.py file, and all the modules inside the package will be able to use it.

And in fact, if you look at PEP 257, it mentions that the __init__.py can also contain the documentation for package level information.

def __init__(self, x=[]):
    self._x = x

In this case, whenever you initialize an instance of your class with no argument, self._x will reference the same object instead of creating a new empty list for each instance. In effect, self._x.append is appending to the same list.

The recommended way to do this is

def __init__(self, x=None):
    if x is None:
        # create a new list
        x = []
    self._x = x

This applies to all mutable objects (such as dict and set...).

Overview

@Mike's answer is correct but too imprecise. It is true that Python 3.3+ supports Implicit Namespace Packages that allows it to create a package without an __init__.py file. This is called a namespace package in contrast to a regular package which does have an __init__.py file (empty or not empty).

However, creating a namespace package should ONLY be done if there is a need for it. For most use cases and developers out there, this doesn't apply so you should stick with EMPTY __init__.py files regardless.

Namespace package use case

To demonstrate the difference between the two types of python packages, lets look at the following example:

google_pubsub/              <- Package 1
    google/                 <- Namespace package (there is no __init__.py)
        cloud/              <- Namespace package (there is no __init__.py)
            pubsub/         <- Regular package (with __init__.py)
                __init__.py <- Required to make the package a regular package
                foo.py

google_storage/             <- Package 2
    google/                 <- Namespace package (there is no __init__.py)
        cloud/              <- Namespace package (there is no __init__.py)
            storage/        <- Regular package (with __init__.py)
                __init__.py <- Required to make the package a regular package
                bar.py

google_pubsub and google_storage are separate packages but they share the same namespace google/cloud. In order to share the same namespace, it is required to make each directory of the common path a namespace package, i.e. google/ and cloud/. This should be the only use case for creating namespace packages, otherwise, there is no need for it.

It's crucial that there are no __init__py files in the google and google/cloud directories so that both directories can be interpreted as namespace packages. In Python 3.3+ any directory on the sys.path with a name that matches the package name being looked for will be recognized as contributing modules and subpackages to that package. As a result, when you import both from google_pubsub and google_storage, the Python interpreter will be able to find them.

This is different from regular packages which are self-contained meaning all parts live in the same directory hierarchy. When importing a package and the Python interpreter encounters a subdirectory on the sys.path with an __init__.py file, then it will create a single directory package containing only modules from that directory, rather than finding all appropriately named subdirectories outside that directory. This is perfectly fine for packages that don't want to share a namespace. I highly recommend taking a look at Traps for the Unwary in Python’s Import System to get a better understanding of how Python importing behaves with regular and namespace package and what __init__.py traps to watch out for.

Summary

• Only skip __init__.py files if you want to create namespace packages. Only create namespace packages if you have different libraries that reside in different locations and you want them each to contribute a subpackage to the parent package, i.e. the namespace package.
• Keep on adding empty __init__.py to your directories because 99% of the time you just want to create regular packages. Also, Python tools out there such as mypy and pytest require empty __init__.py files to interpret the code structure accordingly. This can lead to weird errors if not done with care.

Resources

My answer only touches the surface of how regular packages and namespace packages work, so take a look at the following resources for further information:

• PEP 420 -- Implicit Namespace Packages
• The import system - Regular packages
• The import system - Namespace packages
• Traps for the Unwary in Python’s Import System

If not having a value has a meaning in your program (e.g. an optional value), you should use None. That's its purpose anyway.

If the value must be provided by the caller of __init__, I would recommend not to initialize it.

If "" makes sense as a default value, use it.

In Python the type is deduced from the usage. Hence, you can change the type by just assigning a value of another type.

>>> x = None
>>> print type(x)
<type 'NoneType'>
>>> x = "text"
>>> print type(x)
<type 'str'>
>>> x = 42
>>> print type(x)
<type 'int'>