[Python-ideas] Optional static typing -- the crossroads

[Bill Winslow]

As a lurker who barely reads this list at all, let me just add here that
many of the typing-related questions that the BDFL presented as follow-up
are, in my opinion, questions worth asking even outside of the annotation
issue.

(Mini wall of text incoming:)

What I mean is, one of my grievances with Python is that the type hierarchy
is poorly defined and difficult to use, in that the "types" presented in
collections.abc in no way whatsoever interact with the builtins, and
considering how many library and user types inherit from those ABCs (as is
the purpose of those ABCs), it seems to me like a rather serious issue with
using the type system.

Consider the following:


>>> from collections import abc as types
>>> isinstance(dict, types.Mapping)
False
>>> isinstance(types.Mapping, dict)
False
>>> isinstance(list, types.MutableSequence)
False
>>> isinstance(types.MutableSequence, list)
False
>>> isinstance(list, types.Sized)
False


Furthermore:


>>> class DictThing(types.MutableMapping): pass #Easier to subclass
...
>>> isinstance(DictThing, dict)
False
>>> class DicterThing(dict): pass # Simpler
...
>>> isinstance(DicterThing, types.MutableMapping)
False


And finally:


>>> from collections import defaultdict
>>> isinstance(defaultdict, dict)
False
>>> isinstance(defaultdict, types.MutableMapping)
False


My conclusion is that to make lint-sort type-checkers worth their salt, the
Python type hierarchy needs to be fixed and properly integrated. There is
currently no obvious way to check if an object either is a list or behaves
like a list (the duck typing philosophy equates the two). (The current
shortest way is "isinstance(myvar, (list, types.MutableSequence)", but
that's not very obvious or Pythonic IMO.)

Before now I haven't bothered to put my thoughts to words, but this is
pretty decent motivation.

---------------------------------------------------------------------------

If people agree with my conclusion, then the ideal solution would be to
somehow merge the builtin types and the collections.abc types into one
single hierarchy, one single isinstance check, but that's probably
impossible.

The next thing would be to make one hierarchy the appropriate subclasses of
the other hierarchy, but either of those solutions has its own problems.
There're probably better solutions out there.



--Bill

On Fri, Aug 15, 2014 at 4:48 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 15 August 2014 19:38, Terry Reedy <tjreedy at udel.edu> wrote:
> > On 8/15/2014 12:40 AM, Nick Coghlan wrote:
> >>
> >> On 15 August 2014 09:56, Guido van Rossum <guido at python.org> wrote:
> >>>
> >>>
> >>> I don't buy the argument that PEP 3107 promises that annotations are
> >>> completely free of inherent semantics.
> >>
> >>
> >> It's also worth noting the corresponding bullet point in PEP 3100
> >> (under http://www.python.org/dev/peps/pep-3100/#core-language):
> >>
> >> * Add optional declarations for static typing [45] [10] [done]
> >
> > ...
> >
> >> Linters/checkers may also want to provide a configurable way to say
> >> "the presence of decorator <X> means the annotations on that function
> >> aren't type markers". That ties in with the recommendation we added to
> >> PEP 8 a while back: "It is recommended that third party experiments
> >> with annotations use an associated decorator to indicate how the
> >> annotation should be interpreted."
> >
> >
> > Depending on the checker, this suggests that non-type-check annotations
> need
> > not be deprecated. If a decorator wraps a function with an unannotated
> > wrapper, then the checker should see the result as unannotated, rather
> than
> > looking for a wrapped attribute. Also, a decorator can remove non-type
> > annotations and act on them, store them in a closure variable, or store
> them
> > on the function in a different name.
>
> No, many (most?) linters and IDEs will run off the AST without
> actually executing the code, so they'll see the annotations, even if
> they get stripped by the decorator at runtime.
>
> Cheers,
> Nick.
>
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140815/4ada1de6/attachment.html>