[DONOTMERGE] Simplified FauxFactory class definition.

[omaciel]

This pull requests proposes to simplify the definition of the
FauxFactory class for backwards compatibility by looking into the
module's own set of functions and individually adding them to the class
using setaatr, and removing a long list of function definitions that
were calling the newer set of functions.

[elyezer]

for key, val in dict(fauxfactory).items():?

[omaciel]

fauxfactory is a module and non-iterable.

[omaciel]

In [1]: from fauxfactory import FauxFactory

In [2]: FauxFactory.generate_alp
FauxFactory.generate_alpha         FauxFactory.generate_alphanumeric

In [3]: FauxFactory.generate_alpha(3)
Out[3]: u'QjP'

)$ make test-all
coverage run -m unittest discover --start-directory tests --top-level-director
y .                                                                          
..............................................................................
..............................................................................
----------------------------------------------------------------------
Ran 156 tests in 0.805s

OK

[Ichimonji10]

Again, this is not backward-compatible.

[Ichimonji10]

What happens if a new gen_* method is added to the module, or a parameter to a gen_* method changes or receives a new default value? In that case, the FauxFactory class is not identical to what was formerly in place.

[omaciel]

@Ichimonji10

What happens if a new gen_* method is added to the module, or if default parameters change? In that case, the FauxFactory class is not identical to what was formerly in place.

Unless I misunderstood you, all functions from the module are automatically added to FauxFactory if they start with gen_, so adding new functions would still work. Now, if we ever change the arguments for our gen_ functions, then we will intentionally break backwards compatibility :)

[omaciel]

Using locals().items() instead of importing the module itself.

[Ichimonji10]

flake8 should complain about this missing line. It looks for two blank lines preceding each class or function definition.

[Ichimonji10]

Unless I misunderstood you, all functions from the module are automatically added to FauxFactory if they start with gen_, so adding new functions would still work.

As an example, let's say a function gen_limerick is added to this method module. In that case, class method FauxFactory.gen_limerick will be created. This is not completely backward compatible.

[Ichimonji10]

Now, if we ever change the arguments for our gen_ functions, then we will intentionally break backwards compatibility

This breakage is unnecessary. We should be able to independently vary the gen_* functions and FauxFactory.generate_* class methods, should we not? As things stand now, we can change a gen_* function and update the FauxFactory.generate_* wrapper method, and no one with old code is the wiser.

[omaciel]

@Ichimonji10 are you then NACKing this PR? :)

[Ichimonji10]

are you then NACKing this PR? :)

It's just worth weighing the costs and benefits here. We get the benefit of terse, nice-looking code, but at the cost of breaking backward compatibility in some subtle ways. Of course, you could also make the argument that that's what version numbers are for, and we're just providing a close-enough approximation of backward compatibility.

[omaciel]

Getting all sorts of issues with Travis and Python3 RuntimeError: dictionary changed size during iteration. Will revisit some time later... or not.