[Baypiggies] Django presentation?

Daryl Spitzer daryl.spitzer at gmail.com
Tue Jul 8 00:19:54 CEST 2008

On Sat, Jun 28, 2008 at 10:43 AM, jim <jim at well.com> wrote:

> PS: daryl, how's the Django talk coming? ready
> for september or october?

I haven't prepared any kind of talk (yet), but I could.  I'd prefer
October.  I'm certainly far from the most authoritative speaker on
Django available to BayPIGgies, so I'm inclined to make my
presentation more personal; something like "What I Learned from the
Django Framework" and talk about the Python patterns and idioms used
in Django.

But I defer to any Django experts who would be interested in presenting.


On Sat, Jun 28, 2008 at 10:43 AM, jim <jim at well.com> wrote:
>   it's not for me to approve of anything, that's
> for the group to coalesce or congeal or something.
>   i worry that a feature such as this has the
> problem of sustenance: can we manage to keep it up
> each month, what if there's a talk that needs the
> whole time, what if we can't find someone or think
> something up.... that said, it seems doable, just
> include the fact of the newbie nugget in the web
> page and email announcements for the month and
> be clear that this feature may not always appear
> in every monthly meeting.
>   i'm big on the idea of providing a little support
> to speakers (e.g. steven knight's request for input
> as to his august talk, no bayPIGgies discussion so
> far, sad to say). i'd like to include the possibility
> of helping speakers develop their talks as a formal
> part of the speaker-getting process so that it doesn't
> appear that _we_ are helping some poor decrepit
> half-brain gussy up--people are different, some
> welcome support, others take umbrage. the issue is
> regularly to include the offer formally as an option
> the speaker may choose or not.
>   i'm not clear on your note to daryl as to what
> info you're hoping he'll provide (daryl may be, of
> course, though others may not be, so discussion
> seems helpful).
>   i say compare to C as a matter of planning. in
> C as in most any language, closing a file after
> writing is much more important than after reading,
> the issue is how to do it in Python. so jj's
> comment should head the entire set of examples,
> and each example would benefit from comments noting
> the technique.
>   in the first example, the try and finally blocks
> seem pythonic. anything pertinent regarding release?
>   in the second example, importing may bear a note
> (not available in C or many other languages), and
> __future__ bears two notes, the magic underbars
> and what's __future__ about? getting the with
> statement bears discussion. definitely pythonic.
> release 2.5 and after.
>   the third example seems murky to me: why add
> the complication of database manipulation? oh,
> well. now that we've got the with statement, what's
> from contextlib import closing all about? seems
> that closing() is a bona fide member of our
> namespace, is that best, or is there an argument
> to use contextlib.closing() instead (i.e. what's
> the effect and style guidelines for using from?
>   well, i got it off my chest, hope it helps.
> jim
> 415 823 4590 my cellphone, call anytime
> PS: daryl, how's the Django talk coming? ready
> for september or october?
> On Sat, 2008-06-28 at 03:56 -0700, Shannon -jj Behrens wrote:
>> On Fri, Jun 27, 2008 at 6:10 PM, Daryl Spitzer <daryl.spitzer at gmail.com> wrote:
>> > +1
>> >
>> > I could stand to learn more about:
>> >
>> >> * Using IPython (and installing it with an egg).
>> >> * Using "try/finally" with file handles vs. using the "with" statement.
>> >
>> > And since the best way to learn something in depth is to teach it, I
>> > volunteer to present a "newbie nugget" (good name) on these.
>> Jim, I hate to give you more work, but if you approve of the newbie
>> nuggets idea, then I think we have our first speaker ;)
>> Daryl, what I would expect to see in such a talk are the following idioms:
>> # This example makes a lot more sense when you're writing than when
>> you're reading.  It's not all that important to close
>> # a file explicitly when you're reading, but it's critical when you're writing.
>> >>> f = open('notes.otl')
>> >>> try:
>> ...     print f.readline()
>> ... finally:
>> ...     f.close()
>> ...
>> Howto
>> and:
>> # This requires Python 2.5.
>> >>> from __future__ import with_statement
>> >>> with open('notes.otl') as f:
>> ...     print f.readline()
>> ...
>> Howto
>> # Here's how to automatically close database connections.
>> from __future__ import with_statement
>> from contextlib import closing
>> with closing(create_db_connection()) as connection:
>>     ...
>> Happy Hacking!
>> -jj

More information about the Baypiggies mailing list