UserLinux chooses Python as "interpretive language" of choice

[Nils Kassube]

Ruby can get away with it because, as far as I know, functions are
not first class objects. They certainly aren't in Perl which was
Ruby's inspiration.

It's more likely to be inherited from Smalltalk, the other big source
of inspiration for Matz. A Ruby program is composed of objects whom
you "talk to" by sending messages, i.e. calling a method. There are no
"functions" as in the hybrid, but in its history getting more and more
object-oriented language Python. It's a different way of thinking, not
necessarily better or worse.

Using function objects as a way of passing small pieces of code is
replaced by blocks, also borrowed from Smalltalk.

 

[Terry Reedy]

Well, the basic idea was simply to make the () optional for functions
with no parameters.

In mathematics (except in lambda calculus), there
is generally no such thing since functions
generally have no side effects and hence no-param
function = constant, and name with no parens is
same as normal name ref to constant, whether
number, function, or other mathematical object.
On the other hand, one-param functions *are* ofter
written without parens for simple args. Hence I
suspect that above would lead to the suggestion
that parens also be optional for single-arg funcs.

The overloading of no-op juxtaposition to mean
either * or () (alternatively, the interpretation
of function * number as function(number)) is
rather cute.

Terry J. Reedy

 

[Terry Reedy]

It doesn't matter. As you can see by my reply to Bengt,
the crux of the issue is that, in Ruby, the function call
syntax is *optional.* There is no way to make it optional
in Python, and it is not clear whether it should

be.


Just so you know, your adding as conclusion the
line

It's a non-starter for Python, though.

did change how I read (and responded to) that (and
other) posts. Since there is no serious proposal
to change Python, there is no proposal to resist.

Terry J. Reedy

 

[Dennis Lee Bieber]

John Roth fed this fish to the penguins on Sunday 21 December 2003
04:57 am:

Actually, it wasn't written as a replacement for exec2. It was
originally written for VM/CMS, and Exec2 was an MVT/MVS facility.

From Cowlishaw's chapter "REXX Origins" (in "The REXX Handbook", 1992
McGraw-Hill):

"... This style, while adequate for simple commands, proved cumbersome
for the large and complex programs and macros that were soon being
written in EXEC 2. It became clear to me that a new language was
needed, one based on the more classical syntax and semantics used by
languages in the tradition of ALGOL, PASCAL, and PL/I, yet including
the command and string programming facilities that EXEC 2 had proven to
be so effective and powerful."

That sure sounds like an attempt to replace EXEC 2 to me... <G>

--

 

[Dennis Lee Bieber]

John Roth fed this fish to the penguins on Sunday 21 December 2003
05:02 am:

Whoops! Forget my last response - you're

<G> Too late...

--

 

[Bengt Richter]

In mathematics (except in lambda calculus), there
is generally no such thing since functions
generally have no side effects and hence no-param
function = constant, and name with no parens is
same as normal name ref to constant, whether
number, function, or other mathematical object.
On the other hand, one-param functions *are* ofter
written without parens for simple args. Hence I
suspect that above would lead to the suggestion
that parens also be optional for single-arg funcs.

The overloading of no-op juxtaposition to mean
either * or () (alternatively, the interpretation
of function * number as function(number)) is
rather cute.

... def __init__(self, f): self.f = f
... def __mul__(self, other): return self.f(other)
... "'Happy Holidays'"

Regards,
Bengt Richter

 

[Steve Lamb]

Something, that is of type NoneType.

He didn't say what, he said when. Can anyone show a program that will
evaluate the return of sys.exit() and successfully parse it? =D

 

[Bengt Richter]

That's really an inherent feature of the 'property' notion:
since it's accessed like a variable, the getter can't have any
parameters. Since the property access return an object,
I suppose you could have something that looks like an
indexable or slicable property.

Or even callable, with sneaky dynamic method substitution ;-)
Or any other expression trailer combination of, e.g.,

Well, the basic idea was simply to make the () optional for functions
with no parameters. No particular syntax there but it would require some
major jump through hoops gyrations from the virtual machine, and there
would have to be some way of getting the function object when you
wanted it, and I suspect the difference between a function object and
a more general 'callable' would totally confuse most people. And of
course, does a function/method with only keywords count as a function
with no parameters?

Ruby can get away with it because, as far as I know, functions are not
first class objects. They certainly aren't in Perl which was Ruby's
inspiration.

Really? Perl was Ruby's inspiration??

It's a non-starter for Python, though.

Seems so. OTTOMH I guess you could have the tokenizer generate two kinds of names,
names_as_now, and bare_names (tagged so with lookahead determining no trailers).
Then you could dynamically check if a bare_name was referring to a callable, and
call it with no params if so, and for all other name usage do as now. Except that as
you point out, you'd need a way to inhibit the effect. But since this thing would be
unusual (and would cause major breakage), maybe it could be enabled only for references
to objects with an __autocall__ alias to their __call__ attribute. And then, since the
auto-call would only happen for bare names, you could pass it as a function by using
name.__call__ instead of name. Or use vars()['name'].

