Python teacher notes, preparing for class...
My flight plan for sharing Python this evening, adult audience, real time in cyberspace, includes going backstage to survey the Python for Developers view. That will mean optionally cloning the Github site that's mainly a Sphinx HTML document about how to participate in Python's evolution. https://github.com/python/devguide (show how Sphinx works) I don't plan on actually compiling Python tonight, but we'll be right where one needs to be to learn how. Just looking at the issues tracker (first time) and PEPs (again) will inspire students with how well-oiled a machine is the Python "sausage making" factory. In my estimation, a well-rounded knowledge of Python includes understanding how to make one's own decorators and context managers. The following categories of type should also be made clear: * Mutable vs Immutable * Callable vs not * Collections: Sequences vs Mappings * Iterator vs Iterable * Generator as Iterator * Context Manager * Descriptor We recognize these types based on the assortment of "__ribs__" (special names) they contain e.g. callables have __call__, mutables support __setitem__, iterators have __next__, context managers __enter__ and __exit__, Descriptors __fget__, __fset__ and so on. We're like bird watcher with binoculars, identifying species based on these tell-tale characteristics (APIs). A grand synthesis involves using the @contextmanager decorator from contextlib to turn a generator into a context manager. That's a high point (summit) in my curriculum. The Descriptor concept works in tandem with decorator syntax to bring us the @property type. I use a "magic circle" type for properties, meaning you can set radius or circumference or area of a Circle, and the other two attributes reset automatically. I believe Raymond Hettinger uses the same approach. One of my most computer sciency types is the Permutation class, with many soft links to Group Theory. My P class randomly generates a dict with [a-z] plus space (' ') mapped to the same set, keys to values in a different order. I have voluminous writings on how one might use this class to explore elementary group theory on math-teach @ Math Forum, public archives, no longer open to new comments. https://repl.it/@kurner/Permutations http://mathforum.org/kb/message.jspa?messageID=10227508 https://github.com/4dsolutions/Python5/blob/master/Permutations.ipynb Kirby
On Monday, August 27, 2018, kirby urner <kirby.urner@gmail.com> wrote:
My flight plan for sharing Python this evening, adult audience, real time in cyberspace, includes going backstage to survey the Python for Developers view.
That will mean optionally cloning the Github site that's mainly a Sphinx HTML document about how to participate in Python's evolution.
https://github.com/python/devguide (show how Sphinx works)
ReadTheDocs might be a helpful segue from Sphinx and the devguide. https://github.com/rtfd/readthedocs-docker-images/blob/master/README.rst#usa... $ docker pull readthedocs/build:latest (Building a PDF with Sphinx requires installing a lot of LaTeX packages) https://github.com/yoloseem/awesome-sphinxdoc cookiecutter-pypackage has a good Sphinx template that extends the one generated by sphinx-quickstart with e.g. how to include README.rst in the Sphinx docs and the package long_description in setup.py (with cool badges) https://cookiecutter.readthedocs.io/en/latest/readme.html#available-cookiecu... https://packaging.python.org
I don't plan on actually compiling Python tonight, but we'll be right where one needs to be to learn how. Just looking at the issues tracker (first time) and PEPs (again) will inspire students with how well-oiled a machine is the Python "sausage making" factory.
In my estimation, a well-rounded knowledge of Python includes understanding how to make one's own decorators and context managers.
The following categories of type should also be made clear:
* Mutable vs Immutable * Callable vs not * Collections: Sequences vs Mappings * Iterator vs Iterable * Generator as Iterator * Context Manager * Descriptor
We recognize these types based on the assortment of "__ribs__" (special names) they contain e.g. callables have __call__, mutables support __setitem__, iterators have __next__, context managers __enter__ and __exit__, Descriptors __fget__, __fset__ and so on. We're like bird watcher with binoculars, identifying species based on these tell-tale characteristics (APIs.
This is the most unified reference on __dunder_methods__ ('magic methods') I've ever seen: "A Guide to Python's Magic Methods" https://rszalski.github.io/magicmethods/
A grand synthesis involves using the @contextmanager decorator from contextlib to turn a generator into a context manager. That's a high point (summit) in my curriculum.
The Descriptor concept works in tandem with decorator syntax to bring us the @property type. I use a "magic circle" type for properties, meaning you can set radius or circumference or area of a Circle, and the other two attributes reset automatically. I believe Raymond Hettinger uses the same approach.
ipywidgets (and IPython) are built atop traitlets (which are like properties with event handlers that are observable) https://ipywidgets.readthedocs.io/en/stable/examples/Widget%20Events.html#Tr...
Widget properties are IPython traitlets and traitlets are eventful. To handle changes, the observe method of the widget can be used to register a callback.
One of my most computer sciency types is the Permutation class, with many soft links to Group Theory. My P class randomly generates a dict with [a-z] plus space (' ') mapped to the same set, keys to values in a different order. I have voluminous writings on how one might use this class to explore elementary group theory on math-teach @ Math Forum, public archives, no longer open to new comments.
https://repl.it/@kurner/Permutations http://mathforum.org/kb/message.jspa?messageID=10227508 https://github.com/4dsolutions/Python5/blob/master/Permutations.ipynb
Kirby
This is the most unified reference on __dunder_methods__ ('magic methods') I've ever seen: "A Guide to Python's Magic Methods" https://rszalski.github.io/magicmethods/
I'd not seen that Guide to magic methods before. Thanks!
From perusing it, I was reminded of a topic Trey Hunner discussed in one of his recorded live chats:
When defining how your class implements ordering, e.g. using __lt__, __gt__, __eg__ and so on, it's sufficient to define just two of these, then decorate with @total_ordering to have Python fill in the blanks. I tested that out in my OrderingPolys.ipynb (Jupyter Notebook). Great! I'm keeping the demo. http://localhost:8889/notebooks/Documents/SAISOFT/SAISOFT/OrderingPolys.ipyn... This Notebook now includes a link back to Rafe's docs. I'll be sure my California students know about this update. We meet again tonight. I use geometry, polyhedrons in particular, as an excuse to introduce OOP from yet another angle (I take a multi-faceted approach). Kirby
I tested that out in my OrderingPolys.ipynb (Jupyter Notebook). Great! I'm keeping the demo.
http://localhost:8889/notebooks/Documents/SAISOFT/SAISOFT/OrderingPolys.ipyn...
https://github.com/4dsolutions/SAISOFT/blob/master/OrderingPolys.ipynb Sorry, my bad. I gave the local URL on my laptop vs the global one @ Github. Kirby
By default, the sorted function looks at the leftmost element of a tuple or other iterable, when sorting...
AFAIU, sorted() compares the whole object. https://docs.python.org/3/howto/sorting.html
l = [(3, 2), (3, 1), (1, 1, 2), (1, 1)] sorted(l) [(1, 1), (1, 1, 2), (3, 1), (3, 2)]
The way it reads, it seems like you're implying that sorted() does this:
l = [(3, 2), (3, 1), (1, 1, 2), (1, 1)] sorted(l, key=lambda x: x[0]) [(1, 1, 2), (1, 1), (3, 2), (3, 1)]
You'll find some excellent overview of the magic methods in this essay by Rafe Kettler: A Guide to Python's Magic Methods. He's mostly looking at Python 2.7, so does not pick up on the __next__ method, however you'll be able to fill in the blanks thanks to this course
This is unclear to me. What does the next() function do? How do I find the docs and source for it? These are misspelled:
comparitor compartor
These are great: - http://www.scipy-lectures.org/intro/language/python_language.html - http://nbviewer.jupyter.org/github/jrjohansson/scientific-python-lectures/bl... - Something about sorted with a link to the docs would be a good addition. IDK, I tend to find it much easier to just read the docs (and the source, if it's not clear). https://docs.python.org/3/library/functions.html#sorted https://docs.python.org/3/howto/sorting.html sorted() is a built-in function (as indicated by the TypeError thrown by inspect.getfile(sorted)); which are in bltinmodule.c: https://github.com/python/cpython/blob/master/Python/bltinmodule.c On Wednesday, August 29, 2018, kirby urner <kirby.urner@gmail.com> wrote:
I tested that out in my OrderingPolys.ipynb (Jupyter Notebook). Great! I'm keeping the demo.
http://localhost:8889/notebooks/Documents/SAISOFT/ SAISOFT/OrderingPolys.ipynb
https://github.com/4dsolutions/SAISOFT/blob/master/OrderingPolys.ipynb
Sorry, my bad. I gave the local URL on my laptop vs the global one @ Github.
Kirby
On Thu, Aug 30, 2018 at 3:02 AM Wes Turner <wes.turner@gmail.com> wrote:
By default, the sorted function looks at the leftmost element of a tuple or other iterable, when sorting...
You're right, my presentation is unclear. I'll fix it. The way it reads, it seems like you're implying that sorted() does this:
Yes, and that's wrong.
l = [(3, 2), (3, 1), (1, 1, 2), (1, 1)] sorted(l, key=lambda x: x[0]) [(1, 1, 2), (1, 1), (3, 2), (3, 1)]
You'll find some excellent overview of the magic methods in this essay by Rafe Kettler: A Guide to Python's Magic Methods. He's mostly looking at Python 2.7, so does not pick up on the __next__ method, however you'll be able to fill in the blanks thanks to this course
This is unclear to me. What does the next() function do? How do I find the docs and source for it?
next(obj) triggers obj.__next__() which in 2.7 is named next internally i.e. isn't magic. __next__ is the main driver of iterators e.g. for loops hit __next__ over and over as they loop over whatever. True, a list (iterable) doesn't have a __next__, but a for loop implicitly applies __iter__ (called by the iter function) which turns iterables into iterators.
These are misspelled:
comparitor compartor
Will fix next.
These are great: - http://www.scipy-lectures.org/intro/language/python_language.html - http://nbviewer.jupyter.org/github/jrjohansson/scientific-python-lectures/bl... - Something about sorted with a link to the docs would be a good addition.
Thanks. Yes, I'll add some links to the docs as you suggest. Great feedback! Actually as part of my class I'm showing them edu-sig and other python.org lists, so we were actually viewing this conversation. I'll extend that to showing your corrections, as I want to demonstrate how the Python community all teaches each other, is friendly and so on. Kirby
On Thursday, August 30, 2018, kirby urner <kirby.urner@gmail.com> wrote:
Thanks. Yes, I'll add some links to the docs as you suggest. Great feedback!
Glad to be helpful. I've trimmed out the text I'm not replying to and tried to use plaintext only in order to: make sure the thread stays below the 40K limit, and make it easy to reply inline without breaking HTML tags.
Actually as part of my class I'm showing them edu-sig and other python.org lists, so we were actually viewing this conversation. I'll extend that to showing your corrections, as I want to demonstrate how the Python community all teaches each other, is friendly and so on.
Code review with pull requests / merge requests and GitHub, Gerrit, GitLab etc is an essential skill. Src: https://github.com/jupyter/nbdime Docs: https://nbdime.readthedocs.io/
nbdime provides tools for diffing and merging of Jupyter Notebooks.
There are a number of real-time collaborative platforms for working with notebooks (CoCalc, Colab, ) https://hypothes.is highlights and annotations work on anything with a URL, are threaded, and support Markdown.
Kirby
Mailing list tips and tricks, PEPs, Write the Docs Since you asked, although this isn't in scope of the original subject line, and since I'd like to just continue this thread instead of breaking the thread by changing the subject line, and since this isn't technically OT (off-topic) in the interest of conversing toward an objective, here I've added a first-line summary of this message. I should probably change the subject and start a new thread. You can search mailing lists in a number of ways: - Google search with "site:mail.python.org" and/or "inurl:" queries https://www.google.com/search?q=site%3Amail.python.org (inurl doesn't match mm3-migrated lists too) - Google Groups, if the list is set up there too - Gmail "list:python.org" queries - This doesn't find messages that you didn't receive because you weren't subscribed yet. - "from:list@mail.python.org" queries - This doesn't find messages that you didn't receive because you weren't subscribed yet. - Markmail "list:org.python.edu-sig" queries https://markmail.org/search/?q=list%3Aorg.python https://markmail.org/search/?q=list%3Aorg.python.edu-sig The Python mailing lists aren't yet all upgraded to mailman 3 (/mm3/ URLs); so some lists have the classic mailman archive interface (where "by thread" breaks at the month boundary, for example) and upgraded lists have the new Django-based HyperKitty interface with e.g. search and a full thread view. With mm3, it's also possible to reply to threads you didn't receive because you weren't subscribed at the time. e.g. -- for example i.e. -- that is (List of acronyms OTOH/OTOMH) Reply-all is unnecessary, but often helpful. If you just click reply, it may be addressed off-list to only the sender (and not the list email address, which is what you want if you want the mailing list app to archive for and relay the message to every subscriber). If that happens, you (or the recipient) can forward the message to the list, but it'll be unnecessarily quote-indented unless you just copy and paste (which can be lossy with HTML quote indents inferred from plaintext-quoted lines that start with '>'), so it pays to verify the to: field before you start composing a message. Some old hands argue for like 72 character fixed width messages so that when they're n-levels quote-indented, they still fit on an 80 character terminal without rewrapping. Old-school email clients like mutt, for example, can handle this; though, on a phone, fixed width hard-broken lines wrap like this sometimes; which is not as easy to read. TL;DR (too long; didn't read) is an acronym of Reddit; though the standard form of intro summary, body, conclusion summary is equally helpful for long-form mailing list posts. Many email clients show the first part of the first line of the message after the overly-long narrowly descriptive subject line that doesn't actually describe the scope of the discussion anymore. For Python features, the ultimate objective is to write or develop a PEP. There is a PEP template here: https://www.python.org/dev/peps/pep-0012/ https://github.com/python/peps/blob/master/pep-0012.rst PEP 1 explains PEPs: "PEP 1 -- PEP Purpose and Guidelines" https://www.python.org/dev/peps/pep-0001/ https://github.com/python/peps/blob/master/pep-0001.txt PEPs must be justified (as indicated by the Rationale heading in the PEP template); so starting with a justification is a good approach to arguing that you need the whole list's time before you spend your precious time writing an actual PEP like actual contributors do sometimes (when they're getting actual work done). Bug and issue discussions are for the issue tracker (Roundup), though sometimes it's a really good idea to ask a list for help and feedback. Mailing lists don't support ReStructuredText, but docs, docstrings, and PEPs do; so it's perfectly reasonable -- even advisable, though not at all strictly necessary -- to format mailing list messages that would be helpful for those purposes in reStructuredText from the start. By the time you've added RST setext headings, you might as well be collaboratively drafting a PEP. Though it doesn't happen nearly frequently enough, it's often really helpful to update the docs with wisdom culled from the mailing lists (and Q&A sites which have labels). "6. Helping with Documentation¶" https://devguide.python.org/docquality/ "7. Documenting Python¶" https://devguide.python.org/documenting/ The ultimate source of Python documentation (an often-cited strength of Python as a language choice): https://github.com/python/cpython/tree/master/Doc "16. Accepting Pull Requests¶" https://devguide.python.org/committing/ On Thursday, August 30, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Thursday, August 30, 2018, kirby urner <kirby.urner@gmail.com> wrote:
Thanks. Yes, I'll add some links to the docs as you suggest. Great feedback!
Glad to be helpful.
I've trimmed out the text I'm not replying to and tried to use plaintext only in order to: make sure the thread stays below the 40K limit, and make it easy to reply inline without breaking HTML tags.
Actually as part of my class I'm showing them edu-sig and other python.org lists, so we were actually viewing this conversation. I'll extend that to showing your corrections, as I want to demonstrate how the Python community all teaches each other, is friendly and so on.
Code review with pull requests / merge requests and GitHub, Gerrit, GitLab etc is an essential skill.
Src: https://github.com/jupyter/nbdime Docs: https://nbdime.readthedocs.io/
nbdime provides tools for diffing and merging of Jupyter Notebooks.
There are a number of real-time collaborative platforms for working with notebooks (CoCalc, Colab, )
https://hypothes.is highlights and annotations work on anything with a URL, are threaded, and support Markdown.
Kirby
participants (2)
-
kirby urner -
Wes Turner