[Ml-yokadi] Coding style nitpick

[Aurélien Gâteau]

Sébastien Renard wrote:
> 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 think the rules should be:
- Use "import foo" for modules which provide top-level functions.
- Use "from foo import bar" (or "from foo import *", I don't see the 
difference) for modules which provide classes.
- Avoid providing both class and top-level functions in the same module.


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

Cool!

>> 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. 

It's just one .py file, so it's not really a dependency. I was thinking 
about including it in our source code.

>> Sorry for being annoying, I should probably have written this earlier.
> 
> It's never tool late to define some coding guilines.

I meant I should have written this when you made your changes :). I 
agree, it's never too late to write coding guidelines.

> Maybe we could define a 
> common pylintrc file to ease code style control ? Find mines attached for 
> comment.

I do not know pylint... will have a look at it.

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

Yes, I follow kdelibs policy here (how surprising :) ), one space before 
and after '=', one space after ','.

Aurélien