Python vs. Perl, which is better to learn?

Alex Martelli aleax at aleax.it
Mon May 6 17:06:03 EDT 2002


Jason Voegele wrote:
        ...
> I presume that your arguments regarding Python's properties also apply
> to Ruby's 'attr's?  (Not trying to start a rb vs. py thing here, just
> trying to understand).

Roughly, yes -- Ruby's "attr_accessor :whatever" in class scope basically 
takes you back to Python's default situation, while 'properties' are more 
smoothly defined in Ruby.  Seems more or less a wash.  I believe in Ruby
you cannot 'delete' an object's attribute, which Python makes easy (for
either a property or a 'real/normal' attribute), but I don't think that's a 
major issue in most cases.

> Yes, this is a very useful feature.  The analogous (although not quite
> equivalent) technique in Ruby is using Method or Proc objects that
> support a "call" method.  "Callable" objects in Ruby are those that
> have a "call" method, rather than a () operator.

The special-method in Python is called __call__; operator () [or builtin 
function apply] is the way it's invoked (just as special method __add__
is invoked by operator + or function operator.add, etc).  That's the
normal Python way (as I recall I first met something analogous in
Sather, albeit without the __ stropping -- to overload + your class
would define a routine called "plus").


> The Ruby approach requires a little more work to get "a reference to
> this thingy over here".  In Python, you do this by simply naming the
> thing (x.foo, as opposed to x.foo()).  Ruby's default behavior is to
> call the method with that name (x.foo and x.foo() are the same thing).
>  To get foo as an object, you must ask for it:  x.method(:foo).  Thus,
> x.method(:foo).call is a round-about way of saying x.foo().

Not quite as uniform and smooth as Python's access to x's methods and 
attributes, although presumably more or less equivalent in the end.  It IS
somewhat amazing how often Ruby and Python reach roughly equivalent
positions starting from polar-opposite approaches:-).


> Personally, I like the Eiffel mechanism the best (read only
> attributes, no parens for empty method calls, selective export, etc.).

It's another respectable set of tradeoffs, sure.  IMHO it makes the
language too complicated for what it buys you, but admittedly I've
never written substantial amounts of "production" code in Eiffel, so
my evaluation is not based on direct experience.


Alex




More information about the Python-list mailing list