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

--
Ville Vainio http://www.students.tut.fi/~vainio24

[John Roth]

Re: UserLinux chooses Python as "interpret ive language" of choice


"Ville Vainio" <ville.spammeha rdvainio@spamtu t.fi> wrote in message
news:du7ekv0z7g 3.fsf@amadeus.c c.tut.fi...[color=blue]
> 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".[/color]

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

[Steve Lamb]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice

On 2003-12-20, John Roth <newsgroups@jhr othjr.com> wrote:[color=blue]
> a third is the ability to forget the empty parenthesis after
> a function/method call that doesn't require parameters.[/color]

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

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

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[John Roth]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice


"Steve Lamb" <grey@despair.d miyu.org> wrote in message
news:slrnbu77jp .nh8.grey@dmiyu .org...[color=blue]
> On 2003-12-20, John Roth <newsgroups@jhr othjr.com> wrote:[color=green]
> > a third is the ability to forget the empty parenthesis after
> > a function/method call that doesn't require parameters.[/color]
>
> class ThisIs:
> avariable = 'a'
> def amethod(self):
> return 'b'
>
> thisis = ThisIs()
> print thisis.avariabl e
> print thisis.amethod( )
> import this
> print "Read line 2."[/color]

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]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice

"John Roth" <newsgroups@jhr othjr.com> writes:
[color=blue]
> a third is the ability to forget the empty parenthesis after
> a function/method call that doesn't require parameters.[/color]

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?
[color=blue]
> 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.[/color]

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

--
Ville Vainio http://www.students.tut.fi/~vainio24

[Bengt Richter]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice

On Fri, 19 Dec 2003 20:22:38 -0500, "John Roth" <newsgroups@jhr othjr.com> wrote:
[color=blue]
>
>"Steve Lamb" <grey@despair.d miyu.org> wrote in message
>news:slrnbu77j p.nh8.grey@dmiy u.org...[color=green]
>> On 2003-12-20, John Roth <newsgroups@jhr othjr.com> wrote:[color=darkred]
>> > a third is the ability to forget the empty parenthesis after
>> > a function/method call that doesn't require parameters.[/color]
>>
>> class ThisIs:
>> avariable = 'a'
>> def amethod(self):
>> return 'b'
>>
>> thisis = ThisIs()
>> print thisis.avariabl e
>> print thisis.amethod( )
>> import this
>> print "Read line 2."[/color]
>
>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.
>[/color]
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.avariabl e
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.std out).splitlines ()[2]
sys.stdout = sys.__stdout__
print "Read line 2."
print '... which is:', L2

Regards,
Bengt Richter

[Roy Smith]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice

Ville Vainio <ville.spammeha rdvainio@spamtu t.fi> wrote:[color=blue]
> If the extra features [...] were really
> worthwhile, they would be added to Python[/color]

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

[Skip Montanaro]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice


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

[Steve Lamb]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice

On 2003-12-20, John Roth <newsgroups@jhr othjr.com> wrote:[color=blue]
> I'm not sure what your point is.[/color]

If you had run it you would have understood it. You didn't run it, did
you?
[color=blue]
> Your example isn't going to produce the expected result if you say:[/color]
[color=blue]
> print thisis.amethod[/color]
[color=blue]
> instead of[/color]
[color=blue]
> print thisis.amethod( )[/color]

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.[color=blue][color=green][color=darkred]
>>> class ThisIs:[/color][/color][/color]
.... avariable = 'a'
.... def amethod(self):
.... return 'b'
....[color=blue][color=green][color=darkred]
>>> thisis = ThisIs()
>>> print thisis.avariabl e[/color][/color][/color]
a[color=blue][color=green][color=darkred]
>>> print thisis.amethod( )[/color][/color][/color]
b[color=blue][color=green][color=darkred]
>>> import this[/color][/color][/color]
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![color=blue][color=green][color=darkred]
>>> print "Read line 2."[/color][/color][/color]
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! :)

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Ville Vainio]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice

Roy Smith <roy@panix.co m> writes:
[color=blue][color=green]
> > If the extra features [...] were really
> > worthwhile, they would be added to Python[/color]
>
> Down that path lies madness (i.e. Perl).[/color]

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.

--
Ville Vainio http://www.students.tut.fi/~vainio24

[John Roth]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice


"Bengt Richter" <bokr@oz.net> wrote in message
news:bs0amc$hsl $0@216.39.172.1 22...[color=blue]
> On Fri, 19 Dec 2003 20:22:38 -0500, "John Roth" <newsgroups@jhr othjr.com>[/color]
wrote:[color=blue]
>[color=green]
> >
> >"Steve Lamb" <grey@despair.d miyu.org> wrote in message
> >news:slrnbu77j p.nh8.grey@dmiy u.org...[color=darkred]
> >> On 2003-12-20, John Roth <newsgroups@jhr othjr.com> wrote:
> >> > 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.avariabl e
> >> print thisis.amethod( )
> >> import this
> >> print "Read line 2."[/color]
> >
> >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.
> >[/color]
> 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.avariabl e
> 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.std out).splitlines ()[2]
> sys.stdout = sys.__stdout__
> print "Read line 2."
> print '... which is:', L2
>
> Regards,
> Bengt Richter[/color]

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]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice


