UserLinux chooses Python as "interpretive language" of choice

[Francis Avila]

Andrew Dalke wrote in message ...
>Francis Avila:
>> I can't understand the syntax in the example code that shows how you'd
get
>a
>> Method object.

The "messaging" concept was clear, but I didn't understand how one got a
method out of a message.

>m = obj.method(:methname)
>m.call(param1, param2)
>
>where 'method' is a method of the base object type which
>takes the method name and returns a bound Method object.

It's the colon syntax I didn't get.  I think it's clearer to me now.

Python also has a call "message": obj.__call__().  This can be viewed as a
shorthand for obj().  So we can claim this "feature" if we like. :)  It
doesn't completely cover over the messaging v. attribute access distinction,
but it's close.

>Any better?  It really does help if you think of Ruby as sending
>message and not as getting callables.)
>
>> Of course, the typical Ruby accusation against Python is that it (Ruby)
is
>> "purer OO".  I don't know what they mean by "purer".
>
>It is in part because of Python's old class/type dichotomy.
>
>It's also because Python lets you create instances which are
>not part of any class or instance.  For example, Python has
>functions, like
>
>def spam(count):
>  print "Spam " * count
>
>These are not part of any object.  (Well, perhaps the module
>object, but it isn't a method of the module type.)

To my mind, it's a function object, and functions are a base type.  What
it's a "part" of is almost meaningless.  It's an object floating in the
void, and there's a name, belonging to the module object (a different
object), that points to that object.  But a name is part of an object.  So
objects are still essential, but they possess means of referring to one
another (names).  Namespaces arise from objects possessing names.

This is why I can't see how names can be objects in Python: they are
incapable of existing independent of an object.

>Philosophically then, while you could think of everything in
>Python as OO it isn't as "pure" as Ruby because we tend
>to think of modules, instances, attributes, variables, and
>classes as different things, while Ruby doesn't make that
>strong of a distinction between them.

This I don't understand.  It's a different view of things, but it seems to
me that Python is more concrete, rather than less "pure" (neither seems more
pure to me, at this point).  A Pythonista says "everything is an object",
and that means that everything an entity with names that point to other
entities.  A Rubyite (?) says "everything is an object", they mean something
different.  What precisely do they mean?  Everything is an instance of one
fundamental essence?  We can claim this too, although it's not really how we
think.  Can the Rubyite say that they have fewer fundamental concepts?  We
have two: names and objects.  Ruby has two: objects and messages.  So both
have a thing, and a way of relating things.  It's just that Ruby's relations
point in the opposite direction from ours.


>Perhaps this is a good way to think of the difference.
>  Python thinks namespaces are one honking great idea
>  Ruby thinks OO is one honking great idea

Rather, "Ruby thinks messages are one honking great idea"?  They're both OO.
I fail to see how namespaces are possible without OO.

>Python's modules, classes, instances, and locals are all
>namespaces.  They happen to be specific types in a
>type system which is nearly unified.
>
>Ruby's modules, classes, instances, and locals are all
>instances, each of which defines its own namespace.

Hmm, I think Python and Ruby both have both, although the emphasis may be
different.

In Python, an instance presupposes three entities: the instance, the name
pointing to the instance, and the object that possesses the name, and in a
sense "contains" it.  (The nesting is artificial and accidental, though;
really all objects are floating in a void, but only names make them
accessable to one another--whence the structure arises.)

Perhaps we can say the difference is that Python objects are extroverted
(name points to another object; object possessing the name is transparent to
itself), while Ruby objects are introverted (object possesses a message
interface, which other objects talk to from the "outside")?

I see a clear parallel between Python and analytic philosophy's approach to
objects and accessing objects. (Their maxim is "a name is an idea that
points to a thing", and of course since the thinker is a thing himself,
names adhere in things, like people, books, etc.)  I don't know what Ruby
corresponds to, but it's not the name/thing duality, that's for sure.

>(NB: I've never coded Ruby only read the docs and followed
>the newsgroup for a couple of months, so my perception
>can be wrong, but I suspect it isn't that wrong.)

It's more insightful than my thoughts.  However, I can't think of what the
underlying difference is between messages vs. names.  I don't think your
proposal of Namespaces/OO quite works, because names are attached to
objects.  Objects are equally fundamental to both.  What's different is how
they concieve of the *relation* between objects, and how this difference is
relating objects makes one conception "purer" OO than the other escapes me
completely.
--
Francis Avila