[Ml-yokadi] Coding style nitpick

[Sébastien Renard]

Le vendredi 5 décembre 2008, Aurélien Gâteau a écrit :
> Hi,
>
> Right now Yokadi code oscillates between code importing modules like this:
>
>    import foo
>    foo.bar()
>
> and code importing modules like this:
>
>    from foo import bar
>    bar()

And some ugly from xxx import *

> As Pythoneers like to say, "Explicit is better than implicit". I much
> prefer the first version to the second one. Using "from foo import bar"
> hides the fact that "bar()" comes from "foo", which makes code less
> readable and more prone to name conflicts IMHO.

Well, it depends of which module we are talking about.

> Note that this is only true for namespace-like modules. For modules
> which only provide one class, I consider it ok to write this:
>
>    from someclass import SomeClass
>    x=SomeClass()
>
> Rather than:
>
>    import someclass
>    x=someclass.SomeClass()
>
> Which would be useless duplication.

Sure.

> I know this can be painful for os.path functions, though.

Exactly. I am thinking to its, because we use it a lot and multiple times in 
one line. I will be more explicit but much less readable. 
Moreover, their names are well known (join, abspath, dirname etc.) and should 
not have any confusion (ie. no yokadi function or method should be called 
like that - that's evil).
Could we make an exception for well well known standard module ?

And what about Yokadi modules themselves ? Do you really want to apply the 
same rules ?
For utils.* I would say yes.
For db, I would say no.

Idem for sqlobject. I dislike "from sqlobject import *" and always import 
explicitely all functions or class. But I would not like to prexif all my 
code with sqlobject name !

I've just commit some little cleanup to respect a little bit more the policy.

> Maybe it would 
> be a good idea to use the wonderful path.py module instead :)

Path.py is cool, but it would add a strong dependency only for little dev 
confort. 

> Sorry for being annoying, I should probably have written this earlier.

It's never tool late to define some coding guilines. Maybe we could define a 
common pylintrc file to ease code style control ? Find mines attached for 
comment.

We have also quite different policy about space before/after equal and 
comma...

a+
-- 
Sébastien
-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: .pylintrc
Type: text/x-java
Taille: 8937 octets
Desc: non disponible
Url: http://sequanux.org/pipermail/ml-yokadi/attachments/20081206/6bd03e50/attachment.java