UserLinux chooses Python as "interpretive language" of choice

[John Roth]

"Steve Lamb" <grey at despair.dmiyu.org> wrote in message
news:slrnbu7m1s.u03.grey at dmiyu.org...
> On 2003-12-20, John Roth <newsgroups at jhrothjr.com> wrote:
> > 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.
> >>> class ThisIs:
> ...     avariable = 'a'
> ...     def amethod(self):
> ...         return 'b'
> ...
> >>> thisis = ThisIs()
> >>> print thisis.avariable
> a
> >>> print thisis.amethod()
> b
> >>> import this
> 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!
> >>> print "Read line 2."
> 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.
> -------------------------------+------------------------------------------
---