Mailman 3 March 2017 - Python-Dev

PyCharm debugger became 40x faster on Python 3.6 thanks to PEP 523
by Victor Stinner March 28, 2017

March 28, 2017

https://blog.jetbrains.com/pycharm/2017/03/inside-the-debugger-interview-wi… "What changed in Python 3.6 to allow this? The new frame evaluation API was introduced to CPython in PEP 523 and it allows to specify a per-interpreter function pointer to handle the evaluation of frames." Nice! Victor

5 5

Not all public names in C API have the "Py" prefix
by Serhiy Storchaka March 28, 2017

March 28, 2017

A number of public typedef names without the "Py" prefix survived the Grand Renaming [1]. A couple of new names without the "Py" prefix were added after the Grand Renaming (e.g. getter and setter [2]). That names were included in the Stable ABI. The long list of such names can be found in PEP 384 [3]: unaryfunc binaryfunc ternaryfunc inquiry lenfunc ssizeargfunc ssizessizeargfunc ssizeobjargproc ssizessizeobjargproc objobjargproc objobjproc visitproc traverseproc destructor getattrfunc getattrofunc setattrfunc setattrofunc reprfunc hashfunc richcmpfunc getiterfunc iternextfunc descrgetfunc descrsetfunc initproc newfunc allocfunc getter setter And I suppose new names were added since Python 3.2. A couple of underscored name without the "_Py" prefix (e.g. _object, _typeobject) are defined when include "Python.h". Should we to do something with this? Maybe add Py-prefixed aliases and temporary keep old names for compatibility (but allow to hide them if define a special macro)? [1] https://python-history.blogspot.com/2009/03/great-or-grand-renaming.html [2] https://github.com/python/cpython/commit/6d6c1a35e08b95a83dbe47dbd9e6474daf… [3] https://www.python.org/dev/peps/pep-0384/

3 3

Signups for 2017 Python Language Summit are now open
by Larry Hastings March 27, 2017

March 27, 2017

