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 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
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
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
cause
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 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, name
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
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.
S
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
> 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 mailin
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
40 matches
Mail list logo
