Re: [Python-Dev] PEP 442 delegate

2013-05-22 Thread Gregory P. Smith 
+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 :)
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 442 delegate

2013-05-22 Thread Kristján Valur Jónsson 
Stackless python, already with their own special handling of GC finalization, 
is excited by this development :)
K

From: Python-Dev [mailto:[email protected]] 
On Behalf Of Gregory P. Smith
Sent: 22. maí 2013 07:03
To: Antoine Pitrou
Cc: Python-Dev
Subject: Re: [Python-Dev] PEP 442 delegate

+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 
mailto:[email protected]>> wrote:

Hello,

I would like to nominate Benjamin as BDFL-Delegate for PEP 442.
Please tell me if you would like to object :)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 442 delegate

2013-05-22 Thread Carlos Nepomuceno 

> From: [email protected] 
> To: [email protected]; [email protected] 
> Date: Wed, 22 May 2013 19:49:31 + 
> CC: [email protected] 
> Subject: Re: [Python-Dev] PEP 442 delegate 
>  
>  
> Stackless python, already with their own special handling of GC  
> finalization, is excited by this development ☺ 
>  
> K 
>  

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?
  
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 443 - Single-dispatch generic functions

2013-05-22 Thread Łukasz Langa 
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-2013
Post-History: 22-May-2013
Replaces: 245, 246, 3124


Abstract


This PEP proposes a new mechanism in the ``functools`` standard library
module that provides a simple form of generic programming known as
single-dispatch generic functions.

A **generic function** is composed of multiple functions sharing the
same name. Which form should be used during a call is determined by the
dispatch algorithm. When the implementation is chosen based on the type
of a single argument, this is known as **single dispatch**.


Rationale and Goals
===

Python has always provided a variety of built-in and standard-library
generic functions, such as ``len()``, ``iter()``, ``pprint.pprint()``,
``copy.copy()``, and most of the functions in the ``operator`` module.
However, it currently:

1. does not have a simple or straightforward way for developers to
   create new generic functions,

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).

In addition, it is currently a common anti-pattern for Python code to
inspect the types of received arguments, in order to decide what to do
with the objects. For example, code may wish to accept either an object
of some type, or a sequence of objects of that type.

Currently, the "obvious way" to do this is by type inspection, but this
is brittle and closed to extension. Abstract Base Classes make it easier
to discover present behaviour, but don't help adding new behaviour.
A developer using an already-written library may be unable to change how
their objects are treated by such code, especially if the objects they
are using were created by a third party.

Therefore, this PEP proposes a uniform API to address dynamic
overloading using decorators.


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 fun(arg, verbose=False):
  ... if verbose:
  ... print("Let me just say,", end=" ")
  ... print(arg)

To add overloaded implementations to the function, use the
``register()`` attribute of the generic function. It takes a type
parameter:

.. code-block:: pycon

  >>> @fun.register(int)
  ... def _(arg, verbose=False):
  ... if verbose:
  ... print("Strength in numbers, eh?", end=" ")
  ... print(arg)
  ...
  >>> @fun.register(list)
  ... def _(arg, verbose=False):
  ... if verbose:
  ... print("Enumerate this:")
  ... for i, elem in enumerate(arg):
  ... print(i, elem)

To enable registering lambdas and pre-existing functions, the
``register()`` attribute can be used in a functional form:

.. code-block:: pycon

  >>> def nothing(arg, verbose=False):
  ... print("Nothing.")
  ...
  >>> fun.register(type(None), nothing)

When called, the function dispatches on the first argument:

.. code-block:: pycon

  >>> fun("Hello, world.")
  Hello, world.
  >>> fun("test.", verbose=True)
  Let me just say, test.
  >>> fun(42, verbose=True)
  Strength in numbers, eh? 42
  >>> fun(['spam', 'spam', 'eggs', 'spam'], verbose=True)
  Enumerate this:
  0 spam
  1 spam
  2 eggs
  3 spam
  >>> fun(None)
  Nothing.

