On Saturday 26 July 2008 01:23:17 am Nick Coghlan wrote:
> Sebastien Loisel wrote:
> > However, just for posterity (and I'm not going to pursue the argument
> > further than this), I'll say this. The problem of determining the
> > meaning (or overridability or whatever) of x=4$6 is the same as the
> > problem of determining the meaning of x=fooz(4,6). Since it's not a good
> > argument against user-defined functions, I don't see it as a good
> > argument against user-defined operators.
>
> The namespace of usefully mnemonic function names is infinitely larger
> than that of usefully mnemonic punctuation marks. User-defined functions
> are good, but once you have those there is no reason to have
> user-defined operators *as well*.
>
> Cheers,
> Nick.
>
Most mathematicians would disagree with you. I'll grant that it tends to make
the code extremely obscure to those who don't work in the field, but it tends
to make it much clearer to those who do so work.
OTOH, it's also true that there aren't sufficient punctuation symbols. E.g.
math people drafted capital sigma as sum of a series, etc.
Therefore it seems to me that the appropriate thing is to create a convention
that bar-somethingprintable-bar should be interpreted as a user defined
operation, e.g. |+| or |@#|. The first one is reasonable as matrix
multiplication, the second as some user defined operation that hasn't yet
been specified (in this context). And since such things don't yet have
a "secret name" I would suggest that they be defined either via an ordinary
def, or via a def with their name in quotes, i.e., either:
def |+| or def "|+|"
If an ordinary functional reference is desireable (probably) there could be a
decorators that assigned the name, and possibly the precedence, e.g.:
@name=madd
@precedence="+"
def |+| (a, b):
etc.
The main drawback that I see is that code that relies heavily on this approach
would become much less readable to anyone not in the particular field. Think
of the first time you encountered the curl or del operators, or even the
kronecker delta.
OTOH, it seems far too late in the development process to be inserting such a
change in Python 2.6 or 3.0. If this is important to you, you should
probably propose it for 2.7/3.1.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
