On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Thu, May 23, 2013 at 10:14 AM, Glenn Linderman v+pyt...@g.nevcal.com
wrote:
Yet about half of the operator overloads would be incomplete if there were
not corresponding __r*__ methods (__radd__, __rsub__, etc.)
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The binary operators can be more accurately said to use a complicated
single-dispatch dance rather than supporting native dual-dispatch.
Not
On Thu, 23 May 2013 02:33:57 -0400
Devin Jeanpierre jeanpierr...@gmail.com wrote:
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The binary operators can be more accurately said to use a
Hi,
On Thu, May 23, 2013 at 12:33 AM, Łukasz Langa luk...@langa.pl 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
On 23 May 2013 16:37, Devin Jeanpierre jeanpierr...@gmail.com wrote:
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlan ncogh...@gmail.com wrote:
The binary operators can be more accurately said to use a complicated
On 5/23/2013 12:14 AM, Antoine Pitrou wrote:
On Thu, 23 May 2013 02:33:57 -0400
Devin Jeanpierrejeanpierr...@gmail.com wrote:
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrousolip...@pitrou.net wrote:
On Thu, 23 May 2013 12:12:26 +1000
Nick Coghlanncogh...@gmail.com wrote:
The binary
Le Thu, 23 May 2013 00:31:38 -0700,
Glenn Linderman v+pyt...@g.nevcal.com 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
Didn't know about Stackless Python. Is it faster than CPython?
I'm developing an application that takes more than 5000 active threads,
sometimes up to 10.
Will it benefit from Stackless Python?
Can I use it for WSGI with Apache httpd?
Stackless has its own website and mailing list.
On 23 maj 2013, at 01:16, Terry Jan Reedy tjre...@udel.edu 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
Am 21.05.13 18:03, schrieb Ethan Furman:
And, of course, we only make these changes when we're already modifying
the module for some other reason.
In the specific case, the KeyError has indeed useful information that
the TypeError does not, namely the specific character that is the culprit.
So
On 23 maj 2013, at 09:33, Armin Rigo ar...@tunes.org wrote:
Hi,
On Thu, May 23, 2013 at 12:33 AM, Łukasz Langa luk...@langa.pl wrote:
Alternative approaches
==
You could also mention pairtype, used in PyPy:
Thanks for pointing that out. Information on it added
in
On 05/23/2013 04:36 AM, Martin v. Löwis wrote:
Am 21.05.13 18:03, schrieb Ethan Furman:
And, of course, we only make these changes when we're already modifying
the module for some other reason.
In the specific case, the KeyError has indeed useful information that
the TypeError does not,
Ł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:
On 23 maj 2013, at 16:49, Guido van Rossum gu...@python.org 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
On 23 May 2013 15:58, Łukasz Langa luk...@langa.pl wrote:
On 23 maj 2013, at 16:49, Guido van Rossum gu...@python.org 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
Ok, happy bikeshedding. I'm outta here until that's settled. :-)
On Thu, May 23, 2013 at 7:58 AM, Łukasz Langa luk...@langa.pl wrote:
On 23 maj 2013, at 16:49, Guido van Rossum gu...@python.org wrote:
Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP.
There's one.
On 05/23/2013 07:58 AM, Łukasz Langa wrote:
On 23 maj 2013, at 16:49, Guido van Rossum gu...@python.org 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
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
On 23 May 2013 17:00, Walter Dörwald wal...@livinglogic.de 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
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= )
...
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
... def
On Thu, May 23, 2013 at 11:11 AM, Paul Moore p.f.mo...@gmail.com 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
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:
...
On Thu, May 23, 2013 at 2:59 PM, PJ Eby p...@telecommunity.com 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
On 23 maj 2013, at 20:59, PJ Eby p...@telecommunity.com 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
On 23 maj 2013, at 20:13, Éric Araujo mer...@netwok.org 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
On 05/23/2013 01:10 PM, Łukasz Langa wrote:
On 23 maj 2013, at 20:59, PJ Eby p...@telecommunity.com 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
2013/5/23 Łukasz Langa 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)
are registered for the same type?
Last one wins. Just like with assigning names in a scope, defining methods
in a
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
On 24/05/13 00:24, Ethan Furman wrote:
Here's the code that existed at one point:
for c in s:
val = _b32rev.get(c)
if val is None:
raise TypeError('Non-base32 digit found')
Even though there is no KeyError to convert in this incarnation, providing the
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):
...
On 24/05/13 02:56, Paul Moore wrote:
On 23 May 2013 17:00, Walter Dörwald wal...@livinglogic.de 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
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
On Thu, May 23, 2013 at 6:58 PM, Ben Hoyt benh...@gmail.com 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
On 05/23/2013 02:02 PM, Ronan Lamy wrote:
2013/5/23 Łukasz Langa luk...@langa.pl mailto:luk...@langa.pl
On 23 maj 2013, at 20:13, Éric Araujo mer...@netwok.org
mailto:mer...@netwok.org wrote:
Question: what happens if two functions (say in two different modules)
are registered
On May 23, 2013 4:37 PM, Steven D'Aprano st...@pearwood.info 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
On Thu, May 23, 2013 at 7:30 PM, Eric Snow ericsnowcurren...@gmail.com 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
___
On Tue, 21 May 2013 06:36:54 -0700, Guido van Rossum wrote:
Actually changing __str__ or __repr__ is out of the question, best we
can do is discourage makingbthem different. But adding a protocol for
pprint (with extra parameters to convey options) is a fair idea. I note
that Nick sggested to
On Fri, May 24, 2013 at 11:45 AM, Eric Snow ericsnowcurren...@gmail.com wrote:
On Thu, May 23, 2013 at 7:30 PM, Eric Snow ericsnowcurren...@gmail.com
wrote:
If there were more
discussion and consensus on annotations + decorators I'd be more convinced.
However, this PEP should not be gated
On Fri, May 24, 2013 at 10:31 AM, PJ Eby p...@telecommunity.com wrote:
On Thu, May 23, 2013 at 6:58 PM, Ben Hoyt benh...@gmail.com 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
On Fri, May 24, 2013 at 8:40 AM, Steven D'Aprano st...@pearwood.info 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
41 matches
Mail list logo
