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
On Wed, May 22, 2013 at 9:18 PM, Carlos Nepomuceno <
carlosnepomuc...@outlook.com> wrote:
>
> > From: eli...@gmail.com
> [...]
> > I've found the following declaration in 'Objects/stringobject.c' but it
> > just defines _Py_InsertThousandsGrouping() as
> > _PyStrin
> From: eli...@gmail.com
[...]
> I've found the following declaration in 'Objects/stringobject.c' but it
> just defines _Py_InsertThousandsGrouping() as
> _PyString_InsertThousandsGrouping():
>
> "#define _Py_InsertThousandsGrouping _PyString_InsertThousands
On Wed, May 22, 2013 at 8:53 PM, Carlos Nepomuceno <
carlosnepomuc...@outlook.com> wrote:
> Hi guys!
>
> Can someone explain to me where in the CPython 2.7.5 source code is
> _PyString_InsertThousandsGrouping() implemented?
>
> I've found the following declaration in 'Objects/stringobject.c' but i
Hi guys!
Can someone explain to me where in the CPython 2.7.5 source code is
_PyString_InsertThousandsGrouping() implemented?
I've found the following declaration in 'Objects/stringobject.c' but it just
defines _Py_InsertThousandsGrouping() as _PyString_InsertThousandsGrouping():
"#define _Py_
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
> From: krist...@ccpgames.com
> To: g...@krypto.org; solip...@pitrou.net
> Date: Wed, 22 May 2013 19:49:31 +
> CC: python-dev@python.org
> Subject: Re: [Python-Dev] PEP 442 delegate
>
>
> Stackless python, already with their own special handling of GC
Stackless python, already with their own special handling of GC finalization,
is excited by this development :)
K
From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org]
On Behalf Of Gregory P. Smith
Sent: 22. maí 2013 07:03
To: Antoine Pitrou
Cc: Python-Dev
Subject: Re: [P
+1 I second the scoundrel!
fwiw, that pep being implemented is going to be a great addition to Python.
:)
On Tue, May 21, 2013 at 8:57 AM, Antoine Pitrou wrote:
>
> Hello,
>
> I would like to nominate Benjamin as BDFL-Delegate for PEP 442.
> Please tell me if you would like to object :)
>
> R
16 matches
Mail list logo
