Re: another perennial topic... callable functions versus types

On Fri, Jun 8, 2018 at 10:47 PM Wes Turner <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> https://mail.python.org/mailman/listinfo/edu-sig
>>
>

_______________________________________________
Edu-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/edu-sig