On Thursday 30 October 2003 03:27 pm, Moore, Paul wrote:

From: Alex Martelli [mailto:aleaxit@yahoo.com]

...

On Thursday 30 October 2003 02:01 pm, Michael Chermside wrote:

...

And that's exactly why I would be wary of it. One of the GREAT SIMPLICITIES of Python is that all calls are "the same". Calling a function works

A new descriptortype wouldn't change the ``all the same'' idea at the level at which descriptortypes such as staticmethod and classmethod haven't changed it.

Excuse me, did I miss something? Guido's code was entirely user-level Python, so is available for anyone who wants to use it right now, surely?

Yes, exactly like staticmethod was available before it became a builtin (e.g., see p.176, "Python Cookbook").

And if you want it in a C extension, I guess you code a C version for your own use.

Why bother arguing over whether it's "right" or "wrong"?

Raymond and I would like to use it as the descriptor for the new list.sorted. If the code gets in Python anyway, then it should ideally be somehow exposed for general use if it's right -- but not if it's wrong. Moreover, if it's wrong "by enough", it might be better to NOT have it get in at all, and keep the possibility well under wraps -- if this behavior is used by what will likely become a reasonably popular method of a reasonably popular built-in type, list, people may well be encouraged to design some aspects of their classes similarly. If such a design is considered a disaster, then encouraging and popularizing it in this way might not be wise. If, on the other hand, the design IS of enough general use, then there are no such qualms -- indeed, documenting the use and design-assumptions of the new descriptor in the Python docs would then be a good idea. So, it appears to me that the discussion on the pro's and con's of such a descriptor type is well warranted on this list. Alex