[Python-3000] Fwd: defop ?

[Calvin Spealman]

On 11/26/06, Guido van Rossum <guido at python.org> wrote:
> On 11/25/06, Calvin Spealman <ironfroggy at gmail.com> wrote:
> > 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.
>
> Do you realize that expr[expr::expr] already has a meaning?

Yes. As I've stated repeatedly, I don't care for or encourage the a::b
syntax itself, but am using it as a representation of whatever might
become used. I don't know what, at this point.

> You seem to be doing an exceptionally poor job explaining your
> proposal; you are introducing a new token "::" without ever explaining
> what you propose it should mean. How does operator::len differ from
> operator.len?

A.b evaluates to the value of attribute 'b' of some object bound to
name 'A', of course.
A::b (or whatever syntax might be used) would evaluate to some value
that actually represents "The attribute 'b' of this object". This
"attribute object" (poor term, yes) could have other uses, but thats
not completely relevent now. For the case at hand, basically we would
allow the syntax for these objects to be used as legal names (keys in
the __dict__ or elements of the __slots__). Thus, the way in
`A.__len__` the string '__len__' is created and looked up in the
dictionary, with `A.operator::len` (or whatever syntax is used)
<ObjectAttribute operator module, attribute 'len'> would be the key in
the __dict__, the actual name of the attribute of the A class.

Basically, it allows for using any object in combination with a name
to have identifiers that do not conflict. Thus we can have all the
operator methods we want and never conflict with names others might
use. The interface libraries can operate without worry. Lots of
problems solved.

I am sorry if my thoughts are not conveyed as clear as they sound in my mind.

> > > 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/
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
> >
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>


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