[Edu-sig] Permutations with Python

[kirby urner]

On Wed, Nov 18, 2015 at 2:59 PM, kirby urner <kirby.urner at gmail.com> wrote:

<< SNIP >>

>
> I'm currently teaching a course in Python for the State of California.  My
> adult students join me in real time for 10 four hour segments.  I've just
> completed my fourth.  We're coding classes (types) already, were looking at
> simple class constructs from Day One.  I've suggested they adopt the
> mindset of a future high school student, privileged to have a real REPL.
>
>
My pedagogy / andragogy is much influenced by my since-2011 use of Steve
Holden's four part Python series.  He introduces unittesting by the very
start of the second course i.e. right after the basic basics (up through
writing a first class, along with significant string manipulation).

I think that's productive, as it gives flavor and context to not just the
importance of unittests, but the philosophy known as Agile and its various
tenants such as:

(1) no ownership of code
(2) release early / often
(3) TDD or test-driven development as a way of making these early-often
micro-steps.

Write the tests first, as a way of giving your day traction.  You end up
with a pile of audits.  That can be worth a lot when it comes to guarding
against corrupting code.

Given I get to yak for literally hours, you can bet I was persuasive. :-D
Although my focus is core Python out to some standard library, some talk of
3rd party is encouraged (we're using Anaconda after all).  Plus I'm eager
to reach out to that anchoring context (of developing according to some
established best practices).  Using a language, like using a musical
instrument, needs to be embedded in its larger context.

I know Steve, a veteran coder, is not unique in stressing TDD.  Just
letting students know of these ramified schools of thought...  whole
workflows, practices, such as SCRUM.

I've put my own spin on some of this e.g. around (1) "no ownership of code"
I talk a lot about learning to play chess against yourself.

It's when you have that ability to "turn on yourself" now suddenly white's
worst enemy in a good way (ideal sparring partner) that you demonstrate
your ability to "let go and play for the other side" (the testers are like
the skeptics, with the developers the earnest dreamers striving to best
more tests (the athletes, the stars -- as a solo coder, your mindset goes
back and forth, whereas in a bigger company, these may be different teams
(that's what I tell my students)).

Anyway, my previous post included what I introduce as "raw" or "naive"
tests appended to the module itself.  We learn that it's better to split
off the testing code, but you'll notice the unit tests are pointedly
probing the same features.   Two ways of saying the same thing.

Kirby


# -*- coding: utf-8 -*-
"""
Created on Thu Nov 19 10:48:49 2015

@author: kurner
"""

import unittest
from px_class import P

class Test_Permutation(unittest.TestCase):

    def test_1(self):
        """
        any p * ~p should give Identity
        """
        p = P() # identity permutation
        new_p = p.shuffle()
        inv_p = ~new_p
        self.assertEqual(p, inv_p * new_p, "expected identity fails")

    def test_2(self):
        """
        encrypt and decrypt are inverse operations on string
        """
        p = P().shuffle() # arbitrary permutation
        s = "the rain in spain stays mainly in the plain"
        c = p.encrypt(s)
        self.assertEqual(p.decrypt(c), s, "decrypted phrase differs")

if __name__ == "__main__":
    unittest.main()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20151120/864c1d7d/attachment.html>