[melbourne-pug] Thursday's Meeting

[Anthony Briggs]

Dave Cole wrote:
> 
> 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:

The "len(some_list)" version is even better than mine, but the "if not
some_list:" though, is distinctly dodgy, particularly if you're working
with ex-C/C++/Java programmers who like to return None or 0 on error.

>>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
> 
> pychecker is your friend.

Yep, but it won't catch the other cases where someone's explicitly
returned None :\

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

Well, let's continue with the list example. PEP-8 says:

    - For sequences, (strings, lists, tuples), use the fact that empty
      sequences are false, so "if not seq" or "if seq" is preferable
      to "if len(seq)" or "if not len(seq)".

which is not what I do, and is not what you do. It helps because it's a
lot more rigorous than the PEP-8 style, and effectively gives you an
assert statement to check that you have a sequence, catching a common
error. The point I was trying to make is that sometimes the standard is
wrong, either for a specific situation, or in general.

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

There should always be a rationale to it, if you think hard enough. Most
of PEP-8 is common sense, but there are times when you should break it.
PEP-8 even says that explicitly.

It's also a better way to discuss code style - if you can talk about why
you do things a certain way, that often helps to work around any flamewars.

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

Yes, but I found it to be aimed mainly at C/C++/Java code, rather than
Python, so there are some parts which are not as relevant, and other
parts which aren't covered. Not that it's not a good read, but that it
doesn't cover dynamic languages as well, despite having quite a few
Python examples.

Anthony

-- 
------------------------------------------------------
 HyPerACtIVe?! HEY, Who ArE yoU cAllInG HYPERaCTive?!
 abriggs at westnet.com.au
------------------------------------------------------