UserLinux chooses Python as "interpretive language" of choice

[John Roth]

"Ville Vainio" <ville.spammehardvainio at spamtut.fi> wrote in message
news:du7r7yzzmw6.fsf at mozart.cc.tut.fi...
> "John Roth" <newsgroups at jhrothjr.com> writes:
>
> > > > 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?
>
> > 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.

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.

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

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

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

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
>
> -- 
> Ville Vainio   http://www.students.tut.fi/~vainio24