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

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://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