new python syntax: concatenation of functions

[Uwe Mayer]

Hi,

I know the python community is not very receptive towards extending the
python syntax. Nevertheless I'd like to make a suggestion and hear your pro
and cons.

I want so suggest a concatenation operator like in mathematics: °
such that:

a(b(c(d))) <=> a°b°c(d)

Now, why do you think such an extension would be completely useless? ;)

Ciao
Uwe

[Radovan Garabik]

Uwe Mayer <me*****@hadiko .de> wrote:

Hi,

I know the python community is not very receptive towards extending the
python syntax. Nevertheless I'd like to make a suggestion and hear your pro
and cons.

I want so suggest a concatenation operator like in mathematics: °
such that:

a(b(c(d))) <=> a°b°c(d)

Now, why do you think such an extension would be completely useless? ;)

because neither in mathematics people agree on the order:
a°b(x) == a(b(x)) or
a°b(x) == b(a(x)) ?

besides, we are running out of ASCII
and besides, it would make more sence to introduce definable operators,
Ã* la C++

def (x)°(y):
return lambda par: x(y(par))
print (a°b)(x)

or, without leaving ascii:

def (x)composition( y):
return lambda par: x(y(par))
print (a composition b)(x)


--
-----------------------------------------------------------
| Radovan GarabÃ*k http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__ garabik @ kassiopeia.juls .savba.sk |
-----------------------------------------------------------
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

[Daniel Dittmar]

Radovan Garabik wrote:

or, without leaving ascii:

def (x)composition( y):
return lambda par: x(y(par))
print (a composition b)(x)

or without leaving Python

class Composition:
def __init__ (self, outer, inner):
self.outer = outer
self.inner = inner

def __call__ (self, *args):
return self.outer (self.inner (*args))

def __str__ (self):
return '%s ° %s' % (self.outer, self.inner)

Daniel

[Curzio Basso]

Radovan Garabik wrote:

because neither in mathematics people agree on the order:
a°b(x) == a(b(x)) or
a°b(x) == b(a(x)) ?

Is this a joke or what?

In mathematics people DO agree on the order:

if a:B->A and b:X->B, then a°b:X->A and
(a°b)(x)=a(b(x ))

[Sagiv Malihi]

what you would *really* like to do, is to be able to extend any class, and
override it's operators.
in your example, you would like to do something like:

def mul_funcs(self, other):
def temp(*args, **kw):
return self(other(*arg s, **kw))
return temp

and then:
FunctionType.__ mul__(self, other) = mul_funcs

"Daniel Dittmar" <da************ @sap.com> wrote in message
news:c2******** **@news1.wdf.sa p-ag.de...

Radovan Garabik wrote:

or, without leaving ascii:

def (x)composition( y):
return lambda par: x(y(par))
print (a composition b)(x)

or without leaving Python

class Composition:
def __init__ (self, outer, inner):
self.outer = outer
self.inner = inner

def __call__ (self, *args):
return self.outer (self.inner (*args))

def __str__ (self):
return '%s ° %s' % (self.outer, self.inner)

Daniel

[Gonçalo Rodrigues]

On Thu, 11 Mar 2004 15:40:14 +0100, Curzio Basso
<cu**********@u nibas.ch> wrote:

Radovan Garabik wrote:

because neither in mathematics people agree on the order:
a°b(x) == a(b(x)) or
a°b(x) == b(a(x)) ?

Is this a joke or what?

In mathematics people DO agree on the order:

if a:B->A and b:X->B, then a°b:X->A and
(a°b)(x)=a(b(x ))

No they DON'T. Both notations are used. The notation (using
concatenation instead of circle to denote composition)

ba: x -> a(b(x))

is called diagrammatic order, and to be totally consistent we should
really write

x -> (x b) a

and is more often used in Category Theory (and close relatives like
Homological Algebra, etc. ) where you deal more with commutative
diagrams and the like and functions being applied to arguments appear
only very rarely.

With my best regards,
G. Rodrigues

[Michele Simionato]

Uwe Mayer <me*****@hadiko .de> wrote in message news:<c2******* ***@news.rz.uni-karlsruhe.de>.. .

Hi,

I know the python community is not very receptive towards extending the
python syntax. Nevertheless I'd like to make a suggestion and hear your pro
and cons.

I want so suggest a concatenation operator like in mathematics: °
such that:

a(b(c(d))) <=> a°b°c(d)

Now, why do you think such an extension would be completely useless? ;)

Ciao
Uwe

This is not useless, but does not require new notations. Just use
callable objects instead of functions and overload "*" to denote
composition.
Michele Simionato

[Oren Tirosh]

On Thu, Mar 11, 2004 at 12:38:49PM +0100, Uwe Mayer wrote:

Hi,

I know the python community is not very receptive towards extending the
python syntax. Nevertheless I'd like to make a suggestion and hear your pro
and cons.

I want so suggest a concatenation operator like in mathematics: ??
such that:

a(b(c(d))) <=> a??b??c(d)

Now, why do you think such an extension would be completely useless? ;)

Composition of regular functions is not too useful in daily programming
tasks but concatenation of stream processes is quite useful. That is
what makes pipes in shell programming so effective.

Oren

[Jeff Epler]

On Thu, Mar 11, 2004 at 07:25:01AM -0800, Michele Simionato wrote:

This is not useless, but does not require new notations. Just use
callable objects instead of functions and overload "*" to denote
composition.

What about instances which already support __mul__ and __call__, a
combination that is perfectly legal today?

Jeff

[Bob Lancaster]

Uwe Mayer <me*****@hadiko .de> wrote in message news:<c2******* ***@news.rz.uni-karlsruhe.de>.. .

Hi,

I know the python community is not very receptive towards extending the
python syntax. Nevertheless I'd like to make a suggestion and hear your pro
and cons.

I want so suggest a concatenation operator like in mathematics: °
such that:

a(b(c(d))) <=> a°b°c(d)

Now, why do you think such an extension would be completely useless? ;)

Ciao
Uwe

One of the things I like best about Python is the ease of use. This
method would hurt, rather than help the cause, IMO.

Here are the arguments against it:

(1) Where is the ° key on the keyboard? I do chemistry related
programing, and getting the ° into my GUIs (when I need to show
degrees) takes a bit of time and effort. The old way is easier to
type, ergo easier to use.

(2) The precedence and ordering of the operation would have to be more
clearly defined. This seems similar to the Unix pipe | operator.
However, in your proposal the result of c(d) is piped into b, and that
result is piped into a. This could lead to confusion. Should we have
a pipe-style °, in which case the syntax would be: c(d)°b°a, or do
the way you suggest: a°b°c(d). Either way would be confusing to
somebody. (As far as using | to get around the problems with point
(1),

(3) How would this operator play with other operators?

(4) For my personal style, I don't like to use constructs that are too
esoteric. I tend to avoid the tertiary operator in C++, and I tend
not to get fancy with the 'and' and 'or' operators in Python. It
makes code more readable and maintainable, IMO. Any programmer who
writes code without any thought to code maintainance is doing the
employer or client a disservice.

(5) One of the best aspects of Python is how easy it is to learn in
the first place. Someone with a background in C/C++, Java, Pascal,
Perl, etc. can learn python in a few hours. Adding weird operators
would make the process more difficult. Anyone who has been though
language Holy Wars knows that ease of use and learning is about the
only way to convince anyone to even consider Python.

Just my opinions.

-Bob