I enjoyed our discussion of post-its versus buckets, or not versus:
objects in memory take up space, and so are bucket-like, but look how many
labels (post-its) some of them have!
I find it useful to have memory take shape as something finite, even when
we're enjoying more of it on contemporary devices. Python is biased
against making gratuitous copies, or against copying gratuitously, we maybe
could say.
Memory is respected. L.sort() is "in place" whereas sorted(L) leaves L
untouched. This "inplace" idea carries forward as a keyword argument
(named parameter) in many cases.
I confess, in my own courses, I could do more with deepcopy, explaining
what it is and how to do it. I'll get on it.
When is it a copy, when a view? is a discussion in pandas as well.
Another topic:
Another pair of categories I like to tease apart are function versus type,
when it comes to what's a callable.
range() used to be a function that returned a list. Now it returns an
instance of the range type, a sequence. More like dict(), int() and so
on. Not like hex().
enumerate() and zip() are likewise calls to classes, triggers to __init__s
(birth methods). We're asking for instances. We're calling types.
Functions return objects too, so one should not say the difference is
whether they return objects. Both do.
The difference is instances of a type live on with the methods of that
type, whereas a function does not directly bequeath its methods to any
"children".
Functions are factories of other than instances of themselves, even if they
return other functions.
What nuances this view is that FunctionType is a type of object, so calling
a function is calling a type.
However, the way a function responds to being called is like an instance
does when its type has a __call__ method defined.
===
One of my favorite ways to connect classes and functions is to show how a
class might "eat" a function such that the function remains callable, and
yet the instances may also multiply, in which case the functions compose to
create other functions:
@Composable # class
def F(x):
return x + 2
@Composable # class
def G(x):
return 2 * x
H = F * F * F * G * G
(H is now a "pipeline" of F(F(F(G(G(x))))) )
More on REPL.it:
https://repl.it/@kurner/Composing-Functions
(red X warning flag next to lambda expression is bogus, runs fine, Spyder
is smarter)
Kirby
PS: this morning I saw Guido's talk at Stanford on type annotations, which
he recently tweeted about [1]. I definitely include mentioning to be on
the lookout for such syntax going forward, and not being thrown by it. I
emphasize that standard core Python sees annotations more as a type of
documentation, with 3rd party hooks understanding them more as directives.
[1]
https://twitter.com/gvanrossum/status/1003792557652914177
(June 4)
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
https://mail.python.org/mailman/listinfo/edu-sig
