[melbourne-pug] Thursday's Meeting

[Dave Cole]

Anthony Briggs wrote:
> Mike Dewhirst wrote:
> 
>>Anthony Briggs wrote:
>>
>>
>>>... the topic for Thursday will be "Python coding style". 
>>
>>I think the ...
>>
>>	http://www.python.org/peps/pep-0008.html
>>
>>... style guide seems to be a reasonable way forward and I would be more 
>>interested in learning where you think it may be improved on rather than 
>>covering what is already there.
> 
> 
> Sure. It's a good starting point, particularly as there are a number of
> things in there that I don't agree with, such as writing "if not
> someList:..." rather than "if someList == []:". I also tend to prefer a
> style with more whitespace, etc.

I am not sure if you are arguing for or against "if someList == []:".

I suggest that the above code is not good style.  It is very fragile if
you are testing the value of an argument because it will not detect when
someList is ().

When a care about the distinction between empty list and None I almost
always do either "if len(some_list) == 0:" or "if some_list is None:".
When using "if not some_list:" you trap both cases, which is not always
what you want.

>From a PEP-8 perspective, the variable name is even questionable.  The
mixedCase style is only condoned when you are maintaining existing code
that already uses that convention.  If you are writing new code you
should be using some_list rather then someList.

> A lot of the style guides also tend to say 'what', rather than 'why',
> and in fairly rigid fashion too, which means that it's harder to know
> when to break the rules when you need to.

Reading a book like Code Complete might a be good start for people who
want to know why you should do something rather than just be told to do
it.  While it does not discuss Python coding style, it does explore the
reasons behind various code style conventions.

>>I'm especially interested in learning about module layout and project 
>>layout within directories and spanning directories. Maybe "coding style" 
>>can be stretched to cover that and __init__.py which is still a mystery 
>>for me.

This is something I still find myself getting wrong at times.
Especially where you have multiple packages that you wish to share the
same nested package namespace.

- Dave

-- 
http://www.object-craft.com.au