RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20180426/d065a6dd/attachment-0001.html below:

<div dir="ltr"><div> </div>Thanks for working on this, Marcel (and Petr). This looks like an ambitious intern project :) Couple of questions and comments in-line. <div class="gmail_extra"> <div class="gmail_quote">On Mon, Apr 23, 2018 at 12:36 PM, Marcel Plch <<a href="mailto:gmarcel.plch@gmail.com" target="_blank">gmarcel.plch@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello, 
I am an intern at Red Hat mentored by Petr Viktorin. As a part of my 
internship, I learned the CPython internals and how to contribute 
to the CPython interpreter. 
 
As a result, I have prepared PEP 573, which solves some problems 
that PEP 489 (Multi-phase extension module initialization) has left open. 
Specifically, this PEP proposes a way to access per-module state from methods of 
built-in and extension types. 
Like PEP 489, it aims to make subinterpreter-friendly built-in/extension modules 
easier to create. 
 
A big problem found when converting many modules to PEP 489 multi-phase 
initialization is subinterpreter-friendly access to exception 
types defined in built-in/extension modules. 
This PEP solves this by introducing "immutable exception types". 
The current implementation requires one new type flag and two new 
pointers in the heap type structure. 
It should be possible to remove eiher the flag or one of the two pointers, 
if we agree on the other mechanics in the PEP . 
 
 
=================== 
 
PEP: 573 
Title: Module State Access from C Extension Methods 
Version: $Revision$ 
Last-Modified: $Date$ 
Author: Petr Viktorin <<a href="mailto:encukou@gmail.com">encukou@gmail.com</a>>, 
Â Â Â Â Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>>, 
Â Â Â Â Eric Snow <<a href="mailto:ericsnowcurrently@gmail.com">ericsnowcurrently@gmail.com</a>>, 
Â Â Â Â Marcel Plch <<a href="mailto:gmarcel.plch@gmail.com">gmarcel.plch@gmail.com</a>> 
Discussions-To: <a href="mailto:import-sig@python.org">import-sig@python.org</a> 
Status: Active 
Type: Process 
Content-Type: text/x-rst 
Created: 02-Jun-2016 
Python-Version: 3.8 
Post-History: 
 
 
Abstract 
======== 
 
This PEP proposes to add a way for CPython extension methods to access 
context such as 
the state of the modules they are defined in. 
 
This will allow extension methods to use direct pointer dereferences 
rather than PyState_FindModule for looking up module state, reducing 
or eliminating the 
performance cost of using module-scoped state over process global state. 
 
This fixes one of the remaining roadblocks for adoption of PEP 3121 (Extension 
module initialization and finalization) and PEP 489 
(Multi-phase extension module initialization). 
 
Additionaly, support for easier creation of immutable exception 
classes is added. </blockquote><div> </div><div>I'm not a fan of using 'immutable' here, or in the API function name. I understand the types are to some extent immutable (apart from their refcount, I assume), but I think it's going to be too easy to confuse it with types whose *instances* are immutable. (We do occasionally say things like "tuples are an immutable type".) Since the point is that they behave like statically defined ones, perhaps 'Static' would be a reasonable replacement.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This removes the need for keeping per-module state if it would only be used 
for exception classes. 
 
While this PEP takes an additional step towards fully solving the 
problems that PEP 3121 and PEP 489 started 
tackling, it does not attempt to resolve *all* remaining concerns. In 
particular, accessing the module state from slot methods (``nb_add``, 
etc) remains slower than accessing that state from other extension 
methods. 
 
 
Terminology 
=========== 
 
Process-Global State 
-------------------- 
 
C-level static variables. Since this is very low-level 
memory storage, it must be managed carefully. 
 
Per-module State 
---------------- 
 
State local to a module object, allocated dynamically as part of a 
module object's initialization. This isolates the state from other 
instances of the module (including those in other subinterpreters). 
 
Accessed by ``PyModule_GetState()``. 
 
 
Static Type 
----------- 
 
A type object defined as a C-level static variable, i.e. a compiled-in 
type object. 
 
