[Python-3000] Fwd: defop ?

[Calvin Spealman]

I will make only one more comment and then ill drop my comments
without direct questions.

On 11/25/06, Guido van Rossum <guido at python.org> wrote:
> Hm. The double colon rubs me the wrong way (Perl and/or C++). But
> apart from that, if this is the solution, I'm not sure the problem
> you're trying to solve is really worth solving. I just don't expect
> there will be all that many generic operations that need to be stuffed
> into arbitrary classes. Maybe I'll just take back what I said about
> wanting all such operations to be inside the class. Or maybe I'd be
> happier if there was a decorator indicating the name of the operation.

I don't care about the syntax. anything that can denote an expression
(the left of the ::) and a name (the right of the ::) is OK and I dont
care how its denoted.

> Also, I think you're overloading 'def' in a non-obvious way.
> Currently, "def foo..." means an assignment to the local variable foo.
> I would expect that if we extend the syntax for the thing between
> 'def' and the argument list to be more than just a name, it should
> still be considered an assignment target. But that's clearly not what
> you're after. From that POV, I find defop (while still unpleasant for
> other reasons) more "honest" than your overloading of def -- at least
> defop says upfront that it's not just an assignment. (Although the
> similarity with def is still confusing IMO.)

You must be misunderstanding me. I am not saying that its not an
assignment. It would not change what def really means. operator::len
would be the actual name of the function to be created and the name of
the global, local, or class attribute it is bound to. I am saying
operator::len would become something like
MyClass.__dict__[operator::len] and what operator::len evaluates to, i
dont know. something that represents what it is. Maybe just a tuple. I
would expect it also exist for any assignment. special casing being
bad and all.

> Still not convinced? Focus on other problems first. This isn't the
> most important problem we're trying to solve.
>
> PS, It's __builtin__, not __builtins__ -- the latter is an
> unfortunately named but ultimately unimportant implementation detail
> (unimportant unless you're implemented restricted python, that is);
> the former is the module that is implied at the end of every free name
> search.
>
>
> --Guido

-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/