PEP Proposal

[python-pep]

Hi,

sorry, I have these ideas for longer than 10 years, please have a look on it
and comment on it. Thx.
----

This is another proposal for introducing types into Python.

There are many reasons for incorporating types into Python, but there is
also a lot of concern about doing so because of destroying the original
character of Python as a smart script language.

This proposal adds several advantages of Prolog(ue) techniques without
changing the natural understanding of Python as a language.
Proposal:

1. Method definitions can be non-unique if a type is prefixed to one or more
of its parameters, or the parameters differ in number.

2. A keyword 'reject' is added.

3. A keyword 'fail' is added.

4. A keyword 'cut' is added.
Definition:

1. A "type" is a String naming the actual class or class family which the
passed instanced is derived from, prefixing the parameter.

2. "'reject'" is a marker inside a function/method and signals that further
processing will not be done inside this method, but instead be passed to the
next available function/method in row, otherwise an implicit "fail" will
occur.

3. "'fail'" is a marker inside a function/method and signals that NO further
processing can be done in neither of this or the following
functions/methods.

4. "'cut'" is a marker inside a function/method that signals that the
failure of called functions/methods inside of it, following this statement,
automatically lead to a failure, instead of trying the next method -
normally, it would be "reject" instead.

5. Failure of functions/methods to outside of this new context are signalled
with a new exception e.g. "MethodRetrialError".

E.g.

def whoisthethief("List" x):
return iknowit(x)

def whoisthethief("String" x, "String" y):
return iknowit([x,y])

##########

def numeral_add(a, b):
if type(a)!=types.IntType:
reject
...

# equivalent to:

def numeral_add("Integer" a, b):
...

[Gabriel Genellina]

En Thu, 25 Sep 2008 16:24:58 -0300, <py********@arcor.deescribió:

sorry, I have these ideas for longer than 10 years, please have a look
on it
and comment on it. Thx.

This is another proposal for introducing types into Python.

You got the terminology wrong. Python had "types" from the very start.
You're talking about some kind of generic functions, or an alternative
dispatch method.

Read this GvR blog post [1] and his next one; also see PEP 3124 by Phillip
J. Eby, who wrote a pretty good implementation of generic functions a long
time ago.

Your proposal requires a syntax change and three new keywords; all the
others achieve roughly equivalent results without requiring any change to
the core language.

[1] http://www.artima.com/weblogs/viewpo...?thread=155123

--
Gabriel Genellina

[python-pep]

Gabriel Genellina wrote:

En Thu, 25 Sep 2008 16:24:58 -0300, <py********@arcor.deescribió:

>sorry, I have these ideas for longer than 10 years, please have a look
on it
and comment on it. Thx.

This is another proposal for introducing types into Python.

You got the terminology wrong. Python had "types" from the very start.
You're talking about some kind of generic functions, or an alternative
dispatch method.

Typed parameters. Method-Declaration-filtered-typed parameters. That's what
I'm thinking of.

I hear & I will answer.

[J Peyret]

On Sep 25, 12:24 pm, [e-mail] wrote:

def whoisthethief("List" x):
return iknowit(x)

def whoisthethief("String" x, "String" y):
return iknowit([x,y])

I dunno if this is very Pythonic in nature, but I've done things like
rebinding methods dynamically.

ex:

>>def test(a):

.... return a * 2
....

>>print test(2)

4

>>def test2(b):

.... return b * 3
....

>>test = test2
print test(2)

6

In your case

def myNewThiefIdentifier(x,y):
return "Dunno"

whoisthethief = myNewThiefIdentifier
Which method would this affect (i.e. which 'whoisthethief')?

I assume you could figure it out, given a match on the signature, but
how much work would this require from the developer and the
interpreter?

(apologies in case Google Groups decide to multipost)

[Diez B. Roggisch]

py********@arcor.de schrieb:

Gabriel Genellina wrote:

>En Thu, 25 Sep 2008 16:24:58 -0300, <py********@arcor.deescribió:

>>sorry, I have these ideas for longer than 10 years, please have a look
on it
and comment on it. Thx.

This is another proposal for introducing types into Python.

You got the terminology wrong. Python had "types" from the very start.
You're talking about some kind of generic functions, or an alternative
dispatch method.

Typed parameters. Method-Declaration-filtered-typed parameters. That's what
I'm thinking of.

I hear & I will answer.

Did you bother reading the pointers Gabriel gave to you? RuleDispatch or
other generic method dispatches exists for about as long as you ponder
about them.

Diez

[Carl Banks]