Not that I am proposing this ;-)

Regards,
Bengt Richter

 

[Bengt Richter]

... return 123
...
2 0 LOAD_CONST 1 (123)
3 RETURN_VALUE
4 LOAD_CONST 0 (None)
7 RETURN_VALUE
... raise Exception
...
2 0 LOAD_GLOBAL 0 (Exception)
3 RAISE_VARARGS 1
6 LOAD_CONST 0 (None)
9 RETURN_VALUE
1 0 LOAD_CONST 0 (None)
3 RETURN_VALUE

So Python always appends a

return None

statement at the end of a function.
Of course that doesn't mean that it will be executed.

Since the latter is the case much of the time, and since then
it is just unoptimized convenience-boilerplate, maybe a single-byte
RETURN_NONE byte code could be introduced?

Regards,
Bengt Richter

 

[John Roth]

Really? Perl was Ruby's inspiration??

One of them. There's a bit of this and that, but overall
it seems a bit more Perlish than Pythonish. I've never
gotten a satisfactory answer about how it's "more
object-oriented" than Python, unless they mean that
it uses methods instead of built-in functions.

Seems so. OTTOMH I guess you could have the tokenizer generate two kinds of names,
names_as_now, and bare_names (tagged so with lookahead determining no trailers).
Then you could dynamically check if a bare_name was referring to a callable, and
call it with no params if so, and for all other name usage do as now. Except that as
you point out, you'd need a way to inhibit the effect. But since this thing would be
unusual (and would cause major breakage), maybe it could be enabled only for references
to objects with an __autocall__ alias to their __call__ attribute. And then, since the
auto-call would only happen for bare names, you could pass it as a function by using
name.__call__ instead of name. Or use vars()['name'].

I think that's getting a bit baroque. In fact, after my previous post,
I realized that I had an unnecessary complexity: it's simpler to just
auto-execute "all" functions, and let the ones that require parameters
and don't have them fail like they do today, rather than try to make
a distinction.

It puts the VM through quite a few less hoops: all that really has to
be done is duplicate the various opcodes that can fetch a function
object, so that one of each pair autoexecutes and the other doesn't.
Then the parser can decide which to generate based on whether there
is a parameter list following, and also on whether the "magic" syntax for
retreiving the function object without auto-executing it is present.

I suspect it's also easier to explain: funtions and methods are what
are declared with def and lambda, and if it's not that, then it's not
going to autoexecute regardless of whether it has a __call__ method.
Adding classes to the list might be useful as well, but anything more
would lead, I suspect, to too much confusion.

It's still a non-starter, though

John Roth

 

[John Roth]

be.


Just so you know, your adding as conclusion the
line


did change how I read (and responded to) that (and
other) posts. Since there is no serious proposal
to change Python, there is no proposal to resist.

It wasn't a serious proposal in the first place. The proposal
was to take a look at some of the things in some other
languages, and think about them. Somehow that got
lost in the discussion.

And I was quite serious about that. I have the feeling
that there is a good deal of fossilization of the brain
cells setting in.

I could be wrong about that, but I begin to worry when
I see Larry Wall ripping Perl apart and redesigning
it, and I get the impression that the only reason for
Python 3.0 (which seems to be the same distance
in the future, regardless of when we talk about it)
is to make a few relatively minor incompatible
changes.

John Roth

 

[Bengt Richter]

Seems so. OTTOMH I guess you could have the tokenizer generate two kinds of names,
names_as_now, and bare_names (tagged so with lookahead determining no trailers).
Then you could dynamically check if a bare_name was referring to a callable, and
call it with no params if so, and for all other name usage do as now. Except that as
you point out, you'd need a way to inhibit the effect. But since this thing would be
unusual (and would cause major breakage), maybe it could be enabled only for references
to objects with an __autocall__ alias to their __call__ attribute. And then, since the
auto-call would only happen for bare names, you could pass it as a function by using
name.__call__ instead of name. Or use vars()['name'].

I think that's getting a bit baroque. In fact, after my previous post,
I realized that I had an unnecessary complexity: it's simpler to just
auto-execute "all" functions, and let the ones that require parameters
and don't have them fail like they do today, rather than try to make
a distinction.

I sounds like you are suggesting the effect of adding () to every epression
not already ending in (). I don't think you can tell what a name is referring
to until you look it up. Any LOAD_NAME or LOAD_FAST etc. can put a function
reference on the stack (so could the evaluation of any kind of expression!).

It would be unacceptable overhead to test for function magic every time you
got something onto the stack. AFAIK the only thing that now tells the compiler
to generate code to call the unknown thing that has wound up on the stack
is encountering a (...) trailer, empty or not. (Property magic is a little different).

