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