"Steve Lamb" <grey@despair.d miyu.org> wrote in message
news:slrnbu7m1s .u03.grey@dmiyu .org...[color=blue]
> On 2003-12-20, John Roth <newsgroups@jhr othjr.com> wrote:[color=green]
> > I'm not sure what your point is.[/color]
>
> If you had run it you would have understood it. You didn't run it,[/color]
did[color=blue]
> you?
>[color=green]
> > Your example isn't going to produce the expected result if you say:[/color]
>[color=green]
> > print thisis.amethod[/color]
>[color=green]
> > instead of[/color]
>[color=green]
> > print thisis.amethod( )[/color]
>
> 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.[color=green][color=darkred]
> >>> class ThisIs:[/color][/color]
> ... avariable = 'a'
> ... def amethod(self):
> ... return 'b'
> ...[color=green][color=darkred]
> >>> thisis = ThisIs()
> >>> print thisis.avariabl e[/color][/color]
> a[color=green][color=darkred]
> >>> print thisis.amethod( )[/color][/color]
> b[color=green][color=darkred]
> >>> import this[/color][/color]
> 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![color=green][color=darkred]
> >>> print "Read line 2."[/color][/color]
> Read line 2.
>
> Line 2: "Explicit is better than implicit."
>
> thisis.amethod( ) is an explicit call to a method. If you flubbed it[/color]
and[color=blue]
> overwrote your namespace later on then you would get unexpected results at
> runtime. If you remove the () it becomes an implicit call depending on[/color]
the[color=blue]
> object that is a reference to. Hmmm, I guess I could have also finished[/color]
with[color=blue]
> this line as well, "Read line 12." IE, "In the face of ambiguity, refuse[/color]
the[color=blue]
> 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[/color]
special[color=blue]
> case when point to a function as opposed to any other object. D'oh, now[/color]
we[color=blue]
> need to read line 8, "Special cases aren't special enough to break the[/color]
rules."[color=blue]
> 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! :)
>
> --
> Steve C. Lamb | I'm your priest, I'm your shrink, I'm[/color]
your[color=blue]
> PGP Key: 8B6E99C5 | main connection to the switchboard of[/color]
souls.[color=blue]
> -------------------------------+------------------------------------------[/color]
---

[John Roth]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice


"Steve Lamb" <grey@despair.d miyu.org> wrote in message
news:slrnbu7m1s .u03.grey@dmiyu .org...[color=blue]
> On 2003-12-20, John Roth <newsgroups@jhr othjr.com> wrote:[color=green]
> > I'm not sure what your point is.[/color]
>
> If you had run it you would have understood it. You didn't run it,[/color]
did[color=blue]
> you?[/color]

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
[color=blue]
>
> --
> Steve C. Lamb | I'm your priest, I'm your shrink, I'm[/color]
your[color=blue]
> PGP Key: 8B6E99C5 | main connection to the switchboard of[/color]
souls.

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

John Roth

[John Roth]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice


"Ville Vainio" <ville.spammeha rdvainio@spamtu t.fi> wrote in message
news:du74qvwuv2 8.fsf@lehtori.c c.tut.fi...[color=blue]
> "John Roth" <newsgroups@jhr othjr.com> writes:
>[color=green]
> > a third is the ability to forget the empty parenthesis after
> > a function/method call that doesn't require parameters.[/color]
>
> 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?[/color]

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.
[color=blue][color=green]
> > 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.[/color]
>
> 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 ;-).[/color]

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

[Hartmut Goebel]

Re: UserLinux chooses Python as &quot;interpret ive language&quot; of choice

John Roth wrote:[color=blue]
> "Steve Lamb" <grey@despair.d miyu.org> wrote in message[color=green]
>> If you had run it you would have understood it. You didn't run it,
>> did you?[/color]
>
> It doesn't matter. As you can see by my reply to Bengt,[/color]

It does matter, since the _output_ of the result (which Steve posted for
your convenience) contains the answer to your question.
[color=blue]
> the crux of the issue is that, in Ruby, the function call
> syntax is *optional.*[/color]

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'.]
[color=blue]
> 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.[/color]

*walking to the fuel-station, filling my many-years-unused flame-thrower
for the upcoming flame-battle*
[color=blue]
> John Roth[/color]

--
Regards
Hartmut Goebel

| Hartmut Goebel | We build the crazy compilers |
| h.goebel@crazy-compilers.com | Compiler Manufacturer |