A more pythonic code ?

[ytterbium]

Hello,

I looked a little inside the code, and found its style quite unusual for python code.

First, some strange conventions :

• why all function arguments are prefixed with an underscore ? It isn't very useful.
• a lot of \" in string could be ev by using ' or """ quotation marks. And very long strings can be splitted in several lines like this:

("a long, "
"very, "
"long "
"line") 

Some ugly backslash could be removed.

And finally about the msg function : maybe the logging module can do job as good as this function, with more flexibility.

It is only some suggestions, and maybe those points were intended. But if you want, I could transform all the msg logic in order to use the logging module.

(P.S. Do you mind if we continue in french ?

[suizokukan]

Thanks for the feedback ! Please, go on in French if you want : I will translate all that's important to be read by other people.

• about methods' names : I follow https://www.python.org/dev/peps/pep-0008/#method-names-and-instance-variables : "lowercase with words separated by underscores as necessary to improve readability."
• about the ugly \" : I choosed to limit lines' length to 100 characters (see in pylintrc the line "max-line-length=100").

You're right the msg() function but I need time to think about it.

Merci encore de ces remarques que je trouve très constructives. Qu'en pensez-vous / penses-tu ?

[ytterbium]

Le problème n'est pas le nom des méthodes, mais celui des paramètres. Par exemple, pourquoi def msg(_msg, _for_console=True, _for_logfile=True, _consolecolor=None): et pas def msg(msg, for_console=True, for_logfile=True, consolecolor=None): ? Les underscores sont pour des attributs privés, ce qui n'est pas très utiles dans une fonction.

Pour les \, je suis tout à fait d'accord pour limiter la taille des lignes, mais on peut en éliminer certains en mettant entre parenthèses les strings (par exemple quand elles font plus de trois lignes).

s = 'du texte, ' \
      'du texte, ' \
      'toujours du texte'

est équivalent à

s = ('du texte, ' 
      'du texte, ' 
      'toujours du texte')

La deuxième forme limite le risque d'oublier un \ en codant.

On peut aussi éliminer des \" en remplçant les guillemets par ' ou """. Par exemple msg(' o about to remove "{0}" ') à la place de msg(" o about to remove \"{0}\" " )

Pour la fonction msg, si tu veux je peux essayer de la remplacer et de faire un pull requests.

[suizokukan]

• ok pour le nom des paramètres : je comprends le problème; en relisant https://www.python.org/dev/peps/pep-0008/#function-and-method-arguments, je lis en effet que "If a function argument's name clashes with a reserved keyword, it is generally better to append a single trailing underscore rather than use an abbreviation or spelling corruption. Thus class_ is better than clss . (Perhaps better is to avoid such clashes by using a synonym.) ". J'avais mal compris ce passage. Je proposerai un patch.
• pour les \ , je ne connaissais pas la technique des parenthèses, que je trouve très pratique. Je proposerai un patch.
• pour le msg(), j'ai des idées mais je veux bien comparer avec les tiennes. On peut commencer par en parler avant de lancer des pull requests, comme tu voudras.

[suizokukan]

Bon, en fait j'ai simplement ajouté une branch dev : j'y ai inclus un premier commit qui supprime les caractères "\" aberrants.

[suizokukan]

Les _ inutiles ont été virés mais il me faut relire la documentation dans katal.py : trop de choses ont été modifiées. Merci de ces suggestions, très intéressantes.

[suizokukan]

La branch dev contient le code annoncé : plus de _ au début des arguments des fonctions : commit 3bbad3b17b8ebbe5ccbe1c1c89ea43674a4df63b .