- copy()
- deepcopy()
- PyDict_copy
- pprint(depth=n)
a, b = [1,], [2,]
a.append(a)
pprint.pprint(a)
pprint.pprint(a, depth=1)
"Why are these methods faster?"
When is it a copy, when a view? is a discussion in pandas as well.
- zero-copy streaming data
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".
class A(): pass
def func(): print(1)
A.__dict__['func'] = func
a = ()
a.__dict__['here'] = func
a.__class__.__dict__['func2'] = func
b = A()
assert hasattr(b, 'here') == False
assert hasattr(a, 'func') == True
assert hasattr(a, 'func2') == True
# isinstance / MRO
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.
Is a generator a callable?
===
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.
Is there anything to do runtime type checking from annotations (just like pycontracts; maybe even with the additional constraints language)?
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
https://mail.python.org/mailman/listinfo/edu-sig