What's better about Ruby than Python?
jacek.generowicz at cern.ch
Fri Aug 22 11:10:29 CEST 2003
You wrote lots. Forgive me if I don't address everything.
What's better about Ruby than Python?
jacek.generowicz at cern.ch
Fri Aug 22 11:10:29 CEST 2003
You wrote lots. Forgive me if I don't address everything. I wish I had
the time to address all your points more carefully.
"Andrew Dalke" <adalke at mindspring.com> writes:
> However, at present, the only example I've seen for when to use a
> macro came from a method cache implementation that I could implement
> in Python using the normal class behaviour,
Or using directors, or lexical closures. Similarly in Lisp, there is
more than one way to do it, and many would not choose the macro option
when implementing a memoizer.
> so I don't have a good idea of when macros would be appropriate
> *for* *Python*.
(Looks like you've found a need for them yourself - see later on.)
Well, frankly, in the context of Python, I find the whole discussion a
bit abstract. Lisp macros fundamentally rely on the fact that Lisp
programs are represented as lists, and that Lisp includes excellent
support for manipulating such lists. The consequence of this (source
code being a form of data) is that it is extremely easy to manipulate
Lisp source code within Lisp. You can already achieve similar things
in Python by typing your source code as a string, and performing
string manipulations on it, and then calling eval... but it is many
orders of magnitude more painful to do it this way.
Alternatively, get your hands on the parse-tree (I believe there's a
module to help), and mess around with that. That should be much easier
that playing with strings, but still much more of a pain than Lisp
> When this topic has come up before, others mentioned how
> macros would theoretically be able to, say, modify list.sort
> to return the sorted list after it has been modified in-place.
You don't need macros for that. With the advent of new-style classes,
you subclass list, override the sort function, and replace
__builtins__.list (maybe there's more to it, but as this is not
something I ever intend to do, forgive me for not checking the
> Given the not infrequent request for the feature, I know that
> i