UserLinux chooses Python as "interpretive language" of choice

[John Roth]

John Roth wrote:
(snip)

Lol ! Tell us when you'll find a language that do not "make
opportunities for errors".

The non-existance of an example doesn't mean it isn't a
goal worth striving for.

John Roth

 

[Steve Lamb]

The non-existance of an example doesn't mean it isn't a
goal worth striving for.

Some errors aren't wroth attempting to prevent, esp. when they, in turn,
create the possibilty of worse errors down the road.

 

[Fernando Perez]

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.

I briefly scanned the thread, and didn't see (perhaps I missed it) anyone
metioning how this collides with the whole 'callables as first class objects'
philosophy of python. Maybe I'm missing something (I don't know a thing about
Ruby, so I'll speak strictly from the python side), but if parens were
optional, how would the following work?

# Here I want the function
local_fn = some.nested.module.function
# Here I want the result
local_var = some.nested.module.function()

Or:

try:
function_table[key]
except KeyError:
# do something

In this case, I DON'T want the function called, I just need to know if I have
it.

Anyway, in my code I have tons of cases where I critically need to distinguish
between using a 'naked' function and calling it, and I find it always a
pleasure that in python, simply using () or not allows me to, unambiguously,
handle both cases. Perhaps there is an alternative which I haven't seen or
understood, but I'm genuinely interested in how you'd approach this issue if
the () were optional. I'm also curious about how it is handled in the Ruby
world, which as I said I'm not familiar with.

Regards,

f.

 

[Jp Calderone]

sys.exit() doesn't return to caller -- but it doesn't mean it doesn't
return a value. Does this value is discarded? Didn't have time (and
need) to check out.

I hope we can finally put this topic to rest. sys.exit *does not have a
return value*:

static PyObject *
sys_exit(PyObject *self, PyObject *args)
{
PyObject *exit_code = 0;
if (!PyArg_ParseTuple(args, "|O:exit", &exit_code))
return NULL;
/* Raise SystemExit so callers may catch it or clean up. */
PyErr_SetObject(PyExc_SystemExit, exit_code);
return NULL;
}


See? "return NULL;" means "this function does not have a return value".
If you still do not believe me, please go study the Python/C API until you
do.

Jp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/57SVedcO2BJA+4YRAprAAJ9BD3BhFrPWw33/Yw6ykqGJoyMHWgCcDrSg
O6cdgYHoWyTPFTuBK7mKSNw=
=6c9V
-----END PGP SIGNATURE-----

 

[Francis Avila]

Fernando Perez wrote in message ...

Anyway, in my code I have tons of cases where I critically need to
distinguish
between using a 'naked' function and calling it, and I find it always a
pleasure that in python, simply using () or not allows me to, unambiguously,
handle both cases. Perhaps there is an alternative which I haven't seen or
understood, but I'm genuinely interested in how you'd approach this issue if
the () were optional. I'm also curious about how it is handled in the Ruby
world, which as I said I'm not familiar with.
###

I knew nothing about Ruby until a few minutes ago. It seems that the
paradigm is different: Ruby uses messages to methods (which attached to
objects), and methods themselves are not first-class, so there's no
ambiguity.
http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc

I can't understand the syntax in the example code that shows how you'd get a
Method object.

Of course, the typical Ruby accusation against Python is that it (Ruby) is
"purer OO". I don't know what they mean by "purer". If they mean the
fundamental types not being subclassable, that's an old wart that's very
nearly gone. Otherwise, I don't know what they could possibly mean,
considering absolutely everything in Python is an objects upon objects upon
objects. A class is an object, the methods of an instantiated class are
objects, the function a method wraps is an objects, the code of the function
is an object.... I think about the only thing that is not an object in
Python is a name, and I can't think how *that* would work.

If by "purer", all they mean is "more like SmallTalk", well, that's just
empty value judgment.

 

[Andrew Dalke]

Francis Avila:

Ruby uses messages to methods (which attached to
objects), and methods themselves are not first-class, so there's no
ambiguity.
http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc

I can't understand the syntax in the example code that shows how you'd get a
Method object.

I was thinking of how to elaborate on the description on that page, but
all I could come up with was basically a restatement. I'll give it a go
anyway.

In Ruby, the line

obj.methname(param1, param2)

is the same as
"send the message 'methname' with parameters 'param1' and 'param2'
to 'obj'"

In Python it is the same as
"get the method named 'methname' from 'obj' then call it with
parameters 'param1' and 'param2'"

In Ruby it's a one step process. In Python it's two steps.

In Ruby, the line

obj.methname

is the same as
"send the message 'methname' to 'obj'"

while in Python it's the same as the single step
"get the method named 'methname' from 'obj'"

There isn't a method per se in Ruby, but the base object
class knows how to convert a message into a function
object (a functor) which can then be called. However,
there are no functions in Ruby either, only objects which
take messages. So "f(1)" does not work (well, it can
because "functions" get turned into private methods of
the base object) and instead you call functors with the
"call" message.

Hence, to emulate Python's two-step method invocation
(where you get the bound method in the first step then
call the functor in the second step) in Ruby you need to do
it as

m = obj.methodmethname)
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.

