UserLinux chooses Python as "interpretive language" of choice

[Ville Vainio]

I don't know if you have seen this before, but here goes:

http://text.userlinux.com/white_paper.html

There is a jab at Python, though, mentioning that Ruby is more
"refined".

 

[John Roth]

I don't know if you have seen this before, but here goes:

http://text.userlinux.com/white_paper.html

There is a jab at Python, though, mentioning that Ruby is more
"refined".

I'm not sure about refined, but it does seem to have several
things that I think I'd like. One is a much
better way of handling anonymous functions, aka "blocks."
Another is the pervasive use of the visitor pattern, and
a third is the ability to forget the empty parenthesis after
a function/method call that doesn't require parameters.

On the other hand, I'm mildly agnostic over the builtin
function versus method issue.

The biggest problem is that I think Python is beginning
to sucumb to the "we're better so we don't have to try
harder" syndrome. One of these days, someone is going
to start chewing up the user base, and for a while it looked
like Ruby might have been it.

John Roth

 

[Steve Lamb]

a third is the ability to forget the empty parenthesis after
a function/method call that doesn't require parameters.

class ThisIs:
avariable = 'a'
def amethod(self):
return 'b'

thisis = ThisIs()
print thisis.avariable
print thisis.amethod()
import this
print "Read line 2."

 

[John Roth]

class ThisIs:
avariable = 'a'
def amethod(self):
return 'b'

thisis = ThisIs()
print thisis.avariable
print thisis.amethod()
import this
print "Read line 2."

I'm not sure what your point is. Your example isn't going
to produce the expected result if you say:

print thisis.amethod

instead of

print thisis.amethod()

That is the place where I find Ruby syntax to be
helpful: the amount of time where I want the method /
function object is *far* lower than the amount of
time I want to call it. It's one of those conundrums
that doesn't seem to have a clean answer, though.

John Roth

 

[Ville Vainio]

a third is the ability to forget the empty parenthesis after
a function/method call that doesn't require parameters.

Doesn't this suck big time? How can the interpreter tell whether you
are trying to call a function or just want a reference to a callable
object?

harder" syndrome. One of these days, someone is going
to start chewing up the user base, and for a while it looked
like Ruby might have been it.

I dunno. It just doesn't seem likely that people who have "got" Python
would switch to ruby. If the extra features of ruby were really
worthwhile, they would be added to Python (which has happened
before). I trust the Py development team to do the right decision at
all times (apart from ternary operator, obviously ;-).

 

[Skip Montanaro]

John> The biggest problem is that I think Python is beginning to sucumb
John> to the "we're better so we don't have to try harder" syndrome. One
John> of these days, someone is going to start chewing up the user base,
John> and for a while it looked like Ruby might have been it.

Can you give some concrete examples which support your contention?

Skip

 

[Bengt Richter]

I'm not sure what your point is. Your example isn't going
to produce the expected result if you say:

print thisis.amethod

instead of

print thisis.amethod()

That is the place where I find Ruby syntax to be
helpful: the amount of time where I want the method /
function object is *far* lower than the amount of
time I want to call it. It's one of those conundrums
that doesn't seem to have a clean answer, though.

Ok, for line 2, run this ;-)

class ThisIs:
avariable = 'a'
def amethod(self):
return 'b'
def silly(self):
return 'heh'
silly = property(silly)

thisis = ThisIs()
print thisis.avariable
print thisis.amethod()
print thisis.silly
import sys
class L2(list):
def write(self, s): self.append(s)
sys.stdout = L2()
import this
L2 = ''.join(sys.stdout).splitlines()[2]
sys.stdout = sys.__stdout__
print "Read line 2."
print '... which is:', L2

Regards,
Bengt Richter

 

[Roy Smith]

If the extra features [...] were really
worthwhile, they would be added to Python

Down that path lies madness (i.e. Perl).

 

[Steve Lamb]

I'm not sure what your point is.

If you had run it you would have understood it. You didn't run it, did
you?

Your example isn't going to produce the expected result if you say:

print thisis.amethod

instead of

print thisis.amethod()

Well, you kind of got it. Here's the run:

Python 2.3+ (#2, Aug 10 2003, 11:33:47)
[GCC 3.3.1 (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more information..... avariable = 'a'
.... def amethod(self):
.... return 'b'
.... The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!Read line 2.

Line 2: "Explicit is better than implicit."

thisis.amethod() is an explicit call to a method. If you flubbed it and
overwrote your namespace later on then you would get unexpected results at
runtime. If you remove the () it becomes an implicit call depending on the
object that is a reference to. Hmmm, I guess I could have also finished with
this line as well, "Read line 12." IE, "In the face of ambiguity, refuse the
temptation to guess."

def foo:
return 'a'

bar = foo

Is it a or is it the function object? Rats, now we have to make a special
case when point to a function as opposed to any other object. D'oh, now we
need to read line 8, "Special cases aren't special enough to break the rules."
Ok, so we shouldn't make a special case here. That also applies to where?

How often to we make calls to functions/methods without parameters
compared to how often we do?

Man, I never knew that little tidbit was so fun and self referencing.
Thanks Tim Peters!

 

[Ville Vainio]

If the extra features [...] were really
worthwhile, they would be added to Python

Down that path lies madness (i.e. Perl).

And that's why I trust the judgement in the language developers
hands. If Ruby had enough of a "killer" feature that it would result
in flow of people from Ruby to Python, it could be added to Python.

As a whole, the py developer team seems to have their act together
better than Ruby developers, judging by the "taste" and various
perlisms in Ruby. The only thing Ruby will forever have over Python
(according to the individuals who tend to be of that opinions) is the
lack of whitespace block structure. I guess that would be the main
reason why various misguided souls choose Ruby over Python ;-).

But then again, various people choose Perl, of all things, over
Python, so I guess there doesn't need to be a rational explanation for
picking a language.

 

[John Roth]

I'm not sure what your point is. Your example isn't going
to produce the expected result if you say:

print thisis.amethod

instead of

print thisis.amethod()

That is the place where I find Ruby syntax to be
helpful: the amount of time where I want the method /
function object is *far* lower than the amount of
time I want to call it. It's one of those conundrums
that doesn't seem to have a clean answer, though.

Ok, for line 2, run this ;-)

class ThisIs:
avariable = 'a'
def amethod(self):
return 'b'
def silly(self):
return 'heh'
silly = property(silly)

thisis = ThisIs()
print thisis.avariable
print thisis.amethod()
print thisis.silly
import sys
class L2(list):
def write(self, s): self.append(s)
sys.stdout = L2()
import this
L2 = ''.join(sys.stdout).splitlines()[2]
sys.stdout = sys.__stdout__
print "Read line 2."
print '... which is:', L2

Regards,
Bengt Richter

I think you're missing the point I was trying to make.
Sure, you can use a property to not have to put
in the explicit function call, but then you can't put
in the explicit function call *anywhere* you use that
property.

Ruby syntax makes it *optional*. That's what is
missing here.

John Roth

 

[John Roth]

I'm not sure what your point is.

If you had run it you would have understood it. You didn't run it, did

you?

Your example isn't going to produce the expected result if you say:

print thisis.amethod

instead of

print thisis.amethod()

Well, you kind of got it. Here's the run:

Python 2.3+ (#2, Aug 10 2003, 11:33:47)
[GCC 3.3.1 (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more information.... avariable = 'a'
... def amethod(self):
... return 'b'
...The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!Read line 2.

Line 2: "Explicit is better than implicit."

thisis.amethod() is an explicit call to a method. If you flubbed it and
overwrote your namespace later on then you would get unexpected results at
runtime. If you remove the () it becomes an implicit call depending on the
object that is a reference to. Hmmm, I guess I could have also finished with
this line as well, "Read line 12." IE, "In the face of ambiguity, refuse the
temptation to guess."

def foo:
return 'a'

bar = foo

Is it a or is it the function object? Rats, now we have to make a special
case when point to a function as opposed to any other object. D'oh, now we
need to read line 8, "Special cases aren't special enough to break the rules."
Ok, so we shouldn't make a special case here. That also applies to where?

How often to we make calls to functions/methods without parameters
compared to how often we do?

Man, I never knew that little tidbit was so fun and self referencing.
Thanks Tim Peters!

---

 

[John Roth]

If you had run it you would have understood it. You didn't run it, did
you?

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.

What I'm missing, however, is any *thoughtful*
discussion of the issues involved. Your [perjoritive
adverb deleted] response makes it clear that you
didn't think of the issues, you just reacted.

John Roth
souls.

No, you're not, and you will never be.

John Roth

 

[John Roth]

Doesn't this suck big time? How can the interpreter tell whether you
are trying to call a function or just want a reference to a callable
object?

That's the crux of the implementation issue, and I, for one,
haven't got an answer that doesn't look real ugly (let alone
break backwards compatability.) That's why I'm not pushing
this particular issue seriously - I don't see a way of doing it,
given the rest of Python, and completely independently of any
"Python philosophy" issues.

I dunno. It just doesn't seem likely that people who have "got" Python
would switch to ruby. If the extra features of ruby were really
worthwhile, they would be added to Python (which has happened
before). I trust the Py development team to do the right decision at
all times (apart from ternary operator, obviously ;-).

The people who have switched don't post here. I'm very active
on the XP mailing list, and I see lots more references to Ruby than
to Python. Maybe the fact that such industry heavy hitters as Robert
Martin, David Thomas, and any number of others have switched
shouldn't count. In fact, the head of this thread should really be a
wakeup call: the *only* reason that Python was chosen instead
of Ruby is the lack of *current* market penetration.

As far as doing the "right" thing, check the partial list of Ruby
features I gave, and ask yourself how much each of them would
break the "feel" of Python.

It's not that the features aren't worthwhile, it's that there is a
serious philosophy issue, which I think I'm going to address in
my reply to Skip.

John Roth

 

[Hartmut Goebel]

It doesn't matter. As you can see by my reply to Bengt,

It does matter, since the _output_ of the result (which Steve posted for
your convenience) contains the answer to your question.

the crux of the issue is that, in Ruby, the function call
syntax is *optional.*

The crux of this 'option' is that it's ambiguos whether you wnat to
_access_ or _call_ the function object. See line 12 of the output
meantioned above to know why Python will never implement such an
'option'. [And BTW I probably will never use a language having such an
'option'.]

> What I'm missing, however, is any *thoughtful*
discussion of the issues involved. Your [perjoritive
adverb deleted] response makes it clear that you
didn't think of the issues, you just reacted.

*walking to the fuel-station, filling my many-years-unused flame-thrower
for the upcoming flame-battle*

John Roth

--
Regards
Hartmut Goebel

| Hartmut Goebel | We build the crazy compilers |
| (e-mail address removed) | Compiler Manufacturer |

 

[Oren Tirosh]

I'm not sure about refined, but it does seem to have several
things that I think I'd like. One is a much
better way of handling anonymous functions, aka "blocks."
Another is the pervasive use of the visitor pattern, and

I've always considered the visitor pattern as a rather poor substitute
for generators, not as a something worth having for its own sake. Using
generators instead of visitors+anonymous functions obviously reduces the
need for anonymous functions (not that it's any excuse for not having
something better than Python's lambdas!).

Oren

 

[John Roth]

John> The biggest problem is that I think Python is beginning to sucumb
John> to the "we're better so we don't have to try harder" syndrome. One
John> of these days, someone is going to start chewing up the user base,
John> and for a while it looked like Ruby might have been it.

Can you give some concrete examples which support your contention?

I think the discussion on this thread is a reasonably good example [grin].

The responses to my comment about method calls with no
arguements should say everything that needs to be said about
attitude.

Let's skip the fluf and get to the crux. There are four languages (not
counting
minor entries) in the space Python occupies. In alphabetical order, they
are:
Perl, Python, Ruby and TCL. The originators of those languages have very
different language design philosophies.

Larry Wall (Perl): There's more than one way to do it.

Guido vanRossum (Python): There should only be one obvious way to
do anything significant.

Metz (Ruby): I want a language that's both productive and fun to program.

John Osterhout (TCL). I want a language I can embed in tools as a common
scripting language.

Notice that there is only one polarity here: Perl vs Python. Ruby goes
meta on the discussion in that it looks at what the customer (the developer)
*wants*, rather than what the language designer thinks they should have.

And *that* is the crux here. A fairly large number of people I respect
have used Python and have migrated to Ruby. For a long time, the basic
flow was from Perl to Python, for reasons that we don't need to hash over
again.

Most businesses would look at a competitor who is stealing customers
as an opportunity to figure out what those customers want that they
aren't getting.

The jihad against the "functional" builtins is a good case in point.
The replacements for apply, map and filter seem to be adequate,
and in the case of list comprehensions, pretty darned useful although
I think that it's a rather baroque addition to an otherwise very clear
and comprehensible language.

On the other hand, claiming that sum() is an adequate replacement
for reduce() is so silly that it borders on the absurd. The only
explanation I can come up with for that level of absurdity is
a desire to get rid of a feature, regardless of what it looks like.
In other words, a jihad (holy war.)

There is no replacement for lambda in sight, even though lambda is
arguably the ***largest single*** one of the functional constructs
that needs work, and has obviously needed work for a long time.

The obvious replacement for lambda, which is some form of
inline block, has not been seriously discussed, with proposed
syntax and examples, anywhere I've seen it. Clearly, I'm
not ominiscient, so that doesn't mean it hasn't, though.

The PEP 308 mess has left a rather sour taste in a lot of
people's mouths: there was a clear majority in favor of
doing *something*, but the voting was rigged (although I
doubt if it was done deliberately) to make certain that
no single proposal would get a majority.

 

[John Roth]

It does matter, since the _output_ of the result (which Steve posted for
your convenience) contains the answer to your question.

I've been around long enough that that level of "cute"
is simply irritating. I'm well aware of "explicit is better
than implicit."

the crux of the issue is that, in Ruby, the function call
syntax is *optional.*

The crux of this 'option' is that it's ambiguos whether you wnat to
_access_ or _call_ the function object. See line 12 of the output
meantioned above to know why Python will never implement such an
'option'. [And BTW I probably will never use a language having such an
'option'.]

And if you read the rest of my comment, you would know
that I am not suggesting that Python do so, for implementation
reasons. There are ways around the ambiguity you mention,
but they will not come out unless there is a *thoughtful*
discussion, and in any case they would definitely break
backwards compatability.

What I'm missing, however, is any *thoughtful*
discussion of the issues involved. Your [perjoritive
adverb deleted] response makes it clear that you
didn't think of the issues, you just reacted.

*walking to the fuel-station, filling my many-years-unused flame-thrower
for the upcoming flame-battle*

Why bother?

John Roth

 

[Ville Vainio]

That's the crux of the implementation issue, and I, for one,
haven't got an answer that doesn't look real ugly (let alone
break backwards compatability.) That's why I'm not pushing
this particular issue seriously - I don't see a way of doing it,
given the rest of Python, and completely independently of any
"Python philosophy" issues.

Most importantly, why would anyone even care? Ability to optionally
invoke a "call" operation on an object implicitly seems utterly
worthless to me. It has the feel of perl philosophy (regexps in
language syntaxm anyone? ), and it's not the only instance in Ruby. I
don't really like the Perl philosophy (like most of the people who
"get" Python), and I don't really believe a language whose designers
appreciate the perlisms poses a serious threat to Python. Not even if
they got some things right.

to Python. Maybe the fact that such industry heavy hitters as Robert
Martin, David Thomas, and any number of others have switched

Frankly, I don't know who these "heavy hitters" are, but they probably
have their reasons. Quick googling didn't turn out any useful articles
explaining why either of them has switched from Python to Ruby.

As far as doing the "right" thing, check the partial list of Ruby
features I gave, and ask yourself how much each of them would
break the "feel" of Python.

I am yet to see a feature list that would inspire me to switch, or
even consider switching. The little advantages Ruby has over Python
are dwarfed by the advantages of Python (of which the least is not
maturity, community and documentation).

 

[John Roth]

Most importantly, why would anyone even care? Ability to optionally
invoke a "call" operation on an object implicitly seems utterly
worthless to me.

That may not be one of your common coding mistakes.
My mind doesn't quite get the point of inserting an
otherwise useless pair of parenthesis, and consequently
it's fairly high on the list of common coding errors I make
that causes run time errors. Of course, rigidly applying
TDD will bring those errors up rapidly so they don't
lurk to cause problems later, but not having them in the
first place would be even better.

There's a Japanese term used in Lean Manufacturing
that basically translates as "mistake proofing." While
Python makes it harder to make mistakes than many
other languages, it is certainly not perfect in that respect,
and this issue is one of several that fall into that category.

It has the feel of perl philosophy (regexps in
language syntaxm anyone? ), and it's not the only instance in Ruby. I
don't really like the Perl philosophy (like most of the people who
"get" Python), and I don't really believe a language whose designers
appreciate the perlisms poses a serious threat to Python. Not even if
they got some things right.

I suspect you're missing the point. I'm not advocating Ruby,
which has, as far as I am concerned, enough problems that
I'm not considering shifting at this time. What I am advocating
is looking at what it's doing right and asking if some of those
things might not improve Python.

Frankly, I don't know who these "heavy hitters" are, but they probably
have their reasons. Quick googling didn't turn out any useful articles
explaining why either of them has switched from Python to Ruby.

Let's see. Dave (the Pragmatic Programmer) wrote the textbook on
Ruby, and I think his preface says it quite nicely.

I am yet to see a feature list that would inspire me to switch, or
even consider switching. The little advantages Ruby has over Python
are dwarfed by the advantages of Python (of which the least is not
maturity, community and documentation).

As I said, my intent is not to inspire anyone to switch. My intent
is to ask whether there is anything they're doing that would be
(in concept if not in implementation) an improvement to Python.

John Roth