A static type needs to be shared between module instances and has no 
information of what module it belongs to. 
Static types do not have ``__dict__`` (although their instances might). 
 
Heap Type 
--------- 
 
A type object created at run time. 
 
 
Rationale 
========= 
 
PEP 489 introduced a new way to initialize extension modules, which brings 
several advantages to extensions that implement it: 
 
Â Â * The extension modules behave more like their Python counterparts. 
Â Â * The extension modules can easily support loading into pre-existing 
Â Â Â module objects, which paves the way for extension module support for 
Â Â Â ``runpy`` or for systems that enable extension module reloading. 
Â Â * Loading multiple modules from the same extension is possible, which 
Â Â Â makes testing module isolation (a key feature for proper sub-interpreter 
Â Â Â support) possible from a single interpreter. 
 
The biggest hurdle for adoption of PEP 489 is allowing access to module state 
from methods of extension types. 
Currently, the way to access this state from extension methods is by 
looking up the module via 
``PyState_FindModule`` (in contrast to module level functions in 
extension modules, which 
receive a module reference as an argument). 
However, ``PyState_FindModule`` queries the thread-local state, making 
it relatively 
costly compared to C level process global access and consequently 
deterring module authors from using it. 
 
Also, ``PyState_FindModule`` relies on the assumption that in each 
subinterpreter, there is at most one module corresponding to 
a given ``PyModuleDef``.Â This does not align well with Python's import 
machinery.Â Since PEP 489 aimed to fix that,Â the assumption does 
not hold for modules that use multi-phase initialization, so 
``PyState_FindModule`` is unavailable for these modules. 
 
A faster, safer way of accessing module-level state from extension methods 
is needed. 
 
 
Immutable Exception Types 
------------------------- 
 
For isolated modules to work, any class whose methods touch module state 
must be a heap type, so that each instance of a module can have its own 
type object.Â With the changes proposed in this PEP, heap type instances will 
have access to module state without global registration.Â But, to create 
instances of heap types, one will need the module state in order to 
get the type object corresponding to the appropriate module. 
In short, heap types are "viral" â anything that âtouchesâ them must itself be 
a heap type. 
 
Curently, most exception types, apart from the ones in ``builtins``, are 
heap types.Â This is likely simply because there is a convenient way 
to create them: ``PyErr_NewException``. 
Heap types generally have a mutable ``__dict__``. 
In most cases, this mutability is harmful.Â For example, exception types 
from the ``sqlite`` module are mutable and shared across subinterpreters. 
This allows "smuggling" values to other subinterpreters via attributes of 
``sqlite3.Error``. 
 
Moreover, since raising exceptions is a common operation, and heap types 
will be "viral", ``PyErr_NewException`` will tend to "infect" the module 
with "heap type-ness" â at least if the module decides play well with 
subinterpreters/isolation. 
Many modules could go without module state 
entirely if the exception classes were immutable. 
 
To solve this problem, a new function for creating immutable exception types 
is proposed. 
 
 
Background 
=========== 
 
The implementation of a Python method may need access to one or more of 
the following pieces of information: 
 
Â Â * The instance it is called on (``self``) 
Â Â * The underlying function 
Â Â * The class the method was defined in 
Â Â * The corresponding module 
Â Â * The module state 
 
In Python code, the Python-level equivalents may be retrieved as:: 
 
Â Â import sys 
 
Â Â Â Â def meth(self): 
Â Â Â Â Â Â instance = self 
Â Â Â Â Â Â module_globals = globals() 
Â Â Â Â Â Â module_object = sys.modules[__name__]Â # (1) 
Â Â Â Â Â Â underlying_function = Foo.methÂ Â Â Â Â # (1) 
Â Â Â Â Â Â defining_class = FooÂ Â Â Â Â Â Â Â Â Â # (1) 
Â Â Â Â Â Â defining_class = __class__Â Â Â Â Â Â Â # (2) 
 
.. note:: 
 
Â Â The defining class is not ``type(self)``, since ``type(self)`` might 
Â Â be a subclass of ``Foo``. 
 