The proposed API is intentionally limited and opinionated, as to ensure
it is easy to explain and use, as well as to maintain consistency with
existing members in the ``functools`` module.


Implementation Notes


The functionality described in this PEP is already implemented in the
``pkgutil`` standard library module as ``simplegeneric``. Because this
implementation is mature, the goal is to move it largely as-is. Several
open issues remain:

* the current implementation relies on ``__mro__`` alone, making it
  incompatible with Abstract Base Classes'
  ``register()``/``unregister()`` functionality. A possible solution has
  been proposed by PJE on the original issue for exposing
  ``pkgutil.simplegeneric`` as part of the ``functools`` API
  [#issue-5135]_.

* the dispatch type is currently specified as a decorator argument. The
  implementation could allow a form using argument annotations. This
  usage pattern is out of scope for the standard library [#pep-0008]_.
  However, whether this registration form would be acceptable for
  general usage, is up to debate.

Based on the current ``pkgutil.simplegeneric`` implementation and
following the convention on registering virtual subclasses on Ab

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

2013-05-22 Thread Terry Jan Reedy 
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 first arg 
dispatch based on an instance-specific dict, and it has an custom 
instance registration method addTypeEqualityFunc. (Since each test_xxx 
runs in a new instance, a registration for multiple methods has to be 
done either in a setup method or repeated in each test_method.)


Terry


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

2013-05-22 Thread Glenn Linderman 

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 about things like __add__, for operator 
overloading.  And later you mention:



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:


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 one argument functions would be fully covered 
by single dispatch, it is clear that single dispatch doesn't cover a 
large collection of useful cases for operator overloading.


It would seem appropriate to me for the PEP to explain why single 
dispatch is sufficient, in the presence of a large collection of 
operations for which it has been demonstrably shown to be 
insufficient... while the solution is already in place for such 
operations, single dispatch could clearly not be used as a replacement 
solution for those operations, opening the door to the thought that 
maybe single dispatch is an insufficiently useful mechanism, and that 
perhaps at least two arguments should be used for dispatch (when they 
exist).


On the other hand, when using function call notation instead of operator 
notation, maybe single dispatch is sufficient... still, non-commutative 
operations (subtract, divide, etc.) can be difficult to express without 
resorting to function names like "backwardsSubtract" (__rsub__).  But 
even with commutative operations between unlike objects, it may be that 
only one of the objects knows how to perform the operations and must be 
the one that controls the dispatch...


Granted, there are few ternary (or n-ary) operators that are not 
expressed using functional notation anyway, but certainly there is a 
case to be made for dispatch to happen based on types of all arguments. 
While that doesn't necessarily detract from the benefits of a single 
dispatch system, it does raise the question about whether single 
dispatch is sufficient, especially in the presence of a large collection 
of (binary) operations for which it is already known to be insufficient.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

2013-05-22 Thread Glenn Linderman 

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 the first.

This (and your subsequent argument) sounds like a typical case of
"perfection is the enemy of the good." Łukasz already pointed out that
for dispatch on multiple arguments, consensus has been elusive, and
there are some strong statements in opposition. While this does not
exclude the possibility that it might be easier to get consensus on
dual-argument dispatch, I think the case for dual-argument dispatch is
still much weaker than that for single-argument dispatch.

The binary operations, which you use as the primary example, are
already special because they correspond to syntactic forms. Python
intentionally does not have a generalized syntax to invoke arbitrary
binary operations, but only supports a small number of predefined
binary operators -- code in other languages (like Haskell) that uses
"unconventional" binary operators is usually hard to read except for
mathematicians.

Since the language already offers a way to do dual-argument dispatch
for the predefined operations, your proposed dual-argument dispatch
wouldn't be particularly useful for those. (And retrofitting it would
be a very tricky business, given the many subtleties in the existing
binary operator dispatch -- for example, did you know that there's a
scenario where __radd__ is tried *before* __add__?)

For standard function calls, it would be very odd if dual-dispatch
were supported but multiple-dispatch weren't. In general, 0, 1 and
infinity are fair game for special treatment, but treating 2 special
as well usually smells. So I'd say that Łukasz's single-dispatch
proposal covers a fairly important patch of new ground, while
dual-dispatch is both much harder and less useful. Ergo, Łukasz has
made the right trade-off.



Yep. The above, plus a recap of the arguments in opposition to multiple 
argument dispatch, would make the PEP stronger, which is all I was 
asking for. I sort of agree with his quote of Frederick Lundh, regarding 
the complexity of multiple argument dispatch, and multiple argument 
dispatch/overloading is one of the most complex things to understand and 
use in C++.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

2013-05-22 Thread Guido van Rossum 
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 argument) sounds like a typical case of
"perfection is the enemy of the good." Łukasz already pointed out that
for dispatch on multiple arguments, consensus has been elusive, and
there are some strong statements in opposition. While this does not
exclude the possibility that it might be easier to get consensus on
dual-argument dispatch, I think the case for dual-argument dispatch is
still much weaker than that for single-argument dispatch.

The binary operations, which you use as the primary example, are
already special because they correspond to syntactic forms. Python
intentionally does not have a generalized syntax to invoke arbitrary
binary operations, but only supports a small number of predefined
binary operators -- code in other languages (like Haskell) that uses
"unconventional" binary operators is usually hard to read except for
mathematicians.

Since the language already offers a way to do dual-argument dispatch
for the predefined operations, your proposed dual-argument dispatch
wouldn't be particularly useful for those. (And retrofitting it would
be a very tricky business, given the many subtleties in the existing
binary operator dispatch -- for example, did you know that there's a
scenario where __radd__ is tried *before* __add__?)

For standard function calls, it would be very odd if dual-dispatch
were supported but multiple-dispatch weren't. In general, 0, 1 and
infinity are fair game for special treatment, but treating 2 special
as well usually smells. So I'd say that Łukasz's single-dispatch
proposal covers a fairly important patch of new ground, while
dual-dispatch is both much harder and less useful. Ergo, Łukasz has
made the right trade-off.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

2013-05-22 Thread Nick Coghlan 
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 one argument functions would be fully covered by
> single dispatch, it is clear that single dispatch doesn't cover a large
> collection of useful cases for operator overloading.

The binary operators can be more accurately said to use a complicated
single-dispatch dance rather than supporting native dual-dispatch. As
you say, the PEP would be strengthened by pointing this out as an
argument in favour of staying *away* from a multi-dispatch system
(because it isn't obvious how to build a comprehensible one that would
even support our existing NotImplemented based dual dispatch system
for the binary operators).

Cheers,
Nick.

--
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

2013-05-22 Thread Guido van Rossum 
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 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 one argument functions would be fully covered by
>> single dispatch, it is clear that single dispatch doesn't cover a large
>> collection of useful cases for operator overloading.
>
> The binary operators can be more accurately said to use a complicated
> single-dispatch dance rather than supporting native dual-dispatch. As
> you say, the PEP would be strengthened by pointing this out as an
> argument in favour of staying *away* from a multi-dispatch system
> (because it isn't obvious how to build a comprehensible one that would
> even support our existing NotImplemented based dual dispatch system
> for the binary operators).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] _PyString_InsertThousandsGrouping()

2013-05-22 Thread Carlos Nepomuceno 
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_InsertThousandsGrouping _PyString_InsertThousandsGrouping"

I'm looking for the opposite!

I don't even know how that doesn't cause an error! What's the trick?

Besides that I've found a lot of code inside some header files, such as 
'Objects/stringlib/formatter.h'.

Why did you chose that way?

Thanks in advance.

Carlos
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] _PyString_InsertThousandsGrouping()

2013-05-22 Thread Eli Bendersky 
On Wed, May 22, 2013 at 8:53 PM, Carlos Nepomuceno <
[email protected]> 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 it
> just defines _Py_InsertThousandsGrouping() as
> _PyString_InsertThousandsGrouping():
>
> "#define _Py_InsertThousandsGrouping _PyString_InsertThousandsGrouping"
>
> I'm looking for the opposite!
>

No, you aren't :-)

#define _Py_InsertThousandsGrouping _PyString_InsertThousandsGrouping
#include "stringlib/localeutil.h"

Now look inside "stringlib/localeutil.h" and think what the pre-processor
does with the function definition having the #define above.

Eli



>
> I don't even know how that doesn't cause an error! What's the trick?
>
> Thanks in advance.
>
> Carlos
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] _PyString_InsertThousandsGrouping()

2013-05-22 Thread Carlos Nepomuceno 

> From: [email protected] 
[...]
> I've found the following declaration in 'Objects/stringobject.c' but it  
> just defines _Py_InsertThousandsGrouping() as  
> _PyString_InsertThousandsGrouping(): 
>  
> "#define _Py_InsertThousandsGrouping _PyString_InsertThousandsGrouping" 
>  
> I'm looking for the opposite! 
>  
> No, you aren't :-) 
>  
> #define _Py_InsertThousandsGrouping _PyString_InsertThousandsGrouping 
> #include "stringlib/localeutil.h" 
>  
> Now look inside "stringlib/localeutil.h" and think what the  
> pre-processor does with the function definition having the #define  
> above. 
>  
> Eli 

lol I can see clearly now! :p

That reminds me of "Which came first, the chicken or the egg?"

Thank you! Somehow I got intrigued by such use...

Do you know why they've put a lot of source code inside the header files?   
  
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] _PyString_InsertThousandsGrouping()

2013-05-22 Thread Eli Bendersky 
On Wed, May 22, 2013 at 9:18 PM, Carlos Nepomuceno <
[email protected]> wrote:

> 
> > From: [email protected]
> [...]
> > I've found the following declaration in 'Objects/stringobject.c' but it
> > just defines _Py_InsertThousandsGrouping() as
> > _PyString_InsertThousandsGrouping():
> >
> > "#define _Py_InsertThousandsGrouping _PyString_InsertThousandsGrouping"
> >
> > I'm looking for the opposite!
> >
> > No, you aren't :-)
> >
> > #define _Py_InsertThousandsGrouping _PyString_InsertThousandsGrouping
> > #include "stringlib/localeutil.h"
> >
> > Now look inside "stringlib/localeutil.h" and think what the
> > pre-processor does with the function definition having the #define
> > above.
> >
> > Eli
>
> lol I can see clearly now! :p
>
> That reminds me of "Which came first, the chicken or the egg?"
>
> Thank you! Somehow I got intrigued by such use...
>
> Do you know why they've put a lot of source code inside the header files?
> ___
>
>
This depends per use-case. Commonly, code is placed in header files in C to
achieve some sort of C++-template-like behavior with the preprocessor. In
particular, I think Objects/stringlib/formatter.h  does this. Note this
comment near its top:

/* Before including this, you must include either:
   stringlib/unicodedefs.h
   stringlib/stringdefs.h

   Also, you should define the names:
   FORMAT_STRING
   FORMAT_LONG
   FORMAT_FLOAT
   FORMAT_COMPLEX
   to be whatever you want the public names of these functions to
   be.  These are the only non-static functions defined here.
*/

Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

2013-05-22 Thread Antoine Pitrou 
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 as key to the dispatch as the first.
> >
> > While unary operators, and one argument functions would be fully covered by
> > single dispatch, it is clear that single dispatch doesn't cover a large
> > collection of useful cases for operator overloading.
> 
> 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 single argument, though. I guess you can
also reduce every function of several arguments to a function accepting
a single tuple of several items, but that doesn't sound very
interesting.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

2013-05-22 Thread Devin Jeanpierre 
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 single argument, though.

Why not?

I'd expect it to look something like this:

@singledispatch
def ladd(left, right):
return NotImplemented

@singledispatch
def radd(right, left):
return NotImplemented

def add(left, right):
x = ladd(left, right)
if x is not NotImplemented:
return x
x = radd(right, left)
if x is not NotImplemented:
return x
raise TypeError

Then instead of defining __add__ you define an overloaded
implementation of ladd, and instead of defining __radd__ you define an
overloaded implementation of radd.

-- Devin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com