My bare_name distinction limits testing of the stacked item to expressions ending in
plain names, but that's still terrible overhead, unless you generate different
code for when a static analysis can show that the name refers to a function.
Then you could add an implicit () trailer effect for auto-execution. If you could
also require statically determining that it was an "auto-excecute" function, it
could pretty much eliminate run-time overhead, IWT. BTW, I said tokenizer before,
but that's not the place to look ahead for a trailer. Parser/compiler better.

It puts the VM through quite a few less hoops: all that really has to
be done is duplicate the various opcodes that can fetch a function
object, so that one of each pair autoexecutes and the other doesn't.

See above. Any expression can potentially "fetch a function". ISTM the only
kind that you were originally concerned with was ones ending in bare names.

Then the parser can decide which to generate based on whether there
is a parameter list following, and also on whether the "magic" syntax for
retreiving the function object without auto-executing it is present.

(quote func) ? ;-)

I suspect it's also easier to explain: funtions and methods are what
are declared with def and lambda, and if it's not that, then it's not
going to autoexecute regardless of whether it has a __call__ method.
Adding classes to the list might be useful as well, but anything more
would lead, I suspect, to too much confusion.

It's still a non-starter, though

Well, maybe all this is useful in driving home that point ;-)

Regards,
Bengt Richter

 

[Bruno Desthuilliers]

John Roth wrote:
(snip)

And I was quite serious about that. I have the feeling
that there is a good deal of fossilization of the brain
cells setting in.

I could be wrong about that, but I begin to worry when
I see Larry Wall ripping Perl apart and redesigning
it, and I get the impression that the only reason for
Python 3.0 (which seems to be the same distance
in the future, regardless of when we talk about it)
is to make a few relatively minor incompatible
changes.

<troll>
Could it be that Python having a much better design right from the
start, there's no need to do it again ?-)
</troll>

 

[David M. Wilson]

I don't think I misunderstand it. As I've said several times in this
thread, I am not seriously advocating it for a number of reasons.

Please think before making a critique.

That was an attempt to help unravel someone a little from the
discussion, instead it has pulled me in somewhat. Look at the current
subject line, look at the topic of your last post. Is there any point
to this? You are engaged in free-for-all intellectual masterbation. Is
there also any point to being so blunt? Please learn some manners
before speaking in a public forum, you may let yourself down.


David.

 

[Steve Lamb]

Cute. Every function returns something.. None if
nothing else.. except for functions that don't return.

def v():
raise ValueError

would be another variation on the theme.

You're missing the point, aren't you? Is it intentionally missing it or
are you that dense?

 

[Ville Vainio]

One of them. There's a bit of this and that, but overall
it seems a bit more Perlish than Pythonish. I've never
gotten a satisfactory answer about how it's "more
object-oriented" than Python, unless they mean that
it uses methods instead of built-in functions.

It's because it has object orientation built in, unlike Python where
it is just an add-on. Object orientation is more integrated in Ruby.

And Ruby is mostly based on Smalltalk, unlike Python. Smalltalk was a
pretty object oriented in its time.

And yes, I am being sarcastic. Ruby people mostly don't seem to have
any real arguments, apart from the Smalltalk mantra.

It's still a non-starter, though

Yes it is. I think a more useful approach would be a preprocessor that
fixed the screwups that newbies make (pychecker --fixtrivial?), until
they learn. Nobody would use it, but it would be nice to have as
something people could be referred to until they see the error of
their ways.

 

[Ville Vainio]

I could be wrong about that, but I begin to worry when
I see Larry Wall ripping Perl apart and redesigning
it, and I get the impression that the only reason for

That's because perl5 is broken, and judging by what I've read of
perl6, so will be perl6.

Python 3.0 (which seems to be the same distance
in the future, regardless of when we talk about it)
is to make a few relatively minor incompatible
changes.

This clearly showcases the lasting design of Python.

The only kind of major redesign I would see appropriate would be
changing the language so that it could be compiled to fast machine
code (a'la Lisp), if necessary. I guess something would have to go...

 

[Jarek Zgoda]

He didn't say what, he said when. Can anyone show a program that will
evaluate the return of sys.exit() and successfully parse it? =D

sys.exit() doesn't return to caller -- but it doesn't mean it doesn't
return a value. Does this value is discarded? Didn't have time (and
need) to check out.

 

[Bruno Desthuilliers]

John Roth wrote:
(snip)

If a language makes opportunities for errors, then there is
something wrong with the language that needs to be corrected.

Lol ! Tell us when you'll find a language that do not "make
opportunities for errors".

 

[Rainer Deyke]

sys.exit() doesn't return to caller -- but it doesn't mean it doesn't
return a value.

Actually that's exactly what it means. The code to return None may be
included in the sys.exit function object, but it is never executed.