The statements marked (1) implicitly rely on name-based lookup via the 
function's ``__globals__``: 
either the ``Foo`` attribute to access the defining class and Python 
function object, or ``__name__`` to find the module object in 
``sys.modules``. 
In Python code, this is feasible, as ``__globals__`` is set 
appropriately when the function definition is executed, and 
even if the namespace has been manipulated to return a different 
object, at worst an exception will be raised. 
 
The ``__class__`` closure, (2), is a safer way to get the defining 
class, but it still relies on ``__closure__`` being set appropriately. 
 
By contrast, extension methods are typically implemented as normal C functions. 
This means that they only have access to their arguments and C level 
thread-local 
and process-global states. Traditionally, many extension modules have stored 
their shared state in C-level process globals, causing problems when: 
 
Â Â * running multiple initialize/finalize cycles in the same process 
Â Â * reloading modules (e.g. to test conditional imports) 
Â Â * loading extension modules in subinterpreters 
 
PEP 3121 attempted to resolve this by offering the 
``PyState_FindModule`` API, but this still has significant problems 
when it comes to extension methods (rather than module level 
functions): 
 
Â Â * it is markedly slower than directly accessing C-level process-global state 
Â Â * there is still some inherent reliance on process global state 
that means it still doesn't reliably handle module reloading 
 
It's also the case that when looking up a C-level struct such as 
module state, supplying 
an unexpected object layout can crash the interpreter, so it's 
significantly more important to ensure that extension 
methods receive the kind of object they expect. 
 
Proposal 
======== 
 
Currently, a bound extension method (``PyCFunction`` or 
``PyCFunctionWithKeywords``) receives only 
``self``, and (if applicable) the supplied positional and keyword arguments. 
 
While module-level extension functions already receive access to the 
defining module object via their 
``self`` argument, methods of extension types don't have that luxury: 
they receive the bound instance 
via ``self``, and hence have no direct access to the defining class or 
the module level state. 
 
The additional module level context described above can be made 
available with two changes. 
Both additions are optional; extension authors need to opt in to start 
using them: 
 
Â Â * Add a pointer to the module to heap type objects. 
 
Â Â * Pass the defining class to the underlying C function. 
 
Â Â Â The defining class is readily available at the time built-in 
Â Â Â method object (``PyCFunctionObject``) is created, so it can be stored 
Â Â Â in a new struct that extends ``PyCFunctionObject``. 
 
The module state can then be retrieved from the module object via 
``PyModule_GetState``. 
 
Note that this proposal implies that any type whose method needs to access 
per-module state must be a heap type, rather than a static type. 
 
This is necessary to support loading multiple module objects from a single 
extension: a static type, as a C-level global, has no information about 
which module it belongs to. 
 
 
Slot methods 
------------ 
 
The above changes don't cover slot methods, such as ``tp_iter`` or ``nb_add``. 
 
The problem with slot methods is that their C API is fixed, so we can't 
simply add a new argument to pass in the defining class. 
Two possible solutions have been proposed to this problem: 
 
