[Python-Dev] PEP 561 implemented and minor clarification
Hello,
I've updated PEP 561 to clarify that any installed stub package should
supersede an installed inline package. In other words if there is:
/global/site-packages/pkg/
/user/site-packages/pkg-stubs/
Even if pkg in the global site packages is found first and marks that it
supports types, the stub package should supersede it.
I also point to mypy's docs on its implementation of the PEP (which can be
read about here:
https://mypy.readthedocs.io/en/latest/installed_packages.html). The
implementation has been merged into master and will be available in the
0.590 release.
As always, the PEP text is replicated below.
Cheers!
Ethan
==
PEP: 561
Title: Distributing and Packaging Type Information
Author: Ethan Smith
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Sep-2017
Python-Version: 3.7
Post-History: 10-Sep-2017, 12-Sep-2017, 06-Oct-2017, 26-Oct-2017
Abstract
PEP 484 introduced type hinting to Python, with goals of making typing
gradual and easy to adopt. Currently, typing information must be distributed
manually. This PEP provides a standardized means to leverage existing tooling
to package and distribute type information with minimal work and an ordering
for type checkers to resolve modules and collect this information for type
checking.
Rationale
=
Currently, package authors wish to distribute code that has inline type
information. Additionally, maintainers would like to distribute stub files
to keep Python 2 compatibility while using newer annotation syntax. However,
there is no standard method to distribute packages with type information.
Also, if one wished to ship stub files privately the only method available
would be via setting ``MYPYPATH`` or the equivalent to manually point to
stubs. If the package can be released publicly, it can be added to
typeshed [1]_. However, this does not scale and becomes a burden on the
maintainers of typeshed. In addition, it ties bug fixes in stubs to releases
of the tool using typeshed.
PEP 484 has a brief section on distributing typing information. In this
section [2]_ the PEP recommends using ``shared/typehints/pythonX.Y/`` for
shipping stub files. However, manually adding a path to stub files for each
third party library does not scale. The simplest approach people have taken
is to add ``site-packages`` to their ``MYPYPATH``, but this causes type
checkers to fail on packages that are highly dynamic (e.g. sqlalchemy
and Django).
Definition of Terms
===
The definition of "MAY", "MUST", and "SHOULD", and "SHOULD NOT" are
to be interpreted as described in RFC 2119.
"inline" - the types are part of the runtime code using PEP 526 and 3107
syntax.
"stubs" - files containing only type information, empty of runtime code.
"Distributions" are the packaged files which are used to publish and distribute
a release. [3]_
"Module" a file containing Python runtime code or stubbed type information.
"Package" a directory or directories that namespace Python modules.
Specification
=
There are several motivations and methods of supporting typing in a package.
This PEP recognizes three (3) types of packages that users of typing wish to
create:
1. The package maintainer would like to add type information inline.
2. The package maintainer would like to add type information via stubs.
3. A third party or package maintainer would like to share stub files for
a package, but the maintainer does not want to include them in the source
of the package.
This PEP aims to support these scenarios and make them simple to add to
packaging and deployment.
The two major parts of this specification are the packaging specifications
and the resolution order for resolving module type information. The type
checking spec is meant to replace the ``shared/typehints/pythonX.Y/`` spec
of PEP 484 [2]_.
New third party stub libraries SHOULD distribute stubs via the third party
packaging methods proposed in this PEP in place of being added to typeshed.
Typeshed will remain in use, but if maintainers are found, third party stubs
in typeshed MAY be split into their own package.
Packaging Type Information
--
In order to make packaging and distributing type information as simple and
easy as possible, packaging and distribution is done through existing
frameworks.
Package maintainers who wish to support type checking of their code MUST add
a marker file named ``py.typed`` to their package supporting typing.
This marker applies
recursively: if a top-level package includes it, all its sub-packages
MUST support
type checking as well. To have this file installed with the package,
maintainers can use existing packaging options such as ``package_data`` in
distutils, shown below.
Distutils option example::
setup(
...,
package_data = {
'foopkg': ['py.typed'],
},
...,
)
For namespace packages, the ``py.typed`` file should be
[Python-Dev] python3.5.3: xmlrpc_net unit test fail
Hi All, Before installing python 3.5.3, i performed the test cases provided with the source tar ball. But 3 tests failed. I figured out the reason for other 2. But 1 test case is out of my understanding. Re-running test 'test_xmlrpc_net' in verbose mode test_python_builders (test.test_xmlrpc_net.PythonBuildersTest) ... ERROR == ERROR: test_python_builders (test.test_xmlrpc_net.PythonBuildersTest) -- Traceback (most recent call last): File "/pkgs/Python-3.5.3/Lib/test/test_xmlrpc_net.py", line 17, in test_python_builders builders = server.getAllBuilders() File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1092, in __call__ return self.__send(self.__name, args) File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1432, in __request verbose=self.__verbose File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1134, in request return self.single_request(host, handler, request_body, verbose) File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1167, in single_request dict(resp.getheaders()) xmlrpc.client.ProtocolError: -- Ran 1 test in 0.215s FAILED (errors=1) test test_xmlrpc_net failed Can somebody highlight the reason of failure. -- Regards, Nikita Gupta ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python3.5.3: xmlrpc_net unit test fail
That unit test was written when https://buildbot.python.org was running at Buildbot version 8 which had an XMLRPC interface. Last year, buildbot.python.org was upgraded to Buildbot version 9, which dropped the XMLRPC interface in favor of a REST API. So that link no longer works. The unit change was changed to skip: https://github.com/python/cpython/blob/master/Lib/test/test_xmlrpc_net.py#L8 -- Craig On Thu, Apr 12, 2018 at 3:16 AM, Nikita Gupta wrote: > Hi All, > > Before installing python 3.5.3, i performed the test cases provided with > the source tar ball. > But 3 tests failed. I figured out the reason for other 2. But 1 test case > is out of my understanding. > > Re-running test 'test_xmlrpc_net' in verbose mode > test_python_builders (test.test_xmlrpc_net.PythonBuildersTest) ... ERROR > > == > ERROR: test_python_builders (test.test_xmlrpc_net.PythonBuildersTest) > -- > Traceback (most recent call last): > File "/pkgs/Python-3.5.3/Lib/test/test_xmlrpc_net.py", line 17, in > test_python_builders > builders = server.getAllBuilders() > File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1092, in __call__ > return self.__send(self.__name, args) > File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1432, in __request > verbose=self.__verbose > File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1134, in request > return self.single_request(host, handler, request_body, verbose) > File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1167, in > single_request > dict(resp.getheaders()) > xmlrpc.client.ProtocolError: xmlrpc/: 503 Service Unavailable> > > -- > Ran 1 test in 0.215s > > FAILED (errors=1) > test test_xmlrpc_net failed > > Can somebody highlight the reason of failure. > > > -- > Regards, > Nikita Gupta > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > rodrigc%40freebsd.org > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 575: Unifying function/method classes
Dear Python developers, I would like to request a review of PEP 575, which is about changing the classes used for built-in functions and Python functions and methods. The text of the PEP can be found at https://www.python.org/dev/peps/pep-0575/ No substantial changes to the contents of the PEP were made compared to the first posting. However, many details have been changed, clarified or added, based on comments from the initial discussion thread and the work on an implementation. My implementation is at https://github.com/jdemeyer/cpython/tree/pep575 This is certainly not meant to be ready to merge upstream; in particular, the Python test suite does not fully pass. Nevertheless, it should be good enough to review the PEP. If the PEP would be accepted, I plan to continue working on the implementation, including adding tests and documentation. Jeroen. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