(reposting, cc'ing python-dev) It’s that time again: time to start thinking about the Python Language Summit! The 2017 summit will be held on Wednesday, May 17, from 10am to 4pm, at the Oregon Convention Center in Portland, Oregon, USA. Your befezzled hosts Larry and Barry will once again be at the helm. The summit’s purpose is to disseminate information and spark conversation among core Python developers. It’s our yearly opportunity to get together for an in-person discussion, to review interesting developments of the previous year and hash out where we’re going next. And we have lots to talk about! Since our last summit, Python 3.6 was released, and the main CPython development process has been moved to GitHub. Naturally Python 3.7 development continues apace. Speaking of changes, we’re continuing to evolve the summit. Everyone seemed to like the lightning talks, so we’ll keep those. Everyone seemed to hate us keeping the schedule secret -sorry!- so we’ll make that available beforehand, with the understanding that it’ll be fluid as the day progresses. Due to room size limitations and the yearly increase in participation, we’re limiting summit invitations to just core developers and invited speakers. As usual, we’ll have whiteboards and a projector. But this year we’re adding roaming microphones, so everybody in the room will be able to hear your question! With the help of the ever awesome Ewa, this year we’ll have badge ribbons for Language Summit participants, which we’ll hand out at the summit room in the morning. As with last year, we’re using Google Forms to collect signups. The form will let you request an invitation to the summit and optionally propose a talk. Signups are open now, and will remain open until Wednesday April 12th, 2017. You can find the link to the signup form from the summit’s official web page, here: https://us.pycon.org/2017/events/language-summit/ But never forget: you don’t need to be registered for PyCon in order to attend the summit! One final note. We’re re-inviting Jake Edge from Linux Weekly News to attend the summit and provide press coverage. Jake’s done a phenomenal job of covering the previous two years’ summits, providing valuable information not just for summit attendees, but also for the Python community at large. Jake’s coverage goes a long way toward demystifying the summit, while remaining respectful of confidential information that’s deemed “off the record” ahead of time by participants. We hope to see you at the summit! [BL]arry

1 0

Summary of Python tracker Issues
by Python tracker March 24, 2017

March 24, 2017

ACTIVITY SUMMARY (2017-03-17 - 2017-03-24) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 5860 (+19) closed 35792 (+40) total 41652 (+59) Open issues with patches: 2431 Issues opened (40) ================== #29838: Check that sq_length and mq_length return non-negative result http://bugs.python.org/issue29838 opened by serhiy.storchaka #29839: Avoid raising OverflowError in len() when __len__() returns ne http://bugs.python.org/issue29839 opened by serhiy.storchaka #29840: Avoid raising OverflowError in bool() http://bugs.python.org/issue29840 opened by serhiy.storchaka #29841: errors raised by bytes and bytearray constructors for invalid http://bugs.python.org/issue29841 opened by Oren Milman #29842: Make Executor.map work with infinite/large inputs correctly http://bugs.python.org/issue29842 opened by josh.r #29843: errors raised by ctypes.Array for invalid _length_ attribute http://bugs.python.org/issue29843 opened by Oren Milman #29844: Windows Python installers not installing DLL to System32/SysWO http://bugs.python.org/issue29844 opened by TBBle #29846: ImportError: Symbol not found: __PyCodecInfo_GetIncrementalDec http://bugs.python.org/issue29846 opened by ajstewart #29847: Path takes and ignores **kwargs http://bugs.python.org/issue29847 opened by Jelle Zijlstra #29851: Have importlib.reload() raise ImportError when a spec can't be http://bugs.python.org/issue29851 opened by Richard Cooper #29852: Argument Clinic: add common converter to Py_ssize_t that accep http://bugs.python.org/issue29852 opened by serhiy.storchaka #29854: Segfault when readline history is more then 2 * history size http://bugs.python.org/issue29854 opened by nirs #29857: Provide `sys.executable_argv` for host application's command l http://bugs.python.org/issue29857 opened by ncoghlan #29858: inspect.signature includes bound argument for wrappers around http://bugs.python.org/issue29858 opened by anton-ryzhov #29860: smtplib.py doesn't capitalize EHLO. http://bugs.python.org/issue29860 opened by Lord Anton Hvornum #29862: Fix grammar typo in importlib.reload() exception http://bugs.python.org/issue29862 opened by brett.cannon #29863: Add a COMPACT constant to the json module http://bugs.python.org/issue29863 opened by brett.cannon #29867: Add asserts in PyXXX_GET_SIZE macros http://bugs.python.org/issue29867 opened by serhiy.storchaka #29868: multiprocessing.dummy missing cpu_count http://bugs.python.org/issue29868 opened by johnwiseman #29869: Underscores in numeric literals not supported in lib2to3. http://bugs.python.org/issue29869 opened by nevsan #29870: ssl socket leak http://bugs.python.org/issue29870 opened by thehesiod #29871: Enable optimized locks on Windows http://bugs.python.org/issue29871 opened by josh.r #29877: compileall hangs when accessing urandom even if number of work http://bugs.python.org/issue29877 opened by virtuald #29878: Add global instances of int 0 and 1 http://bugs.python.org/issue29878 opened by serhiy.storchaka #29879: typing.Text not available in python 3.5.1 http://bugs.python.org/issue29879 opened by Charles Bouchard-Légaré #29881: Add a new private API clear private variables, which are initi http://bugs.python.org/issue29881 opened by haypo #29882: Add an efficient popcount method for integers http://bugs.python.org/issue29882 opened by niklasf #29883: asyncio: Windows Proactor Event Loop UDP Support http://bugs.python.org/issue29883 opened by Adam Meily #29885: Allow GMT timezones to be used in datetime. http://bugs.python.org/issue29885 opened by Decorater #29886: links between binascii.{un,}hexlify / bytes.{,to}hex http://bugs.python.org/issue29886 opened by chrysn #29887: test_normalization doesn't work http://bugs.python.org/issue29887 opened by serhiy.storchaka #29888: The link referring to "Python download page" is broken http://bugs.python.org/issue29888 opened by cocoatomo #29889: test_asyncio fails always http://bugs.python.org/issue29889 opened by Thomas Knox #29890: Constructor of ipaddress.IPv*Interface does not follow documen http://bugs.python.org/issue29890 opened by Ilya.Kulakov #29891: urllib.request.Request accepts but doesn't check bytes headers http://bugs.python.org/issue29891 opened by ezio.melotti #29892: change statement for open() is splited into two part in middle http://bugs.python.org/issue29892 opened by OSAMU.NAKAMURA #29893: create_subprocess_exec doc doesn't match software http://bugs.python.org/issue29893 opened by Torrin Jones #29894: Deprecate returning a subclass of complex from __complex__ http://bugs.python.org/issue29894 opened by serhiy.storchaka #29895: Distutils blows up with an incorrect pypirc, should be caught http://bugs.python.org/issue29895 opened by Tommy Carpenter #29896: ElementTree.fromstring raises undocumented UnicodeError http://bugs.python.org/issue29896 opened by vfaronov Most recent 15 issues with no replies (15) ========================================== #29896: ElementTree.fromstring raises undocumented UnicodeError http://bugs.python.org/issue29896 #29895: Distutils blows up with an incorrect pypirc, should be caught http://bugs.python.org/issue29895 #29894: Deprecate returning a subclass of complex from __complex__ http://bugs.python.org/issue29894 #29893: create_subprocess_exec doc doesn't match software http://bugs.python.org/issue29893 #29891: urllib.request.Request accepts but doesn't check bytes headers http://bugs.python.org/issue29891 #29888: The link referring to "Python download page" is broken http://bugs.python.org/issue29888 #29887: test_normalization doesn't work http://bugs.python.org/issue29887 #29886: links between binascii.{un,}hexlify / bytes.{,to}hex http://bugs.python.org/issue29886 #29883: asyncio: Windows Proactor Event Loop UDP Support http://bugs.python.org/issue29883 #29877: compileall hangs when accessing urandom even if number of work http://bugs.python.org/issue29877 #29868: multiprocessing.dummy missing cpu_count http://bugs.python.org/issue29868 #29852: Argument Clinic: add common converter to Py_ssize_t that accep http://bugs.python.org/issue29852 #29840: Avoid raising OverflowError in bool() http://bugs.python.org/issue29840 #29838: Check that sq_length and mq_length return non-negative result http://bugs.python.org/issue29838 #29818: Py_SetStandardStreamEncoding leads to a memory error in debug http://bugs.python.org/issue29818 Most recent 15 issues waiting for review (15) ============================================= #29894: Deprecate returning a subclass of complex from __complex__ http://bugs.python.org/issue29894 #29892: change statement for open() is splited into two part in middle http://bugs.python.org/issue29892 #29878: Add global instances of int 0 and 1 http://bugs.python.org/issue29878 #29869: Underscores in numeric literals not supported in lib2to3. http://bugs.python.org/issue29869 #29867: Add asserts in PyXXX_GET_SIZE macros http://bugs.python.org/issue29867 #29858: inspect.signature includes bound argument for wrappers around http://bugs.python.org/issue29858 #29854: Segfault when readline history is more then 2 * history size http://bugs.python.org/issue29854 #29852: Argument Clinic: add common converter to Py_ssize_t that accep http://bugs.python.org/issue29852 #29843: errors raised by ctypes.Array for invalid _length_ attribute http://bugs.python.org/issue29843 #29840: Avoid raising OverflowError in bool() http://bugs.python.org/issue29840 #29839: Avoid raising OverflowError in len() when __len__() returns ne http://bugs.python.org/issue29839 #29838: Check that sq_length and mq_length return non-negative result http://bugs.python.org/issue29838 #29822: inspect.isabstract does not work on abstract base classes duri http://bugs.python.org/issue29822 #29816: Get rid of C limitation for shift count in right shift http://bugs.python.org/issue29816 #29803: Remove some redandunt ops in unicodeobject.c http://bugs.python.org/issue29803 Top 10 most discussed issues (10) ================================= #29881: Add a new private API clear private variables, which are initi http://bugs.python.org/issue29881 21 msgs #21895: signal.pause() and signal handlers don't react to SIGCHLD in n http://bugs.python.org/issue21895 14 msgs #29857: Provide `sys.executable_argv` for host application's command l http://bugs.python.org/issue29857 12 msgs #15988: Inconsistency in overflow error messages of integer argument http://bugs.python.org/issue15988 9 msgs #29843: errors raised by ctypes.Array for invalid _length_ attribute http://bugs.python.org/issue29843 8 msgs #29846: ImportError: Symbol not found: __PyCodecInfo_GetIncrementalDec http://bugs.python.org/issue29846 8 msgs #29847: Path takes and ignores **kwargs http://bugs.python.org/issue29847 7 msgs #29844: Windows Python installers not installing DLL to System32/SysWO http://bugs.python.org/issue29844 6 msgs #29863: Add a COMPACT constant to the json module http://bugs.python.org/issue29863 6 msgs #29869: Underscores in numeric literals not supported in lib2to3. http://bugs.python.org/issue29869 6 msgs Issues closed (39) ================== #8256: input() doesn't catch _PyUnicode_AsString() exception; io.Stri http://bugs.python.org/issue8256 closed by serhiy.storchaka #14208: No way to recover original argv with python -m http://bugs.python.org/issue14208 closed by ncoghlan #19930: os.makedirs('dir1/dir2', 0) always fails http://bugs.python.org/issue19930 closed by serhiy.storchaka #22744: os.mkdir on Windows silently strips trailing blanks from direc http://bugs.python.org/issue22744 closed by serhiy.storchaka #24037: Argument Clinic: add the boolint converter http://bugs.python.org/issue24037 closed by serhiy.storchaka #24796: Deleting names referencing from enclosed and enclosing scopes http://bugs.python.org/issue24796 closed by Mariatta #25455: Some repr implementations don't check for self-referential str http://bugs.python.org/issue25455 closed by serhiy.storchaka #26418: multiprocessing.pool.ThreadPool eats up memories http://bugs.python.org/issue26418 closed by pitrou #28331: "CPython implementation detail:" removed when content translat http://bugs.python.org/issue28331 closed by inada.naoki #28749: Fixed the documentation of the mapping codec APIs http://bugs.python.org/issue28749 closed by serhiy.storchaka #28876: bool of large range raises OverflowError http://bugs.python.org/issue28876 closed by serhiy.storchaka #29574: python-3.6.0.tgz permissions borked http://bugs.python.org/issue29574 closed by ned.deily #29615: SimpleXMLRPCDispatcher._dispatch mangles tracebacks when invok http://bugs.python.org/issue29615 closed by serhiy.storchaka #29638: Spurious failures in test_collections in releak hunting mode a http://bugs.python.org/issue29638 closed by serhiy.storchaka #29728: Expose TCP_NOTSENT_LOWAT http://bugs.python.org/issue29728 closed by Mariatta #29748: Argument Clinic: slice index converter http://bugs.python.org/issue29748 closed by serhiy.storchaka #29776: Modernize properties http://bugs.python.org/issue29776 closed by serhiy.storchaka #29793: Convert some builtin types constructors to Argument Clinic http://bugs.python.org/issue29793 closed by serhiy.storchaka #29836: Remove nturl2path from test_sundry and amend its docstring http://bugs.python.org/issue29836 closed by brett.cannon #29845: Mark tests that use _testcapi as CPython-only http://bugs.python.org/issue29845 closed by serhiy.storchaka #29848: Cannot use Decorators of the same class that requires an insta http://bugs.python.org/issue29848 closed by r.david.murray #29849: fix memory leak in import_from http://bugs.python.org/issue29849 closed by xiang.zhang #29850: file access, other drives http://bugs.python.org/issue29850 closed by Gabriel POTTER #29853: Improve exception messages for remove and index methods http://bugs.python.org/issue29853 closed by serhiy.storchaka #29855: The traceback compounding of RecursionError fails to work with http://bugs.python.org/issue29855 closed by ncoghlan #29856: curses online documentation typo http://bugs.python.org/issue29856 closed by Mariatta #29859: Return code of pthread_* in thread_pthread.h is not used for p http://bugs.python.org/issue29859 closed by Birne94 #29861: multiprocessing Pool keeps objects (tasks, args, results) aliv http://bugs.python.org/issue29861 closed by pitrou #29864: Misuse of Py_SIZE in dict.fromkey() http://bugs.python.org/issue29864 closed by serhiy.storchaka #29865: Use PyXXX_GET_SIZE macros rather than Py_SIZE for concrete typ http://bugs.python.org/issue29865 closed by serhiy.storchaka #29866: Added datetime_diff to datetime.py. http://bugs.python.org/issue29866 closed by serhiy.storchaka #29872: spam http://bugs.python.org/issue29872 closed by xiang.zhang #29873: Need a look for return value checking [_elementtree.c] http://bugs.python.org/issue29873 closed by xiang.zhang #29874: Need a look for return value checking [selectmodule.c] http://bugs.python.org/issue29874 closed by xiang.zhang #29875: IDLE quit unexpectedly http://bugs.python.org/issue29875 closed by ned.deily #29876: Check for null return value [_elementtree.c : subelement] http://bugs.python.org/issue29876 closed by xiang.zhang #29880: python3.6 install readline ,and then cpython exit http://bugs.python.org/issue29880 closed by zach.ware #29884: faulthandler does not properly restore sigaltstack during tear http://bugs.python.org/issue29884 closed by Mariatta #1117601: os.path.exists returns false negatives in MAC environments. http://bugs.python.org/issue1117601 closed by serhiy.storchaka

1 0

Await and Async keywords
by Aymeric Fromherz March 24, 2017

March 24, 2017

Hi, I'm currently looking into how Python3 is parsed, and I'm wondering why await and async aren't considered as keywords? Are there programs actually using await and async as variable names? Is there another behaviour where it is interesting to use async for something different? Cheers, Aymeric

2 2

Exact date of Python 2 EOL?
by Victor Stinner March 24, 2017

March 24, 2017

Hi, I looked at the "Status of Python branches" to check if it was up to date. It's the case, thanks :-) But it recalled me that no exact date was decided for the official end of line of the the Python 2 branch (2.7 EOL). https://docs.python.org/devguide/#status-of-python-branches says January 1st, 2020 https://pythonclock.org/ picked April 12th, 2020 (Pycon US) "Python 2.7 will not be maintained past 2020. No official date has been given, so this clock counts down until April 12th, 2020, which will be roughly the time of the 2020 PyCon. I am hereby suggesting we make PyCon 2020 the official end-of-life date, and we throw a massive party to celebrate all that Python 2 has done for us. (If this sounds interesting to you, email pythonclockorg(a)gmail.com)." Can we pick an official date? By the way, maybe we can also start to list vendors (Linux vendors?) who plan to offer commercial extended support? For example, you can expect longer support than 2020 from RHEL: https://access.redhat.com/support/policy/updates/errata Ubuntu 12.04 reached its end of life after 5 years, but it seems like Canonical also starts to offer extended support to customers: http://www.omgubuntu.co.uk/2017/03/ubuntu-12-04-esm-support You can expect longer Python 2 support indirectely ;-) Victor

12 15

3.5 unittest does not support namespace packages for discovering
by Ilya Kazakevich March 24, 2017

March 24, 2017

Hello. I have following layout: \---tests | test_module.py | __init__.py When I launch "python.exe" -m unittest discover -t . -s tests" it works perfectly. But when I remove " __init__.py" it says Start directory is not importable: "tests'" ``loader.py``: if start_dir != top_level_dir: is_not_importable = not os.path.isfile(os.path.join(start_dir, '__init__.py')) I believe ``__init__.py`` does not play any role since Python 3.3, am I right? If so, it seems to be a bug. Should I create an issue? Ilya.

5 5

[RELEASE] Python 3.6.1 is now available
by Ned Deily March 22, 2017

March 22, 2017

On behalf of the Python development community and the Python 3.6 release team, I would like to announce the availability of Python 3.6.1, the first maintenance release of Python 3.6. 3.6.0 was released on 2016-12-22 to great interest and now, three months later, we are providing the first set of bugfixes and documentation updates for it. Although it should be transparent to users of Python, 3.6.1 is the first release after some major changes to our development process so we ask users who build Python from source to be on the lookout for any unexpected differences. Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.1 here: https://www.python.org/downloads/release/python-361/ and its change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-1 The next maintenance release of Python 3.6 is expected to follow in about 3 months by the end of 2017-06. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

1 0

Translated Python documentation
by Victor Stinner March 22, 2017

March 22, 2017

Hi, I'm a member of the french #python-fr IRC channel on Freenode: it's common to meet people who don't speak english and so are unable to read the Python official documentation. Python wants to be widely available, for all users, in any language: that's also why Python 3 now allows any non-ASCII identifiers: https://www.python.org/dev/peps/pep-3131/#rationale There are a least 3 groups of people who are translating the Python documentation in their mother language (french, japanese, spanish). They tried to make it more official, but their attempt didn't go far yet. I'm writing this email to propose to officially support translated versions of the documentation. For me, the most impotant point would be to give access to the translated documentation from docs.python.org. For example, have a dropdown list with available languages. IMHO a reference in this domain is PHP: PHP documentation is translated to at least 10 languages. See for example the "Change language: [...]" list at: http://php.net/echo I'm not asking you to take any technical decision here, I'm just asking for an official general "support" of translated documentation. References to translated documentations: Transiflex project: https://www.transifex.com/python-doc/ Français (French, FR): doc: https://www.afpy.org/doc/python/ source: https://github.com/AFPy/python_doc_fr mailing list: http://lists.afpy.org/mailman/listinfo/traductions Japanese (JP): doc: http://docs.python.jp/3/ source: https://github.com/python-doc-ja/python-doc-ja Spanish: doc: http://docs.python.org.ar/tutorial/3/index.html Previous discussions: [Python-ideas] Cross link documentation translations (January, 2016): https://mail.python.org/pipermail/python-ideas/2016-January/038010.html [Python-ideas] https://docs.python.org/fr/ ? (March 2016) https://mail.python.org/pipermail/python-ideas/2016-March/038879.html Victor

17 35

PEP 544: Protocols
by Ivan Levkivskyi March 22, 2017

March 22, 2017

Hi all, PEP 484 specifies semantics for type hints. These type hints are used by various tools, including static type checkers. However, PEP 484 only specifies the semantics for nominal subtyping (subtyping based on subclassing). Here we propose a specification for semantics of structural subtyping (static duck typing). Previous discussions on this PEP happened at: https://mail.python.org/pipermail/python-ideas/2015-September/thread.html#3… https://github.com/python/typing/issues/11 https://github.com/python/peps/pull/224 -- Ivan =========================================== PEP: 544 Title: Protocols Version: $Revision$ Last-Modified: $Date$ Author: Ivan Levkivskyi <levkivskyi(a)gmail.com>, Jukka Lehtosalo < jukka.lehtosalo(a)iki.fi>, Łukasz Langa <lukasz(a)langa.pl> Discussions-To: Python-Dev <python-dev(a)python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 05-Mar-2017 Python-Version: 3.7 Abstract ======== Type hints introduced in PEP 484 can be used to specify type metadata for static type checkers and other third party tools. However, PEP 484 only specifies the semantics of *nominal* subtyping. In this PEP we specify static and runtime semantics of protocol classes that will provide a support for *structural* subtyping (static duck typing). .. _rationale: Rationale and Goals =================== Currently, PEP 484 and the ``typing`` module [typing]_ define abstract base classes for several common Python protocols such as ``Iterable`` and ``Sized``. The problem with them is that a class has to be explicitly marked to support them, which is unpythonic and unlike what one would normally do in idiomatic dynamically typed Python code. For example, this conforms to PEP 484:: from typing import Sized, Iterable, Iterator class Bucket(Sized, Iterable[int]): ... def __len__(self) -> int: ... def __iter__(self) -> Iterator[int]: ... The same problem appears with user-defined ABCs: they must be explicitly subclassed or registered. This is particularly difficult to do with library types as the type objects may be hidden deep in the implementation of the library. Also, extensive use of ABCs might impose additional runtime costs. The intention of this PEP is to solve all these problems by allowing users to write the above code without explicit base classes in the class definition, allowing ``Bucket`` to be implicitly considered a subtype of both ``Sized`` and ``Iterable[int]`` by static type checkers using structural [wiki-structural]_ subtyping:: from typing import Iterator, Iterable class Bucket: ... def __len__(self) -> int: ... def __iter__(self) -> Iterator[int]: ... def collect(items: Iterable[int]) -> int: ... result: int = collect(Bucket()) # Passes type check Note that ABCs in ``typing`` module already provide structural behavior at runtime, ``isinstance(Bucket(), Iterable)`` returns ``True``. The main goal of this proposal is to support such behavior statically. The same functionality will be provided for user-defined protocols, as specified below. The above code with a protocol class matches common Python conventions much better. It is also automatically extensible and works with additional, unrelated classes that happen to implement the required protocol. Nominal vs structural subtyping ------------------------------- Structural subtyping is natural for Python programmers since it matches the runtime semantics of duck typing: an object that has certain properties is treated independently of its actual runtime class. However, as discussed in PEP 483, both nominal and structural subtyping have their strengths and weaknesses. Therefore, in this PEP we *do not propose* to replace the nominal subtyping described by PEP 484 with structural subtyping completely. Instead, protocol classes as specified in this PEP complement normal classes, and users are free to choose where to apply a particular solution. See section on `rejected`_ ideas at the end of this PEP for additional motivation. Non-goals --------- At runtime, protocol classes will be simple ABCs. There is no intent to provide sophisticated runtime instance and class checks against protocol classes. This would be difficult and error-prone and will contradict the logic of PEP 484. As well, following PEP 484 and PEP 526 we state that protocols are **completely optional**: * No runtime semantics will be imposed for variables or parameters annotated with a protocol class. * Any checks will be performed only by third-party type checkers and other tools. * Programmers are free to not use them even if they use type annotations. * There is no intent to make protocols non-optional in the future. Existing Approaches to Structural Subtyping =========================================== Before describing the actual specification, we review and comment on existing approaches related to structural subtyping in Python and other languages: * ``zope.interface`` [zope-interfaces]_ was one of the first widely used approaches to structural subtyping in Python. It is implemented by providing special classes to distinguish interface classes from normal classes, to mark interface attributes, and to explicitly declare implementation. For example:: from zope.interface import Interface, Attribute, implements class IEmployee(Interface): name = Attribute("Name of employee") def do(work): """Do some work""" class Employee(object): implements(IEmployee) name = 'Anonymous' def do(self, work): return work.start() Zope interfaces support various contracts and constraints for interface classes. For example:: from zope.interface import invariant def required_contact(obj): if not (obj.email or obj.phone): raise Exception("At least one contact info is required") class IPerson(Interface): name = Attribute("Name") email = Attribute("Email Address") phone = Attribute("Phone Number") invariant(required_contact) Even more detailed invariants are supported. However, Zope interfaces rely entirely on runtime validation. Such focus on runtime properties goes beyond the scope of the current proposal, and static support for invariants might be difficult to implement. However, the idea of marking an interface class with a special base class is reasonable and easy to implement both statically and at runtime. * Python abstract base classes [abstract-classes]_ are the standard library tool to provide some functionality similar to structural subtyping. The drawback of this approach is the necessity to either subclass the abstract class or register an implementation explicitly:: from abc import ABC class MyTuple(ABC): pass MyTuple.register(tuple) assert issubclass(tuple, MyTuple) assert isinstance((), MyTuple) As mentioned in the `rationale`_, we want to avoid such necessity, especially in static context. However, in a runtime context, ABCs are good candidates for protocol classes and they are already used extensively in the ``typing`` module. * Abstract classes defined in ``collections.abc`` module [collections-abc]_ are slightly more advanced since they implement a custom ``__subclasshook__()`` method that allows runtime structural checks without explicit registration:: from collections.abc import Iterable class MyIterable: def __iter__(self): return [] assert isinstance(MyIterable(), Iterable) Such behavior seems to be a perfect fit for both runtime and static behavior of protocols. As discussed in `rationale`_, we propose to add static support for such behavior. In addition, to allow users to achieve such runtime behavior for *user defined* protocols a special ``@runtime`` decorator will be provided, see detailed `discussion`_ below. * TypeScript [typescript]_ provides support for user defined classes and interfaces. Explicit implementation declaration is not required and structural subtyping is verified statically. For example:: interface LabeledItem { label: string; size?: int; } function printLabel(obj: LabeledValue) { console.log(obj.label); } let myObj = {size: 10, label: "Size 10 Object"}; printLabel(myObj); Note that optional interface members are supported. Also, TypeScript prohibits redundant members in implementations. While the idea of optional members looks interesting, it would complicate this proposal and it is not clear how useful it will be. Therefore it is proposed to postpone this; see `rejected`_ ideas. In general, the idea of static protocol checking without runtime implications looks reasonable, and basically this proposal follows the same line. * Go [golang]_ uses a more radical approach and makes interfaces the primary way to provide type information. Also, assignments are used to explicitly ensure implementation:: type SomeInterface interface { SomeMethod() ([]byte, error) } if _, ok := someval.(SomeInterface); ok { fmt.Printf("value implements some interface") } Both these ideas are questionable in the context of this proposal. See the section on `rejected`_ ideas. .. _specification: Specification ============= Terminology ----------- We propose to use the term *protocols* for types supporting structural subtyping. The reason is that the term *iterator protocol*, for example, is widely understood in the community, and coming up with a new term for this concept in a statically typed context would just create confusion. This has the drawback that the term *protocol* becomes overloaded with two subtly different meanings: the first is the traditional, well-known but slightly fuzzy concept of protocols such as iterator; the second is the more explicitly defined concept of protocols in statically typed code. The distinction is not important most of the time, and in other cases we propose to just add a qualifier such as *protocol classes* when referring to the static type concept. If a class includes a protocol in its MRO, the class is called an *explicit* subclass of the protocol. If a class is a structural subtype of a protocol, it is said to implement the protocol and to be compatible with a protocol. If a class is compatible with a protocol but the protocol is not included in the MRO, the class is an *implicit* subtype of the protocol. The attributes (variables and methods) of a protocol that are mandatory for other class in order to be considered a structural subtype are called protocol members. .. _definition: Defining a protocol ------------------- Protocols are defined by including a special new class ``typing.Protocol`` (an instance of ``abc.ABCMeta``) in the base classes list, preferably at the end of the list. Here is a simple example:: from typing import Protocol class SupportsClose(Protocol): def close(self) -> None: ... Now if one defines a class ``Resource`` with a ``close()`` method that has a compatible signature, it would implicitly be a subtype of ``SupportsClose``, since the structural subtyping is used for protocol types:: class Resource: ... def close(self) -> None: self.file.close() self.lock.release() Apart from few restrictions explicitly mentioned below, protocol types can be used in every context where a normal types can:: def close_all(things: Iterable[SupportsClose]) -> None: for t in things: t.close() f = open('foo.txt') r = Resource() close_all([f, r]) # OK! close_all([1]) # Error: 'int' has no 'close' method Note that both the user-defined class ``Resource`` and the built-in ``IO`` type (the return type of ``open()``) are considered subtypes of ``SupportsClose``, because they provide a ``close()`` method with a compatible type signature. Protocol members ---------------- All methods defined in the protocol class body are protocol members, both normal and decorated with ``@abstractmethod``. If some or all parameters of protocol method are not annotated, then their types are assumed to be ``Any`` (see PEP 484). Bodies of protocol methods are type checked, except for methods decorated with ``@abstractmethod`` with trivial bodies. A trivial body can contain a docstring. Example:: from typing import Protocol from abc import abstractmethod class Example(Protocol): def first(self) -> int: # This is a protocol member return 42 @abstractmethod def second(self) -> int: # Method without a default implementation """Some method.""" Note that although formally the implicit return type of a method with a trivial body is ``None``, type checker will not warn about above example, such convention is similar to how methods are defined in stub files. Static methods, class methods, and properties are equally allowed in protocols. To define a protocol variable, one must use PEP 526 variable annotations in the class body. Additional attributes *only* defined in the body of a method by assignment via ``self`` are not allowed. The rationale for this is that the protocol class implementation is often not shared by subtypes, so the interface should not depend on the default implementation. Examples:: from typing import Protocol, List class Template(Protocol): name: str # This is a protocol member value: int = 0 # This one too (with default) def method(self) -> None: self.temp: List[int] = [] # Error in type checker To distinguish between protocol class variables and protocol instance variables, the special ``ClassVar`` annotation should be used as specified by PEP 526. Explicitly declaring implementation ----------------------------------- To explicitly declare that a certain class implements the given protocols, they can be used as regular base classes. In this case a class could use default implementations of protocol members. ``typing.Sequence`` is a good example of a protocol with useful default methods. Abstract methods with trivial bodies are recognized by type checkers as having no default implementation and can't be used via ``super()`` in explicit subclasses. The default implementations can not be used if the subtype relationship is implicit and only via structural subtyping -- the semantics of inheritance is not changed. Examples:: class PColor(Protocol): @abstractmethod def draw(self) -> str: ... def complex_method(self) -> int: # some complex code here class NiceColor(PColor): def draw(self) -> str: return "deep blue" class BadColor(PColor): def draw(self) -> str: return super().draw() # Error, no default implementation class ImplicitColor: # Note no 'PColor' base here def draw(self) -> str: return "probably gray" def comlex_method(self) -> int: # class needs to implement this nice: NiceColor another: ImplicitColor def represent(c: PColor) -> None: print(c.draw(), c.complex_method()) represent(nice) # OK represent(another) # Also OK Note that there is no conceptual difference between explicit and implicit subtypes, the main benefit of explicit subclassing is to get some protocol methods "for free". In addition, type checkers can statically verify that the class actually implements the protocol correctly:: class RGB(Protocol): rgb: Tuple[int, int, int] @abstractmethod def intensity(self) -> int: return 0 class Point(RGB): def __init__(self, red: int, green: int, blue: str) -> None: self.rgb = red, green, blue # Error, 'blue' must be 'int' # Type checker might warn that 'intensity' is not defined A class can explicitly inherit from multiple protocols and also form normal classes. In this case methods are resolved using normal MRO and a type checker verifies that all subtyping are correct. The semantics of ``@abstractmethod`` is not changed, all of them must be implemented by an explicit subclass before it could be instantiated. Merging and extending protocols ------------------------------- The general philosophy is that protocols are mostly like regular ABCs, but a static type checker will handle them specially. Subclassing a protocol class would not turn the subclass into a protocol unless it also has ``typing.Protocol`` as an explicit base class. Without this base, the class is "downgraded" to a regular ABC that cannot be used with structural subtyping. A subprotocol can be defined by having *both* one or more protocols as immediate base classes and also having ``typing.Protocol`` as an immediate base class:: from typing import Sized, Protocol class SizedAndCloseable(Sized, Protocol): def close(self) -> None: ... Now the protocol ``SizedAndCloseable`` is a protocol with two methods, ``__len__`` and ``close``. If one omits ``Protocol`` in the base class list, this would be a regular (non-protocol) class that must implement ``Sized``. If ``Protocol`` is included in the base class list, all the other base classes must be protocols. A protocol can't extend a regular class. Alternatively, one can implement ``SizedAndCloseable`` like this, assuming the existence of ``SupportsClose`` from the example in `definition`_ section:: from typing import Sized class SupportsClose(...): ... # Like above class SizedAndCloseable(Sized, SupportsClose, Protocol): pass The two definitions of ``SizedAndClosable`` are equivalent. Subclass relationships between protocols are not meaningful when considering subtyping, since structural compatibility is the criterion, not the MRO. Note that rules around explicit subclassing are different from regular ABCs, where abstractness is simply defined by having at least one abstract method being unimplemented. Protocol classes must be marked *explicitly*. Generic and recursive protocols ------------------------------- Generic protocols are important. For example, ``SupportsAbs``, ``Iterable`` and ``Iterator`` are generic protocols. They are defined similar to normal non-protocol generic types:: T = TypeVar('T', covariant=True) class Iterable(Protocol[T]): @abstractmethod def __iter__(self) -> Iterator[T]: ... Note that ``Protocol[T, S, ...]`` is allowed as a shorthand for ``Protocol, Generic[T, S, ...]``. Recursive protocols are also supported. Forward references to the protocol class names can be given as strings as specified by PEP 484. Recursive protocols will be useful for representing self-referential data structures like trees in an abstract fashion:: class Traversable(Protocol): leaves: Iterable['Traversable'] Using Protocols =============== Subtyping relationships with other types ---------------------------------------- Protocols cannot be instantiated, so there are no values with protocol types. For variables and parameters with protocol types, subtyping relationships are subject to the following rules: * A protocol is never a subtype of a concrete type. * A concrete type or a protocol ``X`` is a subtype of another protocol ``P`` if and only if ``X`` implements all protocol members of ``P``. In other words, subtyping with respect to a protocol is always structural. * Edge case: for recursive protocols, a class is considered a subtype of the protocol in situations where such decision depends on itself. Continuing the previous example:: class Tree(Generic[T]): def __init__(self, value: T, leaves: 'List[Tree[T]]') -> None: self.value = value self.leaves = leaves def walk(graph: Traversable) -> None: ... tree: Tree[float] = Tree(0, []) walk(tree) # OK, 'Tree[float]' is a subtype of 'Traversable' Generic protocol types follow the same rules of variance as non-protocol types. Protocol types can be used in all contexts where any other types can be used, such as in ``Union``, ``ClassVar``, type variables bounds, etc. Generic protocols follow the rules for generic abstract classes, except for using structural compatibility instead of compatibility defined by inheritance relationships. Unions and intersections of protocols ------------------------------------- ``Union`` of protocol classes behaves the same way as for non-protocol classes. For example:: from typing import Union, Optional, Protocol class Exitable(Protocol): def exit(self) -> int: ... class Quitable(Protocol): def quit(self) -> Optional[int]: ... def finish(task: Union[Exitable, Quitable]) -> int: ... class GoodJob: ... def quit(self) -> int: return 0 finish(GoodJob()) # OK One can use multiple inheritance to define an intersection of protocols. Example:: from typing import Sequence, Hashable class HashableFloats(Sequence[float], Hashable, Protocol): pass def cached_func(args: HashableFloats) -> float: ... cached_func((1, 2, 3)) # OK, tuple is both hashable and sequence If this will prove to be a widely used scenario, then a special intersection type construct may be added in future as specified by PEP 483, see `rejected`_ ideas for more details. ``Type[]`` with protocols ------------------------- Variables and parameters annotated with ``Type[Proto]`` accept only concrete (non-protocol) subtypes of ``Proto``. The main reason for this is to allow instantiation of parameters with such type. For example:: class Proto(Protocol): @abstractmethod def meth(self) -> int: ... class Concrete: def meth(self) -> int: return 42 def fun(cls: Type[Proto]) -> int: return cls().meth() # OK fun(Proto) # Error fun(Concrete) # OK The same rule applies to variables:: var: Type[Proto] var = Proto # Error var = Concrete # OK var().meth() # OK Assigning an ABC or a protocol class to a variable is allowed if it is not explicitly typed, and such assignment creates a type alias. For normal (non-abstract) classes, the behavior of ``Type[]`` is not changed. ``NewType()`` and type aliases ------------------------------ Protocols are essentially anonymous. To emphasize this point, static type checkers might refuse protocol classes inside ``NewType()`` to avoid an illusion that a distinct type is provided:: form typing import NewType , Protocol, Iterator class Id(Protocol): code: int secrets: Iterator[bytes] UserId = NewType('UserId', Id) # Error, can't provide distinct type On the contrary, type aliases are fully supported, including generic type aliases:: from typing import TypeVar, Reversible, Iterable, Sized T = TypeVar('T') class SizedIterable(Iterable[T], Sized, Protocol): pass CompatReversible = Union[Reversible[T], SizedIterable[T]] .. _discussion: ``@runtime`` decorator and narrowing types by ``isinstance()`` -------------------------------------------------------------- The default semantics is that ``isinstance()`` and ``issubclass()`` fail for protocol types. This is in the spirit of duck typing -- protocols basically would be used to model duck typing statically, not explicitly at runtime. However, it should be possible for protocol types to implement custom instance and class checks when this makes sense, similar to how ``Iterable`` and other ABCs in ``collections.abc`` and ``typing`` already do it, but this is limited to non-generic and unsubscripted generic protocols (``Iterable`` is statically equivalent to ``Iterable[Any]`). The ``typing`` module will define a special ``@runtime`` class decorator that provides the same semantics for class and instance checks as for ``collections.abc`` classes, essentially making them "runtime protocols":: from typing import runtime, Protocol @runtime class Closeable(Protocol): def close(self): ... assert isinstance(open('some/file'), Closeable) Static type checkers will understand ``isinstance(x, Proto)`` and ``issubclass(C, Proto)`` for protocols defined with this decorator (as they already do for ``Iterable`` etc.). Static type checkers will narrow types after such checks by the type erased ``Proto`` (i.e. with all variables having type ``Any`` and all methods having type ``Callable[..., Any]``). Note that ``isinstance(x, Proto[int])`` etc. will always fail in agreement with PEP 484. Examples:: from typing import Iterable, Iterator, Sequence def process(items: Iterable[int]) -> None: if isinstance(items, Iterator): # 'items' have type 'Iterator[int]' here elif isinstance(items, Sequence[int]): # Error! Can't use 'isinstance()' with subscripted protocols Note that instance checks are not 100% reliable statically, this is why this behavior is opt-in, see section on `rejected`_ ideas for examples. Using Protocols in Python 2.7 - 3.5 =================================== Variable annotation syntax was added in Python 3.6, so that the syntax for defining protocol variables proposed in `specification`_ section can't be used in earlier versions. To define these in earlier versions of Python one can use properties:: class Foo(Protocol): @property def c(self) -> int: return 42 # Default value can be provided for property... @abstractproperty def d(self) -> int: # ... or it can be abstract return 0 In Python 2.7 the function type comments should be used as per PEP 484. The ``typing`` module changes proposed in this PEP will be also backported to earlier versions via the backport currently available on PyPI. Runtime Implementation of Protocol Classes ========================================== Implementation details ---------------------- The runtime implementation could be done in pure Python without any effects on the core interpreter and standard library except in the ``typing`` module: * Define class ``typing.Protocol`` similar to ``typing.Generic``. * Implement metaclass functionality to detect whether a class is a protocol or not. Add a class attribute ``__protocol__ = True`` if that is the case. Verify that a protocol class only has protocol base classes in the MRO (except for object). * Implement ``@runtime`` that adds all attributes to ``__subclasshook__()``. * All structural subtyping checks will be performed by static type checkers, such as ``mypy`` [mypy]_. No additional support for protocol validation will be provided at runtime. Changes in the typing module ---------------------------- The following classes in ``typing`` module will be protocols: * ``Hashable`` * ``SupportsAbs`` (and other ``Supports*`` classes) * ``Iterable``, ``Iterator`` * ``Sized`` * ``Container`` * ``Collection`` * ``Reversible`` * ``Sequence``, ``MutableSequence`` * ``AbstractSet``, ``MutableSet`` * ``Mapping``, ``MutableMapping`` * ``ItemsView`` (and other ``*View`` classes) * ``AsyncIterable``, ``AsyncIterator`` * ``Awaitable`` * ``Callable`` * ``ContextManager``, ``AsyncContextManager`` Most of these classes are small and conceptually simple. It is easy to see what are the methods these protocols implement, and immediately recognize the corresponding runtime protocol counterpart. Practically, few changes will be needed in ``typing`` since some of these classes already behave the necessary way at runtime. Most of these will need to be updated only in the corresponding ``typeshed`` stubs [typeshed]_. All other concrete generic classes such as ``List``, ``Set``, ``IO``, ``Deque``, etc are sufficiently complex that it makes sense to keep them non-protocols (i.e. require code to be explicit about them). Also, it is too easy to leave some methods unimplemented by accident, and explicitly marking the subclass relationship allows type checkers to pinpoint the missing implementations. Introspection ------------- The existing class introspection machinery (``dir``, ``__annotations__`` etc) can be used with protocols. In addition, all introspection tools implemented in the ``typing`` module will support protocols. Since all attributes need to be defined in the class body based on this proposal, protocol classes will have even better perspective for introspection than regular classes where attributes can be defined implicitly -- protocol attributes can't be initialized in ways that are not visible to introspection (using ``setattr()``, assignment via ``self``, etc.). Still, some things like types of attributes will not be visible at runtime in Python 3.5 and earlier, but this looks like a reasonable limitation. There will be only limited support of ``isinstance()`` and ``issubclass()`` as discussed above (these will *always* fail with ``TypeError`` for subscripted generic protocols, since a reliable answer could not be given at runtime in this case). But together with other introspection tools this give a reasonable perspective for runtime type checking tools. .. _rejected: Rejected/Postponed Ideas ======================== The ideas in this section were previously discussed in [several]_ [discussions]_ [elsewhere]_. Make every class a protocol by default -------------------------------------- Some languages such as Go make structural subtyping the only or the primary form of subtyping. We could achieve a similar result by making all classes protocols by default (or even always). However we believe that it is better to require classes to be explicitly marked as protocols, for the following reasons: * Protocols don't have some properties of regular classes. In particular, ``isinstance()``, as defined for normal classes, is based on the nominal hierarchy. In order to make everything a protocol by default, and have ``isinstance()`` work would require changing its semantics, which won't happen. * Protocol classes should generally not have many method implementations, as they describe an interface, not an implementation. Most classes have many implementations, making them bad protocol classes. * Experience suggests that many classes are not practical as protocols anyway, mainly because their interfaces are too large, complex or implementation-oriented (for example, they may include de facto private attributes and methods without a ``__`` prefix). * Most actually useful protocols in existing Python code seem to be implicit. The ABCs in ``typing`` and ``collections.abc`` are rather an exception, but even they are recent additions to Python and most programmers do not use them yet. * Many built-in functions only accept concrete instances of ``int`` (and subclass instances), and similarly for other built-in classes. Making ``int`` a structural type wouldn't be safe without major changes to the Python runtime, which won't happen. Support optional protocol members --------------------------------- We can come up with examples where it would be handy to be able to say that a method or data attribute does not need to be present in a class implementing a protocol, but if it is present, it must conform to a specific signature or type. One could use a ``hasattr()`` check to determine whether they can use the attribute on a particular instance. Languages such as TypeScript have similar features and apparently they are pretty commonly used. The current realistic potential use cases for protocols in Python don't require these. In the interest of simplicity, we propose to not support optional methods or attributes. We can always revisit this later if there is an actual need. Make protocols interoperable with other approaches -------------------------------------------------- The protocols as described here are basically a minimal extension to the existing concept of ABCs. We argue that this is the way they should be understood, instead of as something that *replaces* Zope interfaces, for example. Attempting such interoperabilities will significantly complicate both the concept and the implementation. On the other hand, Zope interfaces are conceptually a superset of protocols defined here, but using an incompatible syntax to define them, because before PEP 526 there was no straightforward way to annotate attributes. In the 3.6+ world, ``zope.interface`` might potentially adopt the ``Protocol`` syntax. In this case, type checkers could be taught to recognize interfaces as protocols and make simple structural checks with respect to them. Use assignments to check explicitly that a class implements a protocol ---------------------------------------------------------------------- In Go language the explicit checks for implementation are performed via dummy assignments [golang]_. Such a way is also possible with the current proposal. Example:: class A: def __len__(self) -> float: return ... _: Sized = A() # Error: A.__len__ doesn't conform to 'Sized' # (Incompatible return type 'float') This approach moves the check away from the class definition and it almost requires a comment as otherwise the code probably would not make any sense to an average reader -- it looks like dead code. Besides, in the simplest form it requires one to construct an instance of ``A``, which could be problematic if this requires accessing or allocating some resources such as files or sockets. We could work around the latter by using a cast, for example, but then the code would be ugly. Therefore we discourage the use of this pattern. Support ``isinstance()`` checks by default ------------------------------------------ The problem with this is instance checks could be unreliable, except for situations where there is a common signature convention such as ``Iterable``. For example:: class P(Protocol): def common_method_name(self, x: int) -> int: ... class X: <a bunch of methods> def common_method_name(self) -> None: ... # Note different signature def do_stuff(o: Union[P, X]) -> int: if isinstance(o, P): return o.common_method_name(1) # oops, what if it's an X instance? Another potentially problematic case is assignment of attributes *after* instantiation:: class P(Protocol): x: int class C: def initialize(self) -> None: self.x = 0 c = C() isinstance(c1, P) # False c.initialize() isinstance(c, P) # True def f(x: Union[P, int]) -> None: if isinstance(x, P): # static type of x is P here ... else: # type of x is "int" here? print(x + 1) f(C()) # oops We argue that requiring an explicit class decorator would be better, since one can then attach warnings about problems like this in the documentation. The user would be able to evaluate whether the benefits outweigh the potential for confusion for each protocol and explicitly opt in -- but the default behavior would be safer. Finally, it will be easy to make this behavior default if necessary, while it might be problematic to make it opt-in after being default. Provide a special intersection type construct --------------------------------------------- There was an idea to allow ``Proto = All[Proto1, Proto2, ...]`` as a shorthand for:: class Proto(Proto1, Proto2, ..., Protocol): pass However, it is not yet clear how popular/useful it will be and implementing this in type checkers for non-protocol classes could be difficult. Finally, it will be very easy to add this later if needed. References ========== .. [typing] https://docs.python.org/3/library/typing.html .. [wiki-structural] https://en.wikipedia.org/wiki/Structural_type_system .. [zope-interfaces] https://zopeinterface.readthedocs.io/en/latest/ .. [abstract-classes] https://docs.python.org/3/library/abc.html .. [collections-abc] https://docs.python.org/3/library/collections.abc.html .. [typescript] https://www.typescriptlang.org/docs/handbook/interfaces.html .. [golang] https://golang.org/doc/effective_go.html#interfaces_and_types .. [typeshed] https://github.com/python/typeshed/ .. [mypy] http://github.com/python/mypy/ .. [several] https://mail.python.org/pipermail/python-ideas/2015-September/thread.html#3… .. [discussions] https://github.com/python/typing/issues/11 .. [elsewhere] https://github.com/python/peps/pull/224 Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

6 13