Fluent API for effects (monkeypatch as methods)

[mgaitan]

This PR is a (little bit) cleaner implementation to patch "functions effects" as methods. Supersedes #1104

Basically, avoid to use exec and deprecates fx.all modules, importing every function in each package's init.

In addition, it defines __all__ to reduce the namespace pollution when import from moviepy.editor import *

[coveralls]

Coverage increased (+0.2%) to 68.044% when pulling eee1e1f on mgaitan:fluent_api into 4356fcd on Zulko:master.

[mgaitan]

what happened here? you closed this in favor of something else?

[tburrows13]

Not intentional, sorry!

[tburrows13]

Oh, it closed itself when I deleted the v2 branch. Apparently there's no way to change the base now (???). You might have to make a new one, sorry.

[mgaitan]

ack, no problem.

[tburrows13]

I think it's all sorted now, you can ignore this little fiasco :)

[mgaitan]

@tburrows13 do you have an opinion about this?

It's much humble that what I had in mind, that basically was do this patching via a metaclass to avoid the need to import the "patched classes" from a different place (i.e avoid editor.py at all). I explored that idea a bit, but I then I realized it's not as easy I thought because of circular dependencies (after all, we are patching the "base" classes),

However I guess it's cleaner enough for now, and much more pythonic than the execs and all.py modules.

The unique downside (very minor IMHO) is that fx namespaces changed if for some reason you import effects directly from the packages.

In master if you import something from the fx package, you get the module

In [1]: from moviepy.video.fx import mirror_x                                                                                                                                                 

In [2]: mirror_x?                                                                                                                                                                             
Type:        module
String form: <module 'moviepy.video.fx.mirror_x' from '/home/tin/lab/moviepy/moviepy/video/fx/mirror_x.py'>
File:        ~/lab/moviepy/moviepy/video/fx/mirror_x.py
Docstring:   <no docstring>

and here you get the actual fx function for the same import

In [3]: from moviepy.video.fx import mirror_x                                                                                                                                                 

In [4]: mirror_x?                                                                                                                                                                             
Signature: mirror_x(clip, apply_to='mask')
Docstring: flips the clip horizontally (and its mask too, by default) 
File:      ~/lab/moviepy/moviepy/video/fx/mirror_x.py
Type:      function

However, this way still works in the new implementation

In [1]: from moviepy.video.fx.mirror_x import mirror_x                                                                                                                                        

In [2]: mirror_x?                                                                                                                                                                             
Signature: mirror_x(clip, apply_to='mask')
Docstring: flips the clip horizontally (and its mask too, by default) 
File:      ~/lab/moviepy/moviepy/video/fx/mirror_x.py
Type:      function

so, we are mostly ok.

[tburrows13]

This is definitely better than what we have currently, and better than #1104. Thanks for detailing how this change affects importing from the fx package, but I don't think that that should be a major concern, just something to point out in the changelog (which I can write before merging).

I wouldn't be opposed to getting rid of editor.py altogether as it is rather unpythonic, but as you point out, it might be hard to still keep the fx as methods of the classes. I'm not that familiar with package-level things, but one idea that I had was to move all of editor.py into __init__.py, so users just import moviepy or from moviepy import *. Having just tested it, it allows doing from moviepy.video.io.VideoFileClip import VideoFileClip, and then still being able to use VideoFileClip.rotate() (which is only added as a method in moviepy/__init__.py()). I think that we could go even further and prohibit importing directly from moviepy (by editing __all__?) to enforce standard pythonic (is it?) importing directly from their relevant submodules, but still do the fx as methods stuff in moviepy/__init__.py().

Perhaps that last paragraph should be a different issue/PR, and that last sentence would be quite a bit more of a drastic change and might require reworking the hierarchy of moviepy if everyone is accessing the classes from their proper locations. Furthermore, I still don't know if doing things in moviepy/__init__.py() is any more pythonic than this PR.

Your thoughts would be appreciated :)

[tburrows13]

Closes #591

[tburrows13]

Ok, here's my current thinking.

Move most of the standard imports and the fx 'trickery' into the main __init__.py, and recommend that standard moviepy programs just import what they need from moviepy, not moviepy.editor.
However, leave the stuff in moviepy.editor that only makes sense when doing 'live' editing, such as sliders (which depends on matplotlib), preview and show (which depend on Pygame) and the ipython stuff. This means that import moviepy.editor should only be used for its original intended purpose, which is live editing of movies, and importing moviepy (without editor) should take less than half the time and it won't initialise a Pygame process.

We can also look at including extra imports into either __init__.py or editor.py that are not currently in editor.py where appropriate.

@Zulko @mgaitan I'd appreciate your feedback on this.