Â Â * Look up the class through walking the MRO. 
Â Â Â This is potentially expensive, but will be useful if performance is not 
Â Â Â a problem (such as when raising a module-level exception). 
Â Â * Storing a pointer to the defining class of each slot in a separate table, 
Â Â Â ``__typeslots__`` [#typeslots-mail]_.Â This is technically 
feasible and fast, 
Â Â Â but quite invasive. 
 
Due to the invasiveness of the latter approach, this PEP proposes 
adding an MRO walking 
helper for use in slot method implementations, deferring the more 
complex alternative 
as a potential future optimisation. Modules affected by this concern 
also have the 
option of using thread-local state or PEP 567 context variables, or 
else defining their 
own reload-friendly lookup caching scheme. </blockquote><div> </div><div>I do not believe walking the MRO is going to work without reworking the implementation of types, specifically how typeobject.c deals with slots of subclasses: in some cases copies the slots from the base class (see inherit_slots() and from where it's called). I believe this would cause problems if, for example, you define type X in module A, subclass it from type Y in module B without overriding the slot, and try to find the module object for A from the slot implementation. I don't think copying slots is a requirement for the desired semantics, but it's going to be fairly involved to rewrite it to do something else. There's also backward-compatibility to consider: third-party libraries can be inheriting from builtin types (e.g. numpy does this extensively) using the same copying-slot mechanism, which means those builtin types can't use the MRO walking to find their module without breaking compatibility with those third-party libraries.</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 
 
Immutable Exception Types 
------------------------- 
 
To faciliate creating static exception classes, a new function is proposed: 
``PyErr_PrepareImmutableException``. It will work similarly to 
``PyErr_NewExceptionWithDoc`` 
but will take a ``PyTypeObject **`` pointer, which points to a 
``PyTypeObject *`` that is 
either ``NULL`` or an initialized ``PyTypeObject``. 
This pointer may be declared in process-global state. The function will then 
allocate the object and will keep in mind that already existing exception 
should not be overwritten. 
 
The extra indirection makes it possible to make 
``PyErr_PrepareImmutableException`` 
part of the stable ABI by having the Python interpreter, rather than 
extension code, 
allocate the ``PyTypeObject``. 
 
 
Specification 
============= 
 
Adding module references to heap types 
-------------------------------------- 
 
The ``PyHeapTypeObject`` struct will get a new member, ``PyObject *ht_module``, 
that can store a pointer to the module object for which the type was defined. 
It will be ``NULL`` by default, and should not be modified after the type 
object is created. 
 
A new factory method will be added for creating modules:: 
 
Â Â PyObject* PyType_FromModuleAndSpec(PyObject *module, 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â PyType_Spec *spec, 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â PyObject *bases) 
 
This acts the same as ``PyType_FromSpecWithBases``, and additionally sets 
``ht_module`` to the provided module object. 
 
Additionally, an accessor, ``PyObject * PyType_GetModule(PyTypeObject *)`` 
will be provided. 
It will return the ``ht_module`` if a heap type with module pointer set 
is passed in, otherwise it will set a SystemError and return NULL. 
 
Usually, creating a class with ``ht_module`` set will create a reference 
cycle involving the class and the module. 
This is not a problem, as tearing down modules is not a performance-sensitive 
operation (and module-level functions typically also create reference cycles). 
The existing "set all module globals to None" code that breaks function cycles 
through ``f_globals`` will also break the new cycles through ``ht_module``. 
 
 
Passing the defining class to extension methods 
----------------------------------------------- 
 
A new style of C-level functions will be added to the current selection of 
``PyCFunction`` and ``PyCFunctionWithKeywords``:: 
 
Â Â PyObject *PyCMethod(PyObject *self, 
Â Â Â Â Â Â Â Â Â Â Â Â PyTypeObject *defining_class, 
Â Â Â Â Â Â Â Â Â Â Â Â PyObject *args, PyObject *kwargs) 
 
A new method object flag, ``METH_METHOD``, will be added to signal that 
the underlying C function is ``PyCMethod``. 
 
To hold the extra information, a new structure extending ``PyCFunctionObject`` 
will be added:: 
 
Â Â typedef struct { 
Â Â Â Â PyCFunctionObject func; 
Â Â Â Â PyTypeObject *mm_class; /* Passed as 'defining_class' arg to 
the C func */ 
Â Â } PyCMethodObject; 
 
To allow passing the defining class to the underlying C function, a change 
to private API is required, now ``_PyMethodDef_RawFastCallDict`` and 
``_PyMethodDef_RawFastCallKeywords`` will receive ``PyTypeObject *cls`` 
as one of their arguments. 
 
A new macro ``PyCFunction_GET_CLASS(cls)`` will be added for easier 
access to mm_class. 
 
Method construction and calling code and will be updated to honor 
``METH_METHOD``. 
 
 
Argument Clinic 
--------------- 
 
To support passing the defining class to methods using Argument Clinic, 
a new converter will be added to clinic.py: ``defining_class``. 
 
Each method may only have one argument using this converter, and it must 
appear after ``self``, or, if ``self`` is not used, as the first argument. 
The argument will be of type ``PyTypeObject *``. 
 
When used, Argument Clinic will select ``METH_METHOD`` as the calling 
convention. 
The argument will not appear in ``__text_signature__``. 
 
This will be compatible with ``__init__`` and ``__new__`` methods, where an 
MRO walker will be used to pass the defining class from clinic generated 
code to the user's function. 
 
 
Slot methods 
------------ 
 
To allow access to per-module state from slot methods, an MRO walker 
will be implemented:: 
 
Â Â PyTypeObject *PyType_DefiningTypeFromSlotFunc(PyTypeObject *type, 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â int slot, void *func) 
 
The walker will go through bases of heap-allocated ``type`` 
and search for class that defines ``func`` at its ``slot``. 
 
The ``func`` needs not to be inherited by ``type``, only requirement 
for the walker to find the defining class is that the defining class 
must be heap-allocated. 
 
On failure, exception is set and NULL is returned. 
 
 
Static exceptions 
----------------- 
 
A new function will be added:: 
 
Â Â int PyErr_PrepareImmutableException(PyTypeObject **exc, 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â const char *name, 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â const char *doc, 
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â PyObject *base) 
 
Creates an immutable exception type which can be shared 
across multiple module objects. </blockquote><div> </div><div>How is this going to deal with type.__subclasses__()? Is re-using the static type object between reloads and sub-interpreters important enough to warrant the different behaviour? What if sub-interpreters end up wanting to disallow sharing objects between them?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the type already exists (determined by a process-global pointer, 
``*exc``), skip the initialization and only ``INCREF`` it. 
 
If ``*exc`` is NULL, the function will 
allocate a new exception type and initialize it using given parameters 
the same way ``PyType_FromSpecAndBases`` would. 
The ``doc`` and ``base`` arguments may be ``NULL``, defaulting to a 
missing docstring and ``PyExc_Exception`` base class, respectively. 
The exception type's ``tp_flags`` will be set to values common to 
built-in exceptions and the ``Py_TPFLAGS_HEAP_IMMUTABLE`` flag (see below) 
will be set. 
On failure, ``PyErr_PrepareImmutableException`` will set an exception 
and return -1. 
 
If called with an initialized exception type (``*exc`` 
is non-NULL), the function will do nothing but incref ``*exc``. 
 
A new flag, ``Py_TPFLAGS_HEAP_IMMUTABLE``, will be added to prevent 
mutation of the type object. This makes it possible to 
share the object safely between multiple interpreters. 
This flag is checked in ``type_setattro`` and blocks 
setting of attributes when set, similar to built-in types. 
 
A new pointer, ``ht_moduleptr``, will be added to heap types to store ``exc``. 
 
On deinitialization of the exception type, ``*exc`` will be set to ``NULL``. 
This makes it safe for ``PyErr_PrepareImmutableException`` to check if 
the exception was already initialized. 
 
PyType_offsets 
-------------- 
 
Some extension types are using instances with ``__dict__`` or ``__weakref__`` 
allocated. Currently, there is no way of passing offsets of these through 
``PyType_Spec``. To allow this, a new structure and a spec slot are proposed. 
 
A new structure, ``PyType_offsets``, will have two members containing the 
offsets of ``__dict__`` and ``__weakref__``:: 
 
Â Â typedef struct { 
Â Â Â Â Py_ssize_t dict; 
Â Â Â Â Py_ssize_t weaklist; 
Â Â } PyType_offsets; 
 
The new slot, ``Py_offsets``, will be used to pass a ``PyType_offsets *`` 
structure containing the mentioned data. 
 
 
Helpers 
------- 
 
Getting to per-module state from a heap type is a very common task. To make this 
easier, a helper will be added:: 
 
Â Â void *PyType_GetModuleState(PyObject *type) 
 
This function takes a heap type and on success, it returns pointer to 
state of the 
module that the heap type belongs to. 
 
On failure, two scenarios may occure. When a type without a module is passed in, 
``SystemError`` is set and ``NULL`` returned. If the module is found, pointer 
to the state, which may be ``NULL``, is returned without setting any exception. 
 
 
Modules Converted in the Initial Implementation 
----------------------------------------------- 
 
To validate the approach, several modules will be modified during 
the initial implementation: 
 
The ``zipimport``, ``_io``, ``_elementtree``, and ``_csv`` modules 
will be ported to PEP 489 multiphase initialization. </blockquote><div> </div><div>zipimport currently caches things in C globals. Changing it to use PEP 489 multi-phase initialisation is very likely going to change semantics in subtle ways... Is it really worth the risk?</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 
 
Summary of API Changes and Additions 
==================================== 
 
New functions: 
 
* PyType_GetModule 
* PyType_DefiningTypeFromSlotFunc 
* PyType_GetModuleState 
* PyErr_PrepareImmutableException 
 
New macros: 
 
* PyCFunction_GET_CLASS 
 
New types: 
 
* PyCMethodObject 
 
New structures: 
 
* PyType_offsets 
 
Modified functions: 
 
* _PyMethodDef_RawFastCallDict now receives ``PyTypeObject *cls``. 
* _PyMethodDef_RawFastCallKeywords now receives ``PyTypeObject *cls``. 
 
Modified structures: 
 
* _heaptypeobject - added ht_module and ht_moduleptr 
 
Other changes: 
 
* METH_METHOD call flag 
* defining_class converter in clinic 
* Py_TPFLAGS_HEAP_IMMUTABLE flag 
* Py_offsets type spec slot 
 
 
Backwards Compatibility 
======================= 
 
Two new pointers are added to all heap types. 
All other changes are adding new functions, structures and a type flag. 
 
The new ``PyErr_PrepareImmutableException`` function changes encourages 
modules to switch from using heap type Exception classes to immutable ones, 
and a number of modules will be switched in the initial implementation. 
This change will prevent adding class attributes to such types. 
For example, the following will raise AttributeError:: 
 
Â Â sqlite.OperationalError.foo = None 
 
Instances and subclasses of such exceptions will not be affected. 
 
Implementation 
============== 
 
An initial implementation is available in a Github repository [#gh-repo]_; 
a patchset is at [#gh-patch]_. 
 
 
Possible Future Extensions 
========================== 
 
Easy creation of types with module references 
--------------------------------------------- 
 
It would be possible to add a PEP 489 execution slot type to make 
creating heap types significantly easier than calling 
``PyType_FromModuleAndSpec``. 
This is left to a future PEP. 
 
 
Optimization 
------------ 
 
CPython optimizes calls to methods that have restricted signatures, 
such as not allowing keyword arguments. 
 
As proposed here, methods defined with the ``METH_METHOD`` flag do not support 
these optimizations. 
 
Optimized calls still have the option of accessing per-module state 
the same way slot methods do. 
 
 
References 
========== 
 
.. [#typeslots-mail] [Import-SIG] On singleton modules, heap types, 
and subinterpreters 
Â Â (<a href="https://mail.python.org/pipermail/import-sig/2015-July/001035.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/import-sig/2015-July/001035.html</a>) 
 
.. [#gh-repo] 
Â Â <a href="https://github.com/Traceur759/cpython/commits/pep-c" rel="noreferrer" target="_blank">https://github.com/Traceur759/cpython/commits/pep-c</a> 
 
.. [#gh-patch] 
Â Â <a href="https://github.com/Traceur759/cpython/compare/master...Traceur759:pep-c.patch" rel="noreferrer" target="_blank">https://github.com/Traceur759/cpython/compare/master...Traceur759:pep-c.patch</a> 
 
 
Copyright 
========= 
 
This document has been placed in the public domain. 
_______________________________________________ 
Python-Dev mailing list 
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a> 
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a> 
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/thomas%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/thomas%40python.org</a> 
</blockquote></div> <div> </div>-- <div class="gmail_signature" data-smartmail="gmail_signature">Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank">thomas@python.org</a>> Hi! I'm an email virus! Think twice before sending your email to help me spread!</div>
</div></div>

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4