On Sep 25, 4:04*pm, "Gabriel Genellina" <[e-mail]>
wrote:

En Thu, 25 Sep 2008 16:24:58 -0300, <[e-mail]ó:

sorry, I have these ideas for longer than 10 years, please have a look *
on it
and comment on it. Thx.

This is another proposal for introducing types into Python.

You got the terminology wrong. Python had "types" from the very start. *
You're talking about some kind of generic functions, or an alternative *
dispatch method.

Read this GvR blog post [1] and his next one; also see PEP 3124 by Phillip *
J. Eby, who wrote a pretty good implementation of generic functions a long *
time ago.

Your proposal requires a syntax change and three new keywords; all the *
others achieve roughly equivalent results without requiring any change to*
the core language.

Just to play Devil's advocate here, multimethods(**) aren't
equivalent, roughly or otherwise, to what the OP is requesting.
Superficially it looks that way, but the actual use case for this
logic programming is something that ordinary multimethods can't do.

Prolog-style programming is sort of the exact opposite of pure
functional programming. Whereas in pure functional programming there
are no side effects, in Prolog pretty much everything is a side
effect. The way things happen in Prolog is execution of side effects
in the process of searching for pattern matches.

A decent multimethod implementation doesn't use trial and error for
dispatch; it'll use some kind of mapping and cacheing to get to the
appropriate function as quickly as possible. In logic programming
however, the trial-and-error is essential since side-effects can and
are supposed to happen in the process of trying.
Anyway, this proposal can easily be implemented more or less as
proposed without any syntax changes, using the same ideas as the
multimethod implementations, but guaranteeing trial-and-error
dispatching.
Carl Banks

(**) I avoid the term "generic function" since it constrasts starkly
with the use of the word "generic" in generic programming.

[James Mills]

On Fri, Sep 26, 2008 at 6:14 AM, <py********@arcor.dewrote:

Typed parameters. Method-Declaration-filtered-typed parameters. That's what
I'm thinking of.

Why do we need this (rubbish) ?
Seriously. The use-case is far too small.
And don't invent use-cases either.

Instead of coming up with ideas of adding more
and more into the language from other languages
of which certain features weren't very good in
the first place, devote your time to improving
the libraries, documentation, etc.

Typed parameters is useless to me. A lot of
developers would agree.

--JamesMills

--
--
-- "Problems are solved by method"

[Aaron \Castironpi\ Brady]

On Sep 25, 2:24*pm, [e-mail] wrote:

Hi,

sorry, I have these ideas for longer than 10 years, please have a look onit
and comment on it. Thx.

----

This is another proposal for introducing types into Python.

There are many reasons for incorporating types into Python, but there is
also a lot of concern about doing so because of destroying the original
character of Python as a smart script language.

This proposal adds several advantages of Prolog(ue) techniques without
changing the natural understanding of Python as a language.

Proposal:

1. Method definitions can be non-unique if a type is prefixed to one or more
of its parameters, or the parameters differ in number.

2. A keyword 'reject' is added.

3. A keyword 'fail' is added.

4. A keyword 'cut' is added.

Definition:

1. A "type" is a String naming the actual class or class family which the
passed instanced is derived from, prefixing the parameter.

2. "'reject'" is a marker inside a function/method and signals that further
processing will not be done inside this method, but instead be passed to the
next available function/method in row, otherwise an implicit "fail" will
occur.

3. "'fail'" is a marker inside a function/method and signals that NO further
processing can be done in neither of this or the following
functions/methods.

4. "'cut'" is a marker inside a function/method that signals that the
failure of called functions/methods inside of it, following this statement,
automatically lead to a failure, instead of trying the next method -
normally, it would be "reject" instead.

5. Failure of functions/methods to outside of this new context are signalled
with a new exception e.g. "MethodRetrialError".

E.g.

def whoisthethief("List" x):
* return iknowit(x)

def whoisthethief("String" x, "String" y):
* return iknowit([x,y])

##########

def numeral_add(a, b):
* if type(a)!=types.IntType:
* * reject
* ...

# equivalent to:

def numeral_add("Integer" a, b):
* ...

Would you settle for a class or classes which had the same
functionality, only you would call its methods with parentheses?

Modified examples:

@argtype( List )
def whoisthethief(x):
return iknowit(x)

@argtype( String, String )
def whoisthethief(x, y):
return iknowit([x,y])

def numeral_add(a, b):
if type(a)!=types.IntType:
reject()
...

/or:

def numeral_add(a, b):
if type(a)!=types.IntType:
flow.reject()
...