Cleaned pyro references from most python files.

Replaced 'pyro' by 'communication' everywhere. 
Not sure but there could be a better term ? if yes then I could use it if someone provide it.

Still libexec/check_shinken.py to be converted to new communication mode..


On Thu, Oct 16, 2014 at 9:45 PM, Grégory Starck <notifications@github.com>
wrote:

> In shinken/daemon.py:
>
> > @@ -570,16 +570,19 @@ def do_exit(sig, frame):
> >          del self.debug_output
> >
> >
> > -    # Main "go daemon" mode. Will launch the double fork(), close old file descriptor
> > -    # and such things to have a true DAEMON :D
> > -    # use_pyro= open the TCP port for communication
> > -    # fake= use for test to do not launch runonly feature, like the stats reaper thread
> > -    def do_daemon_init_and_start(self, use_pyro=True, fake=False):
> > +    def do_daemon_init_and_start(self, use_communication=True, fake=False):
> > +        '''Main daemon function.
>
> come on ;)
>
No really.


> It's not *that* a nightmare - I have had some real nightmares these last
> days&nights investigating and enhancing the livestatus module on the 1.4
> branch (hopefully it's now done and I'm going to "front-port" that on the
> 2.x branch by the way - but it was way over such styling question), you
> must be joking I bet :p
>
No

> Unless you mean it's the actual particular kind or form of this specific
> docstring that you don't like ? I could understand that and change the form.
>
I don't like to see prototype and code with distance. If we could put doc
string BEFORE the prototype I'll do it, but it's not possible (even golang
is able to do it...).

> I know there is quite a lot of such comments preceding quite a lot of
> functions (docstring-less) in shinken.
>
I let some but I won't allow it again. It really make code hard to read for
me.

> But sometimes(not to say more often) the comments should/could - IMHO - be
> made into a plain/real function's docstring. Like when the comments just
> relate what the function actually does (more or less detailed) for instance
> (and when the parameters are also explained/commented then it's the icing
> on the cake) ;)
>
Yes, that's comments for human. Doc strings are only cool for testing (we
already got testing framework for this) and doc (code doc I never
understood or used in any tool).

> But it's basically just a question of habit to be used to the functions
> docstrings. Same for how they are formatted :p
> Though I agree we should follow some fixed/defined way that we like the
> more, as far as it's satisfying :)
>
You can put the format you want in a comment before the prototype, but not
in a doc string that will add distance betwween protoype and code.

> Anyway, here effectively I've apparently badly "doc-stringified" the
> comment, the function does not return any value (but None) so it should
> have been made clear. Guess I've had a copy-past too much or something like
> that. going to clean that and make a new pull request then..
>
oki.

> —
> Reply to this email directly or view it on GitHub
> <https://github.com/naparuba/shinken/pull/1344/files#r18981152>.
>