On Fri, May 31, 2013 at 3:13 PM, Chris McDonough wrote:
> On Fri, 2013-05-31 at 03:05 +0200, Łukasz Langa wrote:
>> On 31 maj 2013, at 01:51, Łukasz Langa wrote:
>>
>
>> Back to the point, though. I don't feel we should complicate the
>> code, tests and documentation by introducing special handli
On Fri, 2013-05-31 at 03:05 +0200, Łukasz Langa wrote:
> On 31 maj 2013, at 01:51, Łukasz Langa wrote:
>
> Back to the point, though. I don't feel we should complicate the
> code, tests and documentation by introducing special handling
> for methods. In terms of pure type-driven single dispatch,
On 31 maj 2013, at 01:51, Łukasz Langa wrote:
> On 31 maj 2013, at 01:47, Łukasz Langa wrote:
>
>> class State:
>>def __init__(self):
>>self.add.register(int, self.add_int)
>
> Ouch, I realized this is wrong just after I hit "Send".
> self.add is a staticmethod so this registration
On 31 maj 2013, at 01:47, Łukasz Langa wrote:
> class State:
>def __init__(self):
>self.add.register(int, self.add_int)
Ouch, I realized this is wrong just after I hit "Send". self.add is a
staticmethod so this registration will overload on every instance. Which is
obviously bad.
On 29 maj 2013, at 04:40, Nick Coghlan wrote:
> I expect we will see improved tools for integrating class based
> dispatch and generic function dispatch in the future, but we should
> *not* try to engineer a solution up front. Doing so would involve too
> much guessing about possible use cases, r
On Wed, 29 May 2013 08:08:14 +0200
Antoine Pitrou wrote:
> On Wed, 29 May 2013 12:40:32 +1000
> Nick Coghlan wrote:
> > On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen wrote:
> > > In article ,
> > > Łukasz Langa wrote:
> > >
> > >> Hello,
> > >> Since the initial version, several minor chang
On Wed, 29 May 2013 12:40:32 +1000
Nick Coghlan wrote:
> On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen wrote:
> > In article ,
> > Łukasz Langa wrote:
> >
> >> Hello,
> >> Since the initial version, several minor changes have been made to the
> >> PEP. The history is visible on hg.python.org
On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen wrote:
> In article ,
> Łukasz Langa wrote:
>
>> Hello,
>> Since the initial version, several minor changes have been made to the
>> PEP. The history is visible on hg.python.org. The most important
>> change in this version is that I introduced AB
On 29/05/13 07:27, PJ Eby wrote:
On Tue, May 28, 2013 at 3:41 PM, Russell E. Owen wrote:
Is it true that this cannot be used for instance and class methods? It
dispatches based on the first argument, which is "self" for instance
methods, whereas the second argument would almost certainly be the
On Tue, May 28, 2013 at 3:41 PM, Russell E. Owen wrote:
> Is it true that this cannot be used for instance and class methods? It
> dispatches based on the first argument, which is "self" for instance
> methods, whereas the second argument would almost certainly be the
> argument one would want to
A question about the example:
how hard would it be to modify the example
@fun.register(list)
...
to work with other collections? If it is easy, I think it would make a
for a much more useful example.
-- Russell
___
Python-Dev mailing list
Python-Dev@
In article ,
Åukasz Langa wrote:
> Hello,
> Since the initial version, several minor changes have been made to the
> PEP. The history is visible on hg.python.org. The most important
> change in this version is that I introduced ABC support and completed
> a reference implementation.
>
> No ope
On 27 maj 2013, at 15:31, Łukasz Langa wrote:
> This is exactly what I did now. I also exposed ._clear_cache() and the
> uncached ._find_impl() if somebody finds it necessary to use it. Both
> are left undocumented.
For the record, I moved _find_impl out of the closure for easier
testability. I
On 26 maj 2013, at 03:37, Nick Coghlan wrote:
> On Sun, May 26, 2013 at 9:07 AM, PJ Eby wrote:
>> On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa wrote:
>>> So, the latest document is live:
>>> http://www.python.org/dev/peps/pep-0443/
>>>
>>> The code is here:
>>> http://hg.python.org/features/p
On 26 maj 2013, at 01:07, PJ Eby wrote:
> The PEP uses the term "implementation", and I think that
> actually makes a lot of sense: a generic function is composed of
> functions that implement the same operation for different types.
All suggested changes applied. There are still a couple of ment
On 26/05/13 09:07, PJ Eby wrote:
"""
Transforms a function into a single-dispatch generic function. A **generic
function** is composed of multiple functions implementing the same
operation for different types. Which
implementation should be used during a call is determined by the
dispatch algori
On Sun, May 26, 2013 at 9:07 AM, PJ Eby wrote:
> On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa wrote:
>> So, the latest document is live:
>> http://www.python.org/dev/peps/pep-0443/
>>
>> The code is here:
>> http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l363
Hmm, I find the us
On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa wrote:
> So, the latest document is live:
> http://www.python.org/dev/peps/pep-0443/
>
> The code is here:
> http://hg.python.org/features/pep-443/file/tip/Lib/functools.py#l363
>
> The documentation here:
> http://hg.python.org/features/pep-443/file/t
On Sat, 25 May 2013 22:16:04 +0200
Łukasz Langa wrote:
> On 25 maj 2013, at 17:13, Nick Coghlan wrote:
>
> > So I think I'd prefer flipping this around - you can't provide a
> > custom registry mapping, but you *can* get access to a read only view
> > of it through a "registry" attribute on the
On 25 maj 2013, at 17:13, Nick Coghlan wrote:
> So I think I'd prefer flipping this around - you can't provide a
> custom registry mapping, but you *can* get access to a read only view
> of it through a "registry" attribute on the generic function.
You guys convinced me. Both the PEP and the imp
On Sun, May 26, 2013 at 2:48 AM, PJ Eby wrote:
> On Sat, May 25, 2013 at 10:59 AM, Nick Coghlan wrote:
>> Given the global nature of the cache invalidation, it may be better as
>> a module level abc.get_cache_token() function.
>
> Well, since the only reason to ever use it is to improve performan
On Sat, May 25, 2013 at 10:59 AM, Nick Coghlan wrote:
> Given the global nature of the cache invalidation, it may be better as
> a module level abc.get_cache_token() function.
Well, since the only reason to ever use it is to improve performance,
it'd be better to expose it as an attribute than as
On Sun, May 26, 2013 at 1:09 AM, Łukasz Langa wrote:
> On 25 maj 2013, at 16:59, Nick Coghlan wrote:
>
> I think I added an issue on the tracker for that somewhere... yup:
> http://bugs.python.org/issue16832
>
> Given the global nature of the cache invalidation, it may be better as
> a module lev
On Sun, May 26, 2013 at 12:53 AM, Łukasz Langa wrote:
> On 25 maj 2013, at 16:08, PJ Eby wrote:
>
>> ISTM there should be some way to get at the raw
>> registration info, perhaps by exposing a dictproxy for the registry.
>
> Is that really useful? Just today Antoine asked about changing
> behavio
On 25 maj 2013, at 16:59, Nick Coghlan wrote:
> I think I added an issue on the tracker for that somewhere... yup:
> http://bugs.python.org/issue16832
>
> Given the global nature of the cache invalidation, it may be better as
> a module level abc.get_cache_token() function.
I assigned myself to
On Sun, May 26, 2013 at 12:08 AM, PJ Eby wrote:
> On Sat, May 25, 2013 at 8:08 AM, Łukasz Langa wrote:
>> The most important
>> change in this version is that I introduced ABC support and completed
>> a reference implementation.
>
> Excellent! A couple of thoughts on the implementation...
>
> Wh
On 25 maj 2013, at 16:08, PJ Eby wrote:
> ISTM there should be some way to get at the raw
> registration info, perhaps by exposing a dictproxy for the registry.
Is that really useful? Just today Antoine asked about changing
behaviour of __subclasses__(), suspecting it isn't used in real world
co
On Sat, May 25, 2013 at 8:08 AM, Łukasz Langa wrote:
> The most important
> change in this version is that I introduced ABC support and completed
> a reference implementation.
Excellent! A couple of thoughts on the implementation...
While the dispatch() method allows you to look up what impleme
Hello,
Since the initial version, several minor changes have been made to the
PEP. The history is visible on hg.python.org. The most important
change in this version is that I introduced ABC support and completed
a reference implementation.
No open issues remain from my point of view.
PEP: 443
On 24 maj 2013, at 14:53, Ronan Lamy wrote:
>> 2013/5/24 Łukasz Langa
>>
>> I recognize the need for such behaviour to be discoverable. This is
>> important for debugging purposes. This is why I'm going to let users
>> inspect registered overloads, as well as provide their own mapping
>> for th
On Fri, May 24, 2013 at 10:22 PM, Ronan Lamy wrote:
> Raise a ValueError, maybe? In that case, there needs to be a way to force
> the overriding when it is explicitly desired. One way would be to allow
> unregistering implementations: overriding is then done by unregistering the
> old implementati
On 24 maj 2013, at 14:22, Ronan Lamy wrote:
>> 2013/5/24 Ethan Furman
>> What would you suggest happen in this case?
> Raise a ValueError, maybe? In that case, there needs to be a way to force the
> overriding when it is explicitly desired. One way would be to allow
> unregistering implementa
2013/5/24 Ethan Furman
> On 05/23/2013 02:02 PM, Ronan Lamy wrote:
>
>> 2013/5/23 Łukasz Langa mailto:luk...@langa.pl>>
>>
>>
>> On 23 maj 2013, at 20:13, Éric Araujo > mer...@netwok.org>> wrote:
>>
>> > Question: what happens if two functions (say in two different
>> modules)
>> > ar
On Fri, May 24, 2013 at 7:54 PM, Sam Partington
wrote:
> But isn't it much much worse than names in scope, as with assigning
> names in a scope it is only your scope that is affected :
>
> from os.path import join
> def join(wibble):
> 'overloads join in this module only'
>
> any other module
On Fri, May 24, 2013 at 9:41 PM, Nick Coghlan wrote:
> Furthermore, the proposed registration syntax in the PEP is identical
> to the syntax which already exists for ABC registration as a class
> decorator (http://docs.python.org/3/library/abc#abc.ABCMeta.register).
Sorry, I withdraw that observa
On Fri, May 24, 2013 at 8:53 PM, Steven D'Aprano wrote:
> Python built-ins and the standard library already have a standard idiom for
> specifying multiple values at once. A tuple of types is the One Obvious Way
> to do this:
>
> @fun.register((float, Decimal))
It's not obvious, it's ambiguous -
On 24/05/13 15:09, Nick Coghlan wrote:
On Fri, May 24, 2013 at 8:40 AM, Steven D'Aprano wrote:
I don't think that they will. Being able to register multiple types with a
single call reads very naturally to me, while multiple decorators still
looks weird. Even after many years of seeing them, I
On Thu, May 23, 2013 at 6:40 PM, Steven D'Aprano wrote:
> I don't think that they will. Being able to register multiple types with a
> single call reads very naturally to me, while multiple decorators still
> looks weird. Even after many years of seeing them, I still get a momentary
> "What the he
On 23 May 2013 22:02, Ronan Lamy wrote:
> 2013/5/23 Łukasz Langa
>> Last one wins. Just like with assigning names in a scope, defining methods
>> in a class or overriding them in a subclass.
>
> This is a serious annoyance, considering that there are several places where
> a large library can rea
On Thu, May 23, 2013 at 11:57 PM, Nick Coghlan wrote:
> We should be able to use it to help deal with the "every growing
> importer API" problem, too. I know that's technically what pkgutil
> already uses it for, but elevating this from "pkgutil implementation
> detail" to "official stdlib functio
On Fri, May 24, 2013 at 8:40 AM, Steven D'Aprano wrote:
> I don't think that they will. Being able to register multiple types with a
> single call reads very naturally to me, while multiple decorators still
> looks weird. Even after many years of seeing them, I still get a momentary
> "What the he
On Fri, May 24, 2013 at 10:31 AM, PJ Eby wrote:
> On Thu, May 23, 2013 at 6:58 PM, Ben Hoyt wrote:
>> It seems no one has provided
>> decent use-case examples (apart from contrived ones)
>
> Um, copy.copy(), pprint.pprint(), a bunch of functions in pkgutil
> which are actually *based on this impl
On Fri, May 24, 2013 at 11:45 AM, Eric Snow wrote:
> On Thu, May 23, 2013 at 7:30 PM, Eric Snow
> wrote:
>> If there were more
>> discussion and consensus on annotations + decorators I'd be more convinced.
>
> However, this PEP should not be gated on any such discussion.
Right, I think the late
On Thu, May 23, 2013 at 7:30 PM, Eric Snow wrote:
> If there were more
> discussion and consensus on annotations + decorators I'd be more convinced.
However, this PEP should not be gated on any such discussion.
-eric
___
Python-Dev mailing list
Python-
On May 23, 2013 4:37 PM, "Steven D'Aprano" wrote:
>
> On 24/05/13 01:04, Ethan Furman wrote:
>> If the stdlib is still staying out of the annotation business, then it
should not be allowed.
>
>
>
> Perhaps it is time to relax that ruling? The standard library acts as a
guide to best practice in Py
On 05/23/2013 02:02 PM, Ronan Lamy wrote:
2013/5/23 Łukasz Langa mailto:luk...@langa.pl>>
On 23 maj 2013, at 20:13, Éric Araujo mailto:mer...@netwok.org>> wrote:
> Question: what happens if two functions (say in two different modules)
> are registered for the same type?
Last on
On Thu, May 23, 2013 at 6:58 PM, Ben Hoyt wrote:
> It seems no one has provided
> decent use-case examples (apart from contrived ones)
Um, copy.copy(), pprint.pprint(), a bunch of functions in pkgutil
which are actually *based on this implementation already* and have
been since Python 2.5... I d
> So I am a strong +1 on allowing multiple types to be registered in one call.
Yeah, agreed. It also fits the pattern set by isinstance(), which
allows a tuple of types, like isinstance(x, (int, str)).
That said, I'm +0 on this PEP itself. It seems no one has provided
decent use-case examples (ap
On 24/05/13 02:56, Paul Moore wrote:
On 23 May 2013 17:00, Walter Dörwald wrote:
Should it be possible to register multiple types for the generic function
with one register() call, i.e. should:
@fun.register(int, float)
def _(arg, verbose=False):
...
be allowed as a synonym fo
On 24/05/13 01:04, Ethan Furman wrote:
On 05/23/2013 07:58 AM, Łukasz Langa wrote:
I feel that the PEP should explicitly allow or disallow for the
implementation to accept dispatch on annotations, e.g.:
@func.register
def _(arg: int):
...
versus
@func.register(int)
def _(arg):
...
I
Le 23/05/2013 16:10, Łukasz Langa a écrit :
>> Does this work if the implementation function is called like the first
>> decorated function?
> No, the ``register()`` attribute returns the undecorated function which
> enables decorator stacking, as well as creating unit tests for each
> variant inde
2013/5/23 Łukasz Langa
> On 23 maj 2013, at 20:13, Éric Araujo wrote:
>
> > Question: what happens if two functions (say in two different modules)
> > are registered for the same type?
>
> Last one wins. Just like with assigning names in a scope, defining methods
> in a class or overriding them
On 05/23/2013 01:10 PM, Łukasz Langa wrote:
On 23 maj 2013, at 20:59, PJ Eby wrote:
As to the ability to do multiple types registration, you could support
it only in type annotations, e.g.:
@func.register
def doit(foo: [int, float]):
...
Initially I thought so, too. But it s
On 23 maj 2013, at 20:13, Éric Araujo wrote:
> Does this work if the implementation function is called like the first
> decorated function?
No, the ``register()`` attribute returns the undecorated function which
enables decorator stacking, as well as creating unit tests for each
variant independ
On 23 maj 2013, at 20:59, PJ Eby wrote:
> As to the ability to do multiple types registration, you could support
> it only in type annotations, e.g.:
>
>@func.register
>def doit(foo: [int, float]):
>...
Initially I thought so, too. But it seems other people might think this
mean
On Thu, May 23, 2013 at 2:59 PM, PJ Eby wrote:
> I generally lean towards returning the undecorated function, so that if you
> say:
>
> @func.register
> def do_int(foo: int):
> ...
Oops, forgot to mention: one other advantage to returning the
undecorated function is that you can
On 05/23/2013 11:13 AM, Éric Araujo wrote:
Thanks for writing this PEP. Blessing one implementation for the stdlib
and one official backport will make programmers’ lives a bit easier :)
>>> @fun.register(int)
... def _(arg, verbose=False):
... if verbose:
... print("St
On Thu, May 23, 2013 at 11:11 AM, Paul Moore wrote:
> Is the debate between 1 and 2, or 1 and 3? Is it even possible to implement
> 3 without having 2 different names for "register"?
Yes. You could do it as either:
@func.register
def doit(foo: int):
...
by checking for the first
User API
To define a generic function, decorate it with the ``@singledispatch``
decorator. Note that the dispatch happens on the type of the first
argument, create your function accordingly:
.. code-block:: pycon
>>> from functools import singledispatch
>>> @singledispatch
...
Hi,
Thanks for writing this PEP. Blessing one implementation for the stdlib
and one official backport will make programmers’ lives a bit easier :)
> >>> @fun.register(int)
> ... def _(arg, verbose=False):
> ... if verbose:
> ... print("Strength in numbers, eh?", end=" ")
>
On 23 May 2013 17:00, Walter Dörwald wrote:
> Should it be possible to register multiple types for the generic function
> with one register() call, i.e. should:
>
>@fun.register(int, float)
>def _(arg, verbose=False):
> ...
>
> be allowed as a synonym for
>
>@fun.register(int)
>
On 23.05.13 00:33, Łukasz Langa wrote:
Hello,
I would like to submit the following PEP for discussion and evaluation.
PEP: 443
Title: Single-dispatch generic functions
[...]
>>> @fun.register(int)
... def _(arg, verbose=False):
... if verbose:
... print("Strength in num
On 05/23/2013 07:58 AM, Łukasz Langa wrote:
On 23 maj 2013, at 16:49, Guido van Rossum wrote:
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
There's one. Quoting the PEP:
"The dispatch type is currently specified as a decorator argument. The
implementation could a
Ok, happy bikeshedding. I'm outta here until that's settled. :-)
On Thu, May 23, 2013 at 7:58 AM, Łukasz Langa wrote:
> On 23 maj 2013, at 16:49, Guido van Rossum wrote:
>
>> Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
>
> There's one. Quoting the PEP:
>
> "The disp
On 23 May 2013 15:58, Łukasz Langa wrote:
> On 23 maj 2013, at 16:49, Guido van Rossum wrote:
>
> > Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
>
> There's one. Quoting the PEP:
>
> "The dispatch type is currently specified as a decorator argument. The
> implementat
On 23 maj 2013, at 16:49, Guido van Rossum wrote:
> Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
There's one. Quoting the PEP:
"The dispatch type is currently specified as a decorator argument. The
implementation could allow a form using argument annotations. This u
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
On 23 maj 2013, at 09:33, Armin Rigo wrote:
> Hi,
>
> On Thu, May 23, 2013 at 12:33 AM, Łukasz Langa wrote:
>> Alternative approaches
>> ==
>
> You could also mention "pairtype", used in PyPy:
Thanks for pointing that out. Information on it added
in http://hg.python.org/pe
On 23 maj 2013, at 01:16, Terry Jan Reedy wrote:
> I like the general idea. Does you have any specific stdlib use cases in mind?
>
> I thought of pprint, which at some point dispatches on dict versus
> set/sequence, but overall it seems more complicated than mere arg type
> dispatch.
I want t
Le Thu, 23 May 2013 00:31:38 -0700,
Glenn Linderman a écrit :
>
> I suspect the point was not that add can be described as doing single
> dispatch (it can't), but rather that add could possibly be
> implemented in terms of lower-level functions doing single dispatch.
> If that was the point, per
On 5/23/2013 12:14 AM, Antoine Pitrou wrote:
On Thu, 23 May 2013 02:33:57 -0400
Devin Jeanpierre wrote:
>On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou wrote:
> >On Thu, 23 May 2013 12:12:26 +1000
> >Nick Coghlan wrote:
> >>The binary operators can be more accurately said to use a complica
On 23 May 2013 16:37, "Devin Jeanpierre" wrote:
>
> On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou
wrote:
> > On Thu, 23 May 2013 12:12:26 +1000
> > Nick Coghlan wrote:
> >> The binary operators can be more accurately said to use a complicated
> >> single-dispatch dance rather than supporting n
Hi,
On Thu, May 23, 2013 at 12:33 AM, Łukasz Langa wrote:
> Alternative approaches
> ==
You could also mention "pairtype", used in PyPy:
https://bitbucket.org/pypy/pypy/raw/default/rpython/tool/pairtype.py
(very short code). It's originally about adding double-dispatch, but
On Thu, 23 May 2013 02:33:57 -0400
Devin Jeanpierre wrote:
> On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou wrote:
> > On Thu, 23 May 2013 12:12:26 +1000
> > Nick Coghlan wrote:
> >> The binary operators can be more accurately said to use a complicated
> >> single-dispatch dance rather than sup
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou wrote:
> On Thu, 23 May 2013 12:12:26 +1000
> Nick Coghlan wrote:
>> The binary operators can be more accurately said to use a complicated
>> single-dispatch dance rather than supporting native dual-dispatch.
>
> Not one based on the type of a singl
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlan wrote:
> On Thu, May 23, 2013 at 10:14 AM, Glenn Linderman
> wrote:
> > Yet about half of the operator overloads would be incomplete if there were
> > not corresponding __r*__ methods (__radd__, __rsub__, etc.) because the
> > second parameter is a
Funny. I thought that the PEP was quite strong enough already in its
desire to stay away from multi-dispatch. But sure, I don't mind making
it stronger. :-)
On Wed, May 22, 2013 at 7:12 PM, Nick Coghlan wrote:
> On Thu, May 23, 2013 at 10:14 AM, Glenn Linderman
> wrote:
>> Yet about half of the
On Thu, May 23, 2013 at 10:14 AM, Glenn Linderman wrote:
> Yet about half of the operator overloads would be incomplete if there were
> not corresponding __r*__ methods (__radd__, __rsub__, etc.) because the
> second parameter is as key to the dispatch as the first.
>
> While unary operators, and
On Wed, May 22, 2013 at 5:14 PM, Glenn Linderman wrote:
> Yet about half of the operator overloads would be incomplete if there were
> not corresponding __r*__ methods (__radd__, __rsub__, etc.) because the
> second parameter is as key to the dispatch as the first.
This (and your subsequent argum
On 5/22/2013 5:55 PM, Guido van Rossum wrote:
On Wed, May 22, 2013 at 5:14 PM, Glenn Linderman wrote:
Yet about half of the operator overloads would be incomplete if there were
not corresponding __r*__ methods (__radd__, __rsub__, etc.) because the
second parameter is as key to the dispatch as
On 5/22/2013 3:33 PM, Łukasz Langa wrote:
2. does not have a standard way for methods to be added to existing
generic functions (i.e., some are added using registration
functions, others require defining ``__special__`` methods, possibly
by monkeypatching).
I assume you are talking
I like the general idea. Does you have any specific stdlib use cases in
mind?
I thought of pprint, which at some point dispatches on dict versus
set/sequence, but overall it seems more complicated than mere arg type
dispatch.
Unittest.TestCase.assertEqual mostly (but not completely) uses fir
Hello,
I would like to submit the following PEP for discussion and evaluation.
PEP: 443
Title: Single-dispatch generic functions
Version: $Revision$
Last-Modified: $Date$
Author: Łukasz Langa
Discussions-To: Python-Dev
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 22-May
83 matches
Mail list logo