(Let me try that again. All objects can receive the message
'method', because it's part of Ruby's base object type. The
'method' message comes with the name of the method. It
returns a new object which, when sent the 'call' message,
forwards that message to the original object but changes the
message type from 'call' to the desired message type, which
in this case was the name 'methname'.

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

Ruby has syntactic sugar to allow "functions" like this, but under
the covers it ends up making 'spam' be a private method of
the base object class. When you "call" it you really send
the message "spam" with the given count value to the base
object class.

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.

A class is an object, the methods of an instantiated class are
objects, the function a method wraps is an objects, the code of the function
is an object.... I think about the only thing that is not an object in
Python is a name, and I can't think how *that* would work.

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

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.

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

Andrew
(e-mail address removed)

 

[Francis Avila]

Andrew Dalke wrote in message ...

Francis Avila: get

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

m = obj.methodmethname)
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.)


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.

 

[John Roth]

Of course, the typical Ruby accusation against Python is that it (Ruby) is
"purer OO". I don't know what they mean by "purer".

I suspect they are objecting to the use of built-in functions, and
the use of functions in modules. Ruby
uses methods for everything, and everything inherits from a base
object that has a huge number of methods. Python is simply not
going to go down that path. Personally, I don't have any opinion
about which is better, both styles work.

The other possibility is the pervasive use of the visitor pattern
rather than Python's use of for statements for iterations. This,
combined with the ease of creating anonymous functions, does
seem to make a significant difference - at least it's what most
Ruby afficianados talk about when they say what they like about
the language.

If they mean the
fundamental types not being subclassable, that's an old wart that's very
nearly gone. Otherwise, I don't know what they could possibly mean,
considering absolutely everything in Python is an objects upon objects upon
objects. A class is an object, the methods of an instantiated class are
objects, the function a method wraps is an objects, the code of the function
is an object.... I think about the only thing that is not an object in
Python is a name, and I can't think how *that* would work.

Interesting question, especially since it does seem to come up
every few months.

Technically, since names are simply keys in dictionaries, they
*are* objects. I think the descriptor facility is a start on
addressing that question, though.

Rather than asking how it would work (the obvious answer
is a different dictionary implementation for use in objects)
it might be better to ask what you would use it for.

John Roth

 

[Dang Griffith]

The non-existance of an example doesn't mean it isn't a
goal worth striving for.

John Roth

I think Niklaus Wirth owes you a lollipop.
--dang

 

[Terry Reedy]

message The word 'name' is used in multiple senses in
Python, which seems to sometimes get confused.

But a name is part of an object.

Modules, classes, and functions have a __name__
attribute for the purpose of forming a string
represention. Other builtins do not. This is the
secondary use of 'name'. Otherwise, 'names', in
the primary sense as code token, are *not* parts
of an object.

Namespaces arise from objects possessing names.

Since objects only 'possess' token names by virtue
of being associated with them in namespaces, this
does not seem a useful viewpoint.

This is why I can't see how names can be

objects in Python:

Token names are grammatical code units, like
expressions and statements (which are also not
objects *in* Python). We use them to direct
computation with objects. The interpreter may
implement token names (and namespaces) in any way
consistent with the defined semantics of the
expression and statement they occur in. CPython,
in particular, sometimes converts them to Python
strings and sometimes to C ints.

they are incapable of existing independent of an

object.

They exist in code prior to the creation of ojects
due to running of the code.

Technically, since names are simply keys in

dictionaries,

This is only true of attribute names, the third
use of 'name'. Definition names start as code
token names and become values of a __name__
attribute, not a key. Code token names otherwise
become whatever the interpreter does with them,
which might or might not be to make them a Python
dictionary key.

Terry J. Reedy

 

[Terry Reedy]

Of course, the typical Ruby accusation against Python is that it (Ruby) is
"purer OO". I don't know what they mean by "purer".

I suspect they are objecting to the use of built-in functions, and
the use of functions in modules. Ruby
uses methods for everything, and everything inherits from a base
object that has a huge number of methods. Python is simply not
going to go down that path. Personally, I don't have any opinion
about which is better, both styles work.

The other possibility is the pervasive use of the visitor pattern
rather than Python's use of for statements for iterations. This,
combined with the ease of creating anonymous functions, does
seem to make a significant difference - at least it's what most
Ruby afficianados talk about when they say what they like about
the language.

If they mean the
fundamental types not being subclassable, that's an old wart that's very
nearly gone. Otherwise, I don't know what they could possibly mean,
considering absolutely everything in Python is an objects upon objects upon
objects. A class is an object, the methods of an instantiated class are
objects, the function a method wraps is an objects, the code of the function
is an object.... I think about the only thing that is not an object in
Python is a name, and I can't think how *that* would work.

Interesting question, especially since it does seem to come up
every few months.

Technically, since names are simply keys in dictionaries, they
*are* objects. I think the descriptor facility is a start on
addressing that question, though.

Rather than asking how it would work (the obvious answer
is a different dictionary implementation for use in objects)
it might be better to ask what you would use it for.

John Roth

 

[John Roth]

dictionaries,

This is only true of attribute names, the third
use of 'name'.

That's the sense I assumed Francis Avila was
using the term in, and I didn't particularly care
to be pedantic and discuss the different ways
the word 'name' can be used, espeially since
Lewis Carroll did such a fine job of it once.

Of course, I could be wrong about which
usage he intended.

John Roth