[socal-piggies] Next meeting: Thu. April 28th at Evite
Steve Wedig
stevewedig at gmail.com
Fri Apr 29 16:22:04 PDT 2011
Thanks everybody for attending yesterday. I very much enjoyed the lively
discussion during my talk.
You can find my slides & code for the talk here:
http://code.google.com/p/lingospot/
I added 3 slides with "Post Talk Notes", to provide more detail about some
of the areas of discussion. (For convenience, I also include the content of
those 3 slides below.)
Have a nice weekend!
- Steve
--------------------------------------------------------------------------------
Post Talk Notes Slide 1: global
--------------------------------------------------------------------------------
The "global" keyword is like "import *", I would recommend never using it,
or using it in very select situations.
I use it in the previous slide to overcome the restriction that Python's
lexical closures only have read-only variable access by default:
- Here's a note from Guido:
http://mail.python.org/pipermail/python-dev/2003-October/039214.html
That being said, global only works for variables at the module level. It is
rarely a good idea to be mutating module level variables. Usually it is
better to encapsulate the changing state in a class/object.
--------------------------------------------------------------------------------
Post Talk Notes Slide 2: @unroll
--------------------------------------------------------------------------------
Unrolling collections is useful when you find yourself wishing you could
write multiline comprehensions.
During the talk, someone suggested that instead of @unroll.list, we can
simply do @list. I agreed at the time, however this was incorrect. Trying to
use list as a decorator (@list) causes the inner function to be passed into
the list constructor, which of course doesn't work.
I included this in the updated unroll unit tests...
def test_constructors_not_decorators():
for decorator in [ list, tuple, set, frozenset, dict, frozendict ]:
def attempt():
@decorator
def wrapped():
pass
raises( TypeError, attempt )
--------------------------------------------------------------------------------
Post Talk Notes Slide 3: Option
--------------------------------------------------------------------------------
Sometimes functions and methods must return a value representing "no
output". Often the Null Object Pattern (
http://en.wikipedia.org/wiki/Null_Object_pattern) isn't possible, so we
instead return a special value like "null", "None", or "nothing".
Every client, for every call of such a function, must remember to check
whether the function returned "normal" output, or the special "no output"
value. Since the function's clients are human, there is, and always will be,
a constant rate of forgetting to perform this check.
Given this reality, lets examine the difference between 2 choices for what
to return in the "normal" case.
- Null Reference Approach: Directly return the function's "normal" output
value.
- Option Wrapper Approach: Return an object wrapping the "normal" output
value.
With both approaches, we return a special object in the "no output" case.
----------------------------------------
Forgetting to check with approach 1: Null References
----------------------------------------
When the client forgets to check for "no output", their program will work
until they cause the function to return "no output". At this point, a "null
reference error" will occur. In Python, the error happens when you try to
access an attribute on None. These errors occur at runtime for both
statically and dynamically typed languages. Hopefully this error is caught
during testing. However, the tester is frequently the bug author who forgot
to check for null, so often they will also not know to verify the null case
in their tests. This leads to an inevitable stream of null reference errors
in making it into production. The size of this error stream can be reduced
by testing, documentation, code reviews, etc.
----------------------------------------
Forgetting to check with approach 2: Option Types (in a dynamically typed
language)
----------------------------------------
When the client forgets to check for "no output", their program will not
work, regardless of whether their testing causes the function to return "no
output" or a "normal" value. Either way, they will forget to unwrap the
value, and it will cause a type error the first time they try to use that
value. Even the most minimal test coverage will catch this bug at test time,
instead of in production.
----------------------------------------
Using Option Types in Python
----------------------------------------
Without language support, Option wrapping values creates overhead for
developers. With a decorator like @Option.wrapper, the overhead for wrapping
outputs of functions, methods, and properties is minimal. In our experience,
this is a favorable tradeoff.
I would advise against expecting Option wrapped values as inputs to your
functions and methods. That would force all of your clients to manually wrap
inputs before passing them into your function. This would certainly not be a
favorable tradeoff.
On Thu, Apr 28, 2011 at 3:12 PM, Daniel Greenfeld <pydanny at gmail.com> wrote:
> Hey Grig,
>
> Me and Audrey have our talks ready so I hope you include us in the count.
>
> Danny
>
> On Tue, Apr 26, 2011 at 10:21 AM, Grig Gheorghiu
> <grig.gheorghiu at gmail.com> wrote:
> > Also, if anybody wants to present a 10-minute lightning talk, please
> > let me know. We only have 2 lightning talks scheduled so far and we
> > could definitely do with more. It doesn't even necessarily have to be
> > Python, it can be development- or testing- or devops- or
> > lifehacking-related.
> >
> > Thanks,
> >
> > Grig
> >
> > On Mon, Apr 25, 2011 at 3:18 PM, Grig Gheorghiu
> > <grig.gheorghiu at gmail.com> wrote:
> >> Just a reminder that we have a meeting scheduled for this Thursday
> >> 04/28 at 7 PM at the Evite office in West Hollywood. Please park in
> >> the parking structure of the Ticketmaster building at 8800 Sunset
> >> Blvd, entering from Palm Ave. Parking is free, just tell the parking
> >> attendant you're there for the Python meeting. We'll wait for you in
> >> the lobby (1st floor), then we'll go to a conference room.
> >>
> >> Agenda and Google map are on the wiki: http://socal-piggies.org/scp
> >>
> >> On Sat, Apr 23, 2011 at 9:39 AM, Vivek Shrivastava
> >> <vivshrivastava at gmail.com> wrote:
> >>> +1
> >>>
> >>> On Sat, Apr 23, 2011 at 9:36 AM, John Matthew <john at compunique.com>
> wrote:
> >>>>
> >>>> Me too please.
> >>>> John Matthew
> >>>>
> >>>> On Fri, Apr 22, 2011 at 8:36 PM, Russell Smith <savtech138 at gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Would you add me to the list attendees please?
> >>>>> Thanks!
> >>>>>
> >>>>> Russ
> >>>>>
> >>>>> On Thu, Apr 14, 2011 at 9:46 AM, Grig Gheorghiu
> >>>>> <grig.gheorghiu at gmail.com> wrote:
> >>>>>>
> >>>>>> Hello everybody,
> >>>>>>
> >>>>>> The Evite devops team is hosting our next meeting on Thu. April
> 28th.
> >>>>>> If anybody wants to present, please let me know. We already have 1
> >>>>>> presenter lined up, Steve Wedig from Lingospot. Here is his talk:
> >>>>>>
> >>>>>> =================
> >>>>>> Steve Wedig: "Python Tricks Used at Lingospot"
> >>>>>>
> >>>>>> Lingospot is a startup (founded in 2007), that licenses technology
> to
> >>>>>> online publishers such as USAToday, Forbes, Bloomberg, etc. Over the
> >>>>>> years, we've built up a decent sized Python codebase. Within that
> >>>>>> codebase, a few tricks stand out due to their simplicity (anyone
> could
> >>>>>> pick them up today), and their prevalence (they're used in almost
> >>>>>> every Python module). In this talk, we'll be presenting a few of
> these
> >>>>>> tricks & practices, along with their motivation.
> >>>>>> =================
> >>>>>>
> >>>>>> An idea we've had floating around for a while is to also do a series
> >>>>>> of lightning talks, let's say at 10 minutes each, where you would
> >>>>>> present a given Python tool/technique/trick/etc. If anybody wants to
> >>>>>> present something along these lines at the meeting, please let me
> >>>>>> know.
> >>>>>>
> >>>>>> Also please let me know if you are thinking of attending. We need a
> >>>>>> list to leave with the security guard downstairs. I'll send more
> >>>>>> detailed venue and parking instructions soon.
> >>>>>>
> >>>>>> Grig
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> socal-piggies mailing list
> >>>>>> socal-piggies at lists.idyll.org
> >>>>>> http://lists.idyll.org/listinfo/socal-piggies
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> socal-piggies mailing list
> >>>>> socal-piggies at lists.idyll.org
> >>>>> http://lists.idyll.org/listinfo/socal-piggies
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> socal-piggies mailing list
> >>>> socal-piggies at lists.idyll.org
> >>>> http://lists.idyll.org/listinfo/socal-piggies
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> socal-piggies mailing list
> >>> socal-piggies at lists.idyll.org
> >>> http://lists.idyll.org/listinfo/socal-piggies
> >>>
> >>>
> >>
> >
> > _______________________________________________
> > socal-piggies mailing list
> > socal-piggies at lists.idyll.org
> > http://lists.idyll.org/listinfo/socal-piggies
> >
>
>
>
> --
> 'Knowledge is Power'
> Daniel Greenfeld
> http://pydanny.com
> http://cartwheelweb.com
>
> _______________________________________________
> socal-piggies mailing list
> socal-piggies at lists.idyll.org
> http://lists.idyll.org/listinfo/socal-piggies
>
--
Steve Wedig
http://www.linkedin.com/in/wedig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/socal-piggies/attachments/20110429/b50a88ff/attachment.htm>
More information about the socal-piggies
mailing list