[melbourne-pug] Thursday's Meeting

[Dave Cole]

Anthony Briggs wrote:
> Dave Cole wrote:

>>I am not sure if you are arguing for or against "if someList == []:".
> 
> In general, I'd argue for it, since it's more explicit.
> 
>>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 ().
> 
> But it'll also 'fire' when someList is None, "", 0, etc.

I think you missed my point.  Consider the following:

def func(some_list):
    if some_list == []:
        print 'the list was empty'
    else:
        print 'there were things in the list'

func(())

If the function is going to deal with something that implements the
sequence protocol, why go out of your way to prevent other types that
implement the sequence protocol.

def func(some_list):
    if len(some_list) == 0:
        print 'the list was empty'
    else:
        print 'there were things in the list'

So one of the following objects could be successfully passed to the
function.

class List:
    def __init__(self): ...
    def __len__(self): ...
    def __getitem(self, i): ...

>>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.
> 
> Yep. In the case where you don't know what you're testing, you might be
> able to save some logic by just testing the variable. In a list mangling
> function though, I'd use the explict test - you'll catch broken programs
> much more quickly.

I disagree with that.  I think it is a lot better to test arguments by
the protocols implemented rather than the type.

> Just a bit of background: I've had a few nasty debugging sessions over
> the past little where the culprit has turned out to be a function
> dropping out of the bottom and returning None (not my code, btw) instead
> of an integer or a list. With an implicit test, it's suprising how far
> you can get from that initial error before everything crashes :)
> Explicit testing catches those sorts of errors far faster.

pychecker is your friend.

>>>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.
> 
> 
> Yeah, here we get into personal style issues, and risk starting a flame
> war :)

To paraphrase a friend.  PEP-8 explains how a native "speaker" of Python
writes code.  If you want to write like a native and not a foreigner
then you should follow PEP-8.  Writing with an accent will mean that
your code looks foreign to natives and will be unpleasant to look at.

Each community has its own conventions and accent on the language.  By
developing your own accent you are (to a degree) isolating yourself from
the larger community.  It is hard to see how that helps you.

If you want to write Java (for example) in Python, then maybe you should
be developing in Java.

> perhaps because the caps jump up and make it more legible, whereas the
> underscores blend in a bit. It also depends on what you're used to -
> someone who reads code with underscores all day is going to find the
> latter more readable.

Exactly my point.  The wider community follows PEP-8.  Why make it hard
for new comers to your project by enforcing foreign style.

> This is partly why I picked this particular topic, (other than that it's
> good for getting a discussion going :) ) -- I actually disagree with a
> lot of what PEP-8 has to say. It's not suprising I suppose, considering
> that it's essentially distilled from Guido's personal style, but I'm
> interested to explore some of the rationale behind it.

I am not sure that there is any rationale to it.  It just represents the
way a native Python programmer does things.  Guido is the founder of the
language, so if he says "this is Python style" then that is the correct
style.

>>>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'll have another look at it and see what it's got to say about camel
> case :) From memory though, it's largely geared towards the more static
> languages (C/C++ and Java), so there are some aspects (eg. being passed
> "", None or a list) that wouldn't necessarily come up as often.

I did not mean that you should look to Code Complete for an explanation
of Python style.  I meant that if you want to see a discussion of "why"
for many programming issues then Code Complete is a good read.

- Dave

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