On 11/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> So, the generic function 'as_string' here functions as an "interface" or
> "ability". Of course, instead of being called 'as_string', it could live
> as an attribute of the 'str' type, e.g. 'str.cast':
OK, I think I just "clicked" with what defop is for. It's to allow you
to define additional behaviour for methods, etc, where the normal def
syntax won't allow something like str.cast? Sorry if that description
is a bit vague - it reflects a feeling of "why bother?"
Is
defop str.cast(s: MyClass):
...
that much better than
@str.cast.when(MyClass)
def _(s):
...
given that Guido doesn't like "when", so a better name may end up
being used, and the slight namespace pollution of having to come up
with a name to use for the function (I used _ here, maybe there's a
case for allowing def without a name which passes the anonymous
function to the decorator but does no assignment to names...) I could
quite happily live with the decorator form as it stands though - new
syntax seems like overkill.
Paul
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
