[Python-3000] Fwd: defop ?

[Guido van Rossum]

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.

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

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

On 11/24/06, Calvin Spealman <ironfroggy at gmail.com> wrote:
> On 11/23/06, Guido van Rossum <guido at python.org> wrote:
> > On 11/22/06, Calvin Spealman <ironfroggy at gmail.com> wrote:
> > > On 11/22/06, Guido van Rossum <guido at python.org> wrote:
> > > > Not sure I like this better. My spelling of "operator::XXX" is
> > > > "__XXX__" and I like that just fine -- no new syntax needed.
> > >
> > > Well, that might be a spelling of `operator::XXX` but what about other
> > > use cases like `third_party_interface_system::adapt` or
> > > `anything_at_all::XXX`? Thats what I mean with not being too limiting
> > > and solving the problem in a way that opens up solutions to other
> > > problems. I get the opposition to it, but it seems reasonable,
> > > nonetheless.
> >
> > How was I to generalize from a single example what you meant? I
> > thought you were using 'operator' as a fixed keyword like it is in
> > C++, and I was wondering what you meant by the double colon.
> >
> > I still believe it is easy enough to solve this using a naming convention.
>
> Sorry, I meant it in the context of this thread, where the previous
> examples where using the operator module (which, by virtue of
> existing, should suggest that I wasn't implying its name for use in
> some other way).
>
> Naming conventions will only take us so far before we run into
> conflicts more often than we can offord. We only have one convention
> for special names, really, and it will run up its invitation with or
> without a suitable solution around its limitations. I understand the
> associtiation of this with "Too Much Magic" or simply the idea that
> its more than is needed, overkill, etc. and I share that warriness.
> But its something to consider, I suppose. I guess the thing to
> consider is simply, "What's in a name?"
>
> Another suggestion for this proposal:
>
> class MyList(object):
>     def __builtins__::len(self):
>         return 0
>
> This would basically say that MyList has a method identified by the
> len attribute of __builtins__. Does that make sense? Maybe the syntax
> isn't enjoyable but the effect is more the value I see, so are there
> other ways it could be expressed?
> _______________________________________________
> 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/)