[API change] Deprecating create in observers, v2: by fusing methods

[gabrieldemarmiesse]

Follow up on #541 based on the recommendation of @Qwlouse

[coveralls]

Coverage increased (+0.06%) to 85.366% when pulling 7a228c2 on gabrieldemarmiesse:removing_create_try_2 into 2b1e756 on IDSIA:master.

[JarnoRFB]

This is more complicated then expected :D However, I think that the current proposal is not really a good idea as it exposes an argument mock_args to users leaking an api only needed for testing. What @Qwlouse proposed in #541 (comment) was a bit different. However, thinking about it I am not sure if it good to put the burden of finding the right parameter combinations on the users. Even though the original change was abusing inheritance, it felt much cleaner from an API perspective.

[gabrieldemarmiesse]

@JarnoRFB I don't really understand this part:

However, I think that the current proposal is not really a good idea as it exposes an argument mock_args to users leaking an api only needed for testing. What @Qwlouse proposed in #541 (comment) was a bit different.

#541 (comment) Exposes engine and session in the user facing API, leaking an API only needed for testing too, right?

Even though the original change was abusing inheritance, it felt much cleaner from an API perspective.

I believe so too.

[JarnoRFB]

#541 (comment) Exposes engine and session in the user facing API, leaking an API only needed for testing too, right?

Fair enough :D It probably feels like this, because it is called mock_args, which makes it more explicit.

[gabrieldemarmiesse]

Alternative proposition: #541

[Qwlouse]

I'd prefer engine and session over mock_args, because they are more descriptive and they might be useful to some users (not only for testing, but also for handling obscure custom DB configurations).
I would just document them as a way to bypass the URL and manually set up the database connection.
It would also keep the interface more compatible to before, though that is not much of a concern.

If you feel that it is a problem to have this option openly exposed, I'd suggest catching the arguments with a generic **kwargs instead. That way we can hide them from the user almost completely.

[gabrieldemarmiesse]

Closing this in favor of #601