[Edu-sig] edu-sig in Pythonia

[DeanG]

+1

Regarding the  Args Kwargs, Matt Harrisons "Guide to: Learning Python
Decorators" was a great read for this topic.
http://www.amazon.com/Guide-Learning-Python-Decorators-ebook/dp/B006ZHJSIM


On Mon, Apr 2, 2012 at 11:52 AM, kirby urner <kirby.urner at gmail.com> wrote:
>
> A few of us at Pycon were nodding heads (+1ing)
> over the idea that our subculture / ethnicity could
> evolve these "canned talks" that different people
> deliver in their personalized style.  More than that,
> they demonstrate new "teaching techniques" such
> that the audience might appreciate how advances
> in pedagogy -- and in andragogy -- still occur.
>
> Consider the O'Reilly 'Head First Into...' series.
> Like 'for Dummies', it explains up front that there's
> psychology at work, smart cookies have baked a
> new mix of graphic art, sound bites, who knows
> what's coming, and you, the reader / student are
> in for a treat.  But then books, like videos, are a
> somewhat passive medium.  Once you jump on
> that gym equipment, that treadmill, that weight
> pump, you know there's more to the educational
> experience than having your butt in a chair.
>
> Among the canned topics would be ArgsKwargs.
> Everyone learning Python needs to keep spiraling
> through the ArgsKwargs literature, wherein we do
> what in other languages might be called gathering
> and scattering.  The star and double star, which
> C-language readers are used to seeing anyway
> in function headers etc., have become scavengers,
> accepting / liberal "all may pass" type guards at the
> gate (function entrance), and yet still there are rules
> (positionals before keyword).  Used when passing
> arguments, the star and double-star are "exploders"
> (scatterers), setting free their tuples and dicts to
> mingle as individuals.
>
>>>> def baby(skin="soft", noise_might_be = "crying", **blahblah):
>     print ("Hey baby, I notice the {} skin, and the {} noise you're
> making".format(skin, noise_might_be))
>     print(blahblah)
>
>
>>>> random_keys = {"safe":"12-15-44", "skin":"purple", "tomorrow":"wash
>>>> car"}
>>>> baby(**random_keys)
> Hey baby, I notice the purple skin, and the crying noise you're making
> {'safe': '12-15-44', 'tomorrow': 'wash car'}
>
> Another canned talk -- could be lightning format --
> is IterStuff, beginning with the difference between
> an iterator and an iterable, climbing through
> generators (with plenty of send use) to iterator
> defining classes, to itertools more generally, and
> a discussion of "just in time" versus pre-stocking
> memory with impossibly huge inventories.
>
> Here I'd suggest a lore-based approach wherein
> we go over how Python itself has become ever more
> fascinated with iterators.  How is it that a range class
> object is a sequence (indexable) whereas the
> dict_items object is not (not indexable)?
>
>>>> dict(a=1,b=2).items()[0]
> Traceback (most recent call last):
>   File "<pyshell#0>", line 1, in <module>
>     dict(a=1,b=2).items()[0]
> TypeError: 'dict_items' object does not support indexing
>>>> range(2)[0]
> 0
>
> Then there'd be the protocol talks i.e. lets talk about
> interfaces in the abstract.  The iterator is our first example,
> in being about having __iter__ and __next__.  Then
> comes the descriptor and its interface / protocol.
>
> The point being:  we should always have these talks.
>
> There will always be people new to Python (in this
> model), or people wanting a refresher and (here's
> the kicker) people needing practice in their teaching
> techniques in front of an audience that's already very
> much in the ballpark (already at a Pycon, not just
> casually dropping by to see what this might be about).
>
> Also:  the people most interested in teaching Python,
> such as here on edu-sig, should be most involved in
> organizing this track.
>
> The track of standard topics, things we all need to
> know -- but how best to share?  That track and that
> question are one of our angles / self-chosen
> responsibilities, along with the poster session.
>
> I would extend this philosophy to say edu-sig types
> should also take some 3rd party modules under their
> collective wing, by which I mean to include such worthies
> as:  Visual Python, I-Python, matplotlib, numpy, Blender
> and web frameworks (including Google App Engine).
>
> OK, now that's starting to sound like a complete Pycon,
> not just a track.  Fair enough.
>
> The edu-sig "base" is around a track of core topics.
> Then each topic is conceived to "branch off" into
> various "worlds" or "namespaces".  E.g the IterStuff
> branches off into Twisted and asynchronous techniques
> such as David Beazely has specialized in inventing and
> teaching.  We'd need more diagrams, roadmaps, to
> show the "lay of the land" (Pythonia).  Seeing it one
> way doesn't preclude also seeing it in other ways too.
>
> Kirby
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>