Multiple cases of code refactoring

There are multiple cases where the code should be refactored, here's what I've noticed:

Some code like this function at ./polyenum/enumerators.pyx on this line don't belong in the module in which they are. Creating a seperate cythonized module in which some tools like print_all() could find their place may be a suitable solution.
Multiple cythonized classes don't seem to use OOP principles like inheritance. For instance, code like the following block could be placed only in the base class' __cinit__:
```
self.area = area
self.height = height
self.width = width
self.allow_kiss = allow_kiss
self.verbose = verbose
```
However, one must know that __cinit__ behaves kind of specially: the base class' __cinit__ method is always called at object construction step even if it is redefined in the child class. Pretty much all classes should be revised where they have duplicated methods, attribute intialisation. For instance, the function print_all() is written twice in two different classes that have common base class.
[edit] __cinit__ methods' signature shouldn't use kwargs since the program creates constantly new objects for enumerating and kwargs, being a python concept, slows the program. A solution could be that __cinit__ methods expect one or more struct holding all of the arguments inside.
[edit] polyenum.in shows multiple cases of refactoring needs like the check for user_data.plain before printing something that must be placed in a function / method and not everywhere in the code.
[edit] some parts of the code are not consistent. For e.g., sometimes, getters and setters are used to access and modify objects attributes and sometimes they're accessed and modified directly. Getters and setters may be removed accordingly to the level of encapsulation that python suggests anyway. Some calls like this:
```
enumerator.set_area(area)
```
could be replaced by:
```
enumerator.area = area
```

Notice: If one would want to supply a fix for any of the above points, he should be providing changes through seperate pull requests for each of the independant tasks that are being suggested.

Comments (6)