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(*args, **kw))
return temp

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

"Daniel Dittmar" <da************@sap.com> wrote in message
news:c2**********@news1.wdf.sap-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**********@unibas.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

[F. Petitjean]

On 11 Mar 2004 10:24:14 -0800, Bob Lancaster <bo**********@zxmail.com> wrote:

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

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

Like this ?
(extract from a direct translation of C code into python
Nore also this snippet is nested into three while conditions of a method)
while charNo < self._cols:
charNo += 1
ch = self._ifs.read(1)
cond = ((ch != '\n') and not(ch==FF and
self._doFFs) and (ch != ''))
if not cond:
break

if ord(ch) >= 32 and ord(ch) <= 127:
if ch == '(' or ch == ')' or ch == '\\':
ws("\\")
ws(ch)

How to understand the deep nested, mostly negative parts of condition
cond ? and the test is if not cond: which will be equivalent to ...
So, hmmm,.. I need some sleep...

Regards

--
Ce qui se conçoit bien s'énonce clairement,
Et les mots pour le dire viennent aisément.
Boileau Despréaux (l'Art Poétique)

[Erik Max Francis]

Curzio Basso wrote:

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; both notations are used.

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Your theory is not right; it is not even wrong.
-- Wolfgang Pauli

[Donn Cave]

Quoth Oren Tirosh <or*******@hishome.net>:
....
|> 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.

Well, as you may know, function composition is heavily used in Haskell.
But I would agree that it doesn't sound very useful for Python.

Donn Cave, do**@drizzle.com

[Steve]

Gonçalo Rodrigues 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.

Composition of cummutative diagrams is hardly likely to
be confused with compositions of functions, so I don't
think this argument is relevent.

It has been my experience that no matter how well-known
a notation is, there is some field of mathematics that
will either use the same notation for something
different, or use completely different notation for the
same task.

No doubt that there is some obscure field somewhere
where the expression "1 + 1 = 2" means something other
than the obvious :-)

Even so, in "ordinary" mathematics, composition a°b(x)
generally means a(b(x)). Even if it didn't, we are free
to pick whatever notation we want, just as we did
when we choose to use "+" as an infix operator rather
than either prefix "+ a b" or postfix "a b +".

Needless to say, all three notations are in use, but
Python only recognises one. This is not a problem.

While a composition operator would be cute, I don't
think it would be useful enough to justify using a
non-ASCII operator. Other than saving one character per
pair of functions, what else is it good for?
--
Steven D'Aprano

[Muhammad Alkarouri]

Radovan Garabik <ga*****@kassiopeia.juls.savba.sk> wrote in message news:<c2*************@ID-89407.news.uni-berlin.de>...

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

Hi,

besides, we are running out of ASCII

Simple, use Unicode. It is the shiny new boy in town.

Muhammad Alkarouri