On Fri, Jun 8, 2018 at 10:47 PM Wes Turner <wes.tur...@gmail.com> wrote:
> Python parameter and return type hints are expressed as function > annotations which import and derive types from the typing module and the > typeshed. > > - PEP 3107 -- Function Annotations > https://www.python.org/dev/peps/pep-3107/ > > - PEP 0484 -- Type Hints > https://www.python.org/dev/peps/pep-0484/ > > - https://www.python.org/dev/peps/pep-0484/#function-method-overloading > - https://www.python.org/dev/peps/pep-0484/#the-typing-module > - > https://docs.python.org/3/library/typing.html#classes-functions-and-decorators > > - https://docs.python.org/3/tutorial/controlflow.html#function-annotations > > - from typing import List, MutableMapping, Hashable, Iterable, > AsyncGenerator > > https://docs.python.org/3/library/typing.html#classes-functions-and-decorators > > - https://github.com/python/typeshed > - https://github.com/python/typeshed/tree/master/third_party/2and3 > > - FunctionType, CodeType, > MappingProxyType, SimpleNamespace, > GeneratorType, AsyncGeneratorType, > CoroutineType, > MethodType, BuiltinFunctionType, > TracebackType, FrameType > https://github.com/python/typeshed/blob/master/stdlib/3/types.pyi#L25 > https://github.com/python/typeshed/blob/master/stdlib/3/inspect.pyi > > > > On Fri, Jun 8, 2018 at 6:37 PM kirby urner <kirby.ur...@gmail.com> wrote: > >> >> 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! >> > > sys.getrefcount(None) > > >> >> 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. >> > https://docs.python.org/3/library/copy.html > > https://github.com/python/cpython/blob/master/Lib/copy.py > - copy() > - deepcopy() > > https://github.com/python/cpython/blob/master/Objects/dictobject.c#L2520 > - PyDict_copy > > https://docs.python.org/3/library/pprint.html#pprint.PrettyPrinter > - pprint(depth=n) > a, b = [1,], [2,] > a.append(a) > pprint.pprint(a) > pprint.pprint(a, depth=1) > > > "Why are these methods faster?" > - https://pandas.pydata.org/pandas-docs/stable/enhancingperf.html > - https://ray.readthedocs.io/en/latest/pandas_on_ray.html > - https://github.com/alex/zero_buffer/blob/master/zero_buffer.py > >> >> When is it a copy, when a view? is a discussion in pandas as well. >> > - https://github.com/apache/arrow > - https://arrow.apache.org/ > - 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))))) ) >> > > From > https://medium.com/@westurner/the-fn-py-fn-monad-optionable-f11ceefb567b > : > "The fn.py fn.monad.optionable decorator — @optionable — makes > functional composition with chaining easy, too: > https://github.com/kachayev/fn.py/blob/master/README.rst#functional-style-for-error-handling > " > > >> >> 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)? > > > >> >> [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 >> >
_______________________________________________ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
