[Baypiggies] Discussion for newbies/beginner night talks

[Shannon -jj Behrens]

On 2/9/07, Chad Netzer <chad.netzer at gmail.com> wrote:
> First, I want to thank Dennis and Drew for speaking last night, and
> Jim Stockford for hosting the post talk discussion.
>
> I've created this thread to start discussion about the "newbie" night
> that was talked about at the end of last night's meeting. If people
> reply to this thread only (or mostly), those on the list who aren't
> interested can easily ignore it.  If we are to host a beginners night,
> it will be best to start organizing it soon, in order to line up
> topics, speakers, make timely announcements, etc.
>
> One person at the meeting asked about Python "idioms", and in fact in
> a previous email I brought up the idea of an "anti-idioms"
> presentation. I'll get the ball rolling with a few idioms and tips
> that I can think of, without explanation.  If people are interested in
> the why, or wish to add some, please reply and discuss.  Perhaps it
> could evolve into a good QA topic for beginners.
>
> Also, if people have other ideas or suggestions for a beginners night,
> please feel free to discuss them here.
>
>
>
> Some Python beginner tips and idioms:
>
> 1) Do not use lists, dicts, or any mutable object as default
> arguments; use None instead.
>
> 2) If you need to do a lot of string appends, use lists and join().
>
> 3) Understand and use iterators in loops.
>
> 4) Use dictionaries, sets, and other mappings for searches and
> queries.
>
> 5) Understand and use the decorate/sort/undecorate (DSU) idiom.
>
> 6) Catch exceptions that you can handle, don't suppress ones you
> can't.
>
> 7) Ask forgiveness, not permission. Ie. perform conversions and
> other operations using "try". Avoid queries to determine if an
> operation will succeed.
>
> 8) Use assert() to document your code.
>
> 9) Don't overuse tuples as "read only" lists.  Use them to make
> dictionary keys, or pass around short lived groups of objects.
>
> 10) Use open() to open files, not file(). (trivial, perhaps)

Sorry, I have more:

#) Keep a Python shell open.  Import modules.  Use help(obj) within
the shell.  Try things out.  Copy from the shell into your code.  The
shell is a necessary part of the development environment.

#) Use print instead of a debugger.  In rare cases, throw the
following into your code:

import pdb
pdb.set_trace()

Now, from within the debugger, instead of painstakingly tracing over
your code, pretend you're in the Python shell and look around.

#) In network servers, use a thread that listens on a unix socket as a
backdoor.  It should act like a Python shell so you can look around
your application as it's running.

-jj

-- 
http://jjinux.blogspot.com/