merits of Lisp vs Python

[JShrager]

Python is fun to use.
Easy to read.
Simple and powerful.
Easy to test.
Easy to maintain.
Fast. Very fast!

Okay, I'm going to commit another rhetorical fallacy here called
"Argument from Authority": I challenge anyone making psychological
claims about language X (for any X) being easier to either
read/learn/use than language Y (for any Y) to come up with any valid
evidence whatever. Having a PhD in Cognitive Psychology (as well as two
degrees in computer science) where my subject was how people learn to
program (among other things), and having extensive experience in this
field, I am almost certain that no such evidence exists (at least not
for any real programming language). Now, like any good scientist, I
could be wrong, but you'd have to convince me, and I very much doubt
that you could.

While I'm engaging in this particular fallacy, here's another instance:
Since I'm probably (although I'm not certain) the only person in this
thread who has made a significant amount of money on either of these
languages (i.e., via the sale of a startup whose product was tens of
thousands of lines of Lisp code, and some Tk GUI stuff), and knowing
both Lisp and Python (although I'm certainly not a Python wizard), I am
nearly certain that what we did in Lisp COULD NOT HAVE BEEN DONE IN
PYTHON -- PERIOD. The reason has little to do with macros (although
they were very helpful, of course, esp. in making Tcl look like a
reasonable language so that we could use Tk); it has to do with speed,
which has to do with compilers, which, as it turns out, has to do with
macros. (See below.)

Now, speaking as a scientist, permit me to make a small practical
suggestion: Why not just figure out a way to simplify some brand of
Python -- make parens (or whatever) optionally replace whitespace and
line breaks as syntax -- and then add a simple macro facility -- macros
are actually a very simple extension if you have homogenous syntax,
homogenizing your syntax to the point where macros are possible is the
hard part -- and just see what happens. One of two general things are
likely to happen: Either people will not use them, and they will
languish and die, and then at least you can say; "Been there, done
that" to the Lisp community. Or, more likely, the some subset of the
Python community will get it, and will figure out how useful they are,
although it might take some time. And then you might find yourself with
a wonderful new tool. You might even get a compiler out of the deal, at
a pretty low cost, too! If you get macros, and get a compiler, I'm
pretty sure that you will have no problem winning over the Lisp
community, who would LOVE to have your extensive libraries, and that
you will probably be able to maintain and improve your flagging
position wrt Ruby (which, according to Matz, is more-or-less just Lisp
w/o macros.)

I'm not saying that this is going to be an easy or quick experiment,
but it's one that I, and I think most Lispers, would both like to see
happen, and would benefit from! Moreover, I dare say that some of us in
the Lisp community would love to HELP -- at least I would, and I'm
guessing that others would as well.

(Unless you guys get a compiler too, you'll always just be a
scripting language, but compilers are GREATLY facilitated by having a
macro facility because (at first blush) all you need to do is to
macro-expand down to something you know how to turn into code. This
isn't the only, nor perhaps the best way to get a compiler, but it's
a step in that direction. Later on you can learn the other great
features offered by homogeneous syntax, like being able to write code
walkers, which help improve over the "first blush" compiler. Soon
enough, I predict, you'll be so far past us and Ruby that...well,
even Kenny with jump on board!

 

[Joel Wilsson]

Yes, that's right. And if they insist on using their specialist language
where "that's bad" means "that is best quality", and I insist on using
my language where "that's bad" means "that is worst quality", how much
successful communication are we going to have?

Having such a specialist language, which goes against common
practice, would be stupid. There nothing to gain from doing so,
so it's not done.

The same is true for macros. Redefining everything and programming
in your own special way just to be different would be stupid, and
it's not done.
Everyone keeps telling you this but you keep ignoring it.

Wonder why.

Macros are used where they must be used, to do things that are not
possible with functions. Functions have benefits that macros don't
have, and for most things (but not all things), those benefits are
more useful than the benefits provided by macros.

I will also note that Ken Tilton was right about analogies, and
far too much of this discussion is now about English language, not
the merits of Lisp vs Python. Sad, because there is some good
stuff in here.

 

[Alex Mizrahi]

(message (Hello 'Paul)
(you :wrote n '(10 Dec 2006 04:36:43 -0800))
(

??>> so, it's very close to writting new interpreter -- but it's order of
??>> magnitude easier to write this interpreter via macros than from
??>> scratch, most other language constructs can be reused.

PR> But now you've got an interpreter and you no longer have that Lisp
PR> compiler.

why do you think so?
if you have C compiler that translates C to assembly, and then compiles
assembly to machine language -- that's not C compiler, not asm compiler, or
what?
yes, possibly it would be sub-optimal, but at least it will work. and
normally there would be no big performance penalties.

??>> there is a chapter about continuations in Paul Graham's "On Lisp".
??>>
??>> "Common Lisp doesn't provide call/cc, but with a little extra effort
??>> we can do the same things as we can in Scheme. This section shows how
??>> to use macros to build continuations in Common Lisp programs."

PR> I think he's mistaken about being able to implement call/cc in full
PR> generality with CL macros in any reasonable way.

why do you think so?
you know some case that does not work with call/cc?
i was programming quite significant working system with call/cc in Common
Lisp.
and although there were some glitches, it was doing quite well.

PR> But it might be possible to implement enough to do something like
PR> Python generators using lexical closures that one re-enters through
PR> some kind of cond statement selecting the yield point to be continued
PR> from.

why are you theoretizing -- i've showed working real example of generators!
just get SBCL and ARNESI, load it, and then use call/cc as i've shown in
example. that's real generators. there's no need for any cond -- you can
save state as current-continuation.
if you don't understand how it works, run macroexpand -- it's quite simple
thing.
you can find full defgenerator code here

http://www.cl-user.net/asp/Mi4$4/sdataQvxM$sStWNjUDQ3t9G8X8yBX8yBXnMq=/sdataQu3F$sSHnB==

you can find also other implementations of defgenerator's -- but with
ARNESI's CPS call/cc works with LOOP (that's actually surprising -- since
loop uses TAGBODY/GO -- maybe their code walker mutates TAGBODY making it
functional-style, or something like that).

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")

 

[Steven D'Aprano]

Since I'm probably (although I'm not certain) the only person in this
thread who has made a significant amount of money on either of these
languages (i.e., via the sale of a startup whose product was tens of
thousands of lines of Lisp code

Care to tell us what the startup was, and where it is now?

 

[Steven D'Aprano]

Ah, nice to get a straight answer to a question for a change, and without
an insult or a misrepresentation in sight. Thank you.

Such a pity that answer is, apparently, wrong.

Thank you to those who wrote back with the more accurate answer, which
apparently is "yes, it is easy and there are no error messages".

I'd love to say it has been fun, but it has been more frustrating than
enjoyable. I don't mind an honest disagreement between people who
genuinely are trying to see the other's point of view, but I don't think
that was the case here. What was especially frustrating was that the more
I tried to understand certain Lispers' positions by asking questions, the
more nasty and insulting they became. So now I have an even better
understanding for why Lispers have a reputation for being difficult and
arrogant.

(And believe me, I could say a lot more about that, but I'm trying to be
conciliatory, so I'll just shut up now.)

But I also gained a little more insight into why Lispers love their
language. I've learnt that well-written Lisp code isn't as hard to read as
I remembered, so I'd just like to withdraw a comment I made early in the
piece. I no longer believe that Lisp is especially strange compared to
natural languages.

Anyway, real life catches up on me, and so I must drop out of this thread.
May it not last for ever.

 

[Bill Atkins]

I'd love to say it has been fun, but it has been more frustrating than
enjoyable. I don't mind an honest disagreement between people who
genuinely are trying to see the other's point of view, but I don't think
that was the case here. What was especially frustrating was that the more
I tried to understand certain Lispers' positions by asking questions, the
more nasty and insulting they became. So now I have an even better

Could that be because you were submitting enormous posts making the
same claim and ignoring any new developments several times a day?

But I also gained a little more insight into why Lispers love their
language. I've learnt that well-written Lisp code isn't as hard to read as
I remembered, so I'd just like to withdraw a comment I made early in the
piece. I no longer believe that Lisp is especially strange compared to
natural languages.

Strange that you'd come to that conclusion. I thought we'd
established higher up that most programming languages are not like
natural languages

 

[Stefan Nobis]

Which just proves my point. If people don't share the same language
constructs, the same words, the same grammar, etc, they can't
understand each other.

Yes, but that depends *much* more on social background, habits,
experience than on technical details like correct syntax, orthography
etc. Do you know about studies with texts where the letters of each
word are disordered except the first and the last and nearly everyone
was able to read this (OK, it took a little bit more time, but it was
readable)? So much to the importance of syntax and orthography.

Essentially every group of people, scene, community has it's own
special language and if you want to communicate with them, you have to
learn this language. Excatly the same goes for software projects with
their libraries -- completley independet of the technical background
of the abstractions (functions, classes, macros,...) the libraries
provide.

It's really funny to see how you try to create and defend a purely
factitious line between abstraction techniques like functions,
classes, and even operator overloading and shadowing on the one side
and those big bad macro monsters on the other side.

 

[JShrager]

Care to tell us what the startup was, and where it is now?

Sure. We were called Afferent, Inc. We did simulated organic chemistry,
robot planning and control, and semi-automatic products analysis for
combinatorial chemistry for drug discovery for the pharmaceutical
industry. Founded in, um, ~1996? we were acquired in, um, 1999? (sorry,
I'm a little fuzzy on the dates) by MDL, Inc. for ... well, I'm not
sure that I'm supposed to say how much, so I won't. If someone can find
it in the public record, please feel free to post it. Let's just say
that we weren't a Dot Com but we also weren't particularly unhappy
about the deal.

BTW, I didn't mean to imply that only reason that we used Lisp was the
compiler. What we were doing was more-or-less AI, and we wouldn't have
even thought to try to use anything other than Lisp. (I won't say that
we couldn't have in theory done it in another compiled language for
fear of attack by the Turing Mafia! What I meant was the we
certainly would not have even consider Python or any other uncompiled
language because it would have been WAY too slow! Our (delivered
executable!) product could do hundreds of thousands of simulated
chemical reactions and solve robot planning problems in seconds. (The
robot planning was actually pretty simple. The simulated chemistry was
decidedly NOT!) The Tk-based GUI was by far the slowest part of the
system!

I have the code here (probably not the latest bcs I left the company
when it was acquired), let's do a little experiment, for what it's
worth: 89727 lines of Lisp code in 131 modules (lisp code files), 3306
"(defun" (by grep|wc), and 261 "(defmacro". [We did NOT use
macros as functions!] [Note that lines of code doesn't really matter
in Lisp.]

If you are interested, you can read a little about our product in this
paper:


http://nostoc.stanford.edu/jeff/personal/vita/pubs/2001designforscience.pdf

as well as seeing a little of the interface. (If you have any interest
in history of science, EScience, or drug discovery, you might even find
the content of the paper interesting!

 

[Paul Rubin]

PR> But now you've got an interpreter and you no longer have that Lisp
PR> compiler.

why do you think so?
if you have C compiler that translates C to assembly, and then compiles
assembly to machine language -- that's not C compiler, not asm compiler, or
what?
yes, possibly it would be sub-optimal, but at least it will work. and
normally there would be no big performance penalties.

There would be terrible performance penalties dealing with the
environment lookup on every lexical variable reference. That's the
point. The compiler would treat those as references to slots in the
call frame, would do type inference so it could use unboxed atoms
where it could, etc. You'd lose all that.

PR> I think he's mistaken about being able to implement call/cc in full
PR> generality with CL macros in any reasonable way.

why do you think so?
you know some case that does not work with call/cc?

I don't see how to implement coroutines with CL macros. Maybe I'm
missing something.

why are you theoretizing -- i've showed working real example of generators!
just get SBCL and ARNESI, load it,

Too much hassle, I haven't used CL in many years and can't see doing
the big download etc. just to try out one example. It's not like I'm
going to suddenly discover the delights of CL. Been there, done that.
I might re-read the LTU papers to see if I'm missing something about
how CPS works. I've always been hazy on that stuff.

and then use call/cc as i've shown in
example. that's real generators. there's no need for any cond -- you can
save state as current-continuation.

Fully general call/cc has to be able to switch from one execution
stack to another and back. However, that is not needed for Python
generators ("simple generators"), which can only yield to their direct
caller. I think you might be able to do simple generators with messy
macros but I don't see how you can do call/cc, jumping out to the
continuation across many levels of function calls and then returning
back into all those calls. The contination is not just a machine
address or environment, it carries a lot of other state.

 

[Wade Humeniuk]

But I also gained a little more insight into why Lispers love their
language. I've learnt that well-written Lisp code isn't as hard to read as
I remembered, so I'd just like to withdraw a comment I made early in the
piece. I no longer believe that Lisp is especially strange compared to
natural languages.

Anyway, real life catches up on me, and so I must drop out of this thread.
May it not last for ever.

And I have heard why Pythonistas like their language. They can get things
accomplished in it. The best positive feedback is success. You can get
lost in theoretical, metaphorical discussions about computer languages.
It is frustrating and in many cases pointless.

As for why you have seen conflicting answers and, yes, sometimes hostile
responses. I have no idea. But, I think I have come to a point in my
life where I do not need to be right.

W

 

[Paul Boddie]

(e-mail address removed) skrev:

The reason has little to do with macros (although
they were very helpful, of course, esp. in making Tcl look like a
reasonable language so that we could use Tk)

How long ago was this? ;-)

[Macros in Python]

Either people will not use them, and they will languish and die, and then
at least you can say; "Been there, done that" to the Lisp community.

Well, someone did write Logix probably with the intention of getting
interest from the community:

http://livelogix.net/logix/

It's already been noted what the response has been.

Or, more likely, the some subset of the Python community will get it,
and will figure out how useful they are, although it might take some time.

I've been interested in macros for Python, and you'll find other people
with similar views:

http://www.fiber-space.de/EasyExtend/doc/EE.html

That said, you'll find the discussion about macros to be quite open,
occasionally even on the Python development lists. But it is also
important to note that the development and usage of Python is not
guided from purely technical motivations (or from technically pure
motivations), and the heated discussion about natural language
analogies reveals that just as people are content to form communities
around certain kinds of literature, so are people interested in forming
communities around developing certain kinds of systems.

[...]

you will probably be able to maintain and improve your flagging
position wrt Ruby (which, according to Matz, is more-or-less just Lisp
w/o macros.)

I think this would be a fairly weak argument for what would otherwise
be a reasonable suggestion. "Come over to my way of thinking or be
destroyed" sounds like something the Emperor would say to Luke
Skywalker. And we all know how that ended. ;-)

And on the subject of remarks about Python developers somehow being
remote controlled by the BDFL, I think that anyone who takes a closer
look will see varying levels of dissent and dissatisfaction, just as
you'd find in any community. Again, many more issues must be considered
to understand why people keep using Python (or alternatively stop using
it).

Paul

 

[Kirk Sluder]

Okay, I'm trying to meet a common ground here, but you're not making it
easy. Of course English, like all languages, restricts what can be said in
that language. I'm talking about grammar and syntax, not semantics, just
like I said at the beginning.

Well again, the question is exactly *what* is doing the restricting?
What will happen if you make an "illegal" statement in English? If
you can't define some sort of mechanism inherent in the English
language that prevents the expression of "illegal" utterances, then
you can't make the claim that "English. .. restricts what can be
said in that language." This is a technical point, but not a
trivial one. That is one heck of an active verb that you are
attributing to an extremely passive noun.

If you want common ground, it appears that we both agree that
language practices are enforced by social communities. Is this not
the case?

Oh, you might also like to look up what a straw-man argument is before
continuing to accuse people of making it. There seems to be this myth on
the Internet and Usenet that a straw-man argument is "any argument I don't
like, or don't understand, or can't refute".

Certainly. A straw man is an artificially weak position that you
attribute to your opponent. You chose to argue against the
artificially weak position of "there are no rules." You attributed
that position to me, not acknowledging my stated position. In what
way is this not a straw man?

You now claim to agree with the position I actually stated: language
is restricted by social communities that use language. If we both
agree on this position, we can move on back to the discussion on how
those norms and practices discriminate against unlispy/unpythonic
language extensions.

That might be true in the case of public code which is open to the entire
community, but it isn't true of all code. Not all code is open to the
wider programmer community to inspect. Code gets written in small teams,
or by individuals, and then it gets used by potentially millions of people
who never got to review the code but have to suffer the consequences of
any bugs in it.

What do people who don't need to read code, or don't need access to
code matter in regards to code readability?

And yes, small teams do constitute a linguistic community of
practice as well. But I don't know of many small teams who don't
have histories as members of larger communities of practice.

(I'm not saying this is uniquely a problem caused by Lisp macros. Don't
misinterpret what I'm saying.)

Which comes back around again to my constant question. Why do these
threads consider macros as a way to extend the language so much more
of an obfuscatory threat compared to other methods of language
extension: (including libraries, operator overloading, and
polymorphism?)

 

[Bill Atkins]

You know, I'm really starting to think that you Lispers -- and I hate to
generalise, but in this case I feel I'm forced to -- have a real problem

You feel you're forced to generalize about an entire group of language
users based on what a handful of people have posted on a newsgroup?

So which is it? If Lisp is so self-evidently better than every other
language, and if nobody has any fears or concerns with Lisp, why is Lisp a
fringe language? Not as fringe as it was ten years ago, and maybe growing
in popularity, and it is beyond all doubt that Lisp has a lot of influence
amongst language designers, but outside of a few niche areas, its still a
fringe language.

I'd like to know the answer. But the problem most people cite is the
parentheses, not the fear that someone will abuse macros. I have
certainly never seen anyone as worried about macros as you seem to be.

Yes. But you can't redefine 1+2 in Python, at least not without hacking
the interpreter. Can you redefine (+ 1 2) in Lisp?

Yes. Can't you redefine standard functions in Python?

Frank Buss correctly points out that you can shadow the + symbol and
make it whatever you'd like it to be. This is true, but now someone
has to intentionally and specifically import the package containing
that shadowed + into their own package. You are never unwittingly
using a different + than the standard CL one, although you really seem
to want this to be the case.

Text is data.

What is the point of your comment? You don't have to argue about every
thing I say, even the ones we agree on. Look again at what I wrote. Is
there anything that gave you the impression that I think that having the
ability to write text to a file and import it is better than actually
supporting functional programming directly?

Well, text is not code. Text is a syntaxful representation of the
actual code, which is an AST. If I have a string full of text, I
can't do very much meaningful work with it. On the other hand, if I
have an AST, I can transform it or analyze it however I choose.

Okay, once was funny. Twice is worrying. What exactly is giving you the
idea I need to calm down? Was it the use of reasoning and logic?
Perhaps it was the attempt to be reasonable and moderate and find some
middle ground that we could agree on, or if not agree, at least say "Well,
I disagree with you, but at least I understand where you are coming from"?

Where I'm coming from? Dude, you're writing paragraph upon paragraph
about the same thing, multiple times per day. You're terrified of
worst-case scenarios that everyone else is telling you are not
realistic.

 

[Bryan]

I wonder, how many people gave up trying to learn Lisp because the
language was too hard for them to read? Anyone like to bet that the number
was more than zero?

steven, you bring back awful memories in my college days, we had already
learned fortran, pascal, c, snobol, prolog and some assembly. then we took
a lisp class. what a complete nightmare!!! except for that one brainiac
kid who was on "another planet", the rest of the class (about 30 people)
could not grasp lisp at all. the teacher was always pissed off. he kept
telling us it was such an easy language and it's so powerful and kept
saying our lisp code looked like pascal. so, for the final he
intentionally gave us problems that if you don't think in a lisp way you
couldn't solve the problem within the time given. of course everyone
failed or got a D. my point is i know at least 30 people that could code
in other languages just fine, but not lisp. i've tried to learn it on my
own several times since then, but it's just too difficult for me. my brain
just doesn't work that way i guess. with python, my brain doesn't hurt. i
can program in a very relaxed way and it seems that whatever i'm thinking,
i can just write it naturally in python. for me personally that's how i
define "expressiveness" eventhough others here would disagree on
what "expressiveness" means.


bryan

 

[Pascal Bourguignon]

Yes. Can't you redefine standard functions in Python?

Frank Buss correctly points out that you can shadow the + symbol and
make it whatever you'd like it to be.

Well, there is no "THE + symbol", there are a lot of different symbols
named "+". The one you get when you read the characters of "(+ 1 2)"
depends on the dynamic binding of the COMMON-LISP:*PACKAGE* symbol.

This is true, but now someone
has to intentionally and specifically import the package containing
that shadowed + into their own package. You are never unwittingly
using a different + than the standard CL one, although you really seem
to want this to be the case.

The Common Lisp standard has no provision to and indeed forbid to
modify the function binding of the COMMON-LISP:+ symbol.

On the other hand, implementations may allow, sometimes with the help
of an implementation specific WITHOUT-PACKAGE-LOCK operator, to change
the function binding of the COMMON-LISP:+ symbol.

So, while the standard preserves itself, and wants you to explicitely
say you're using a symbol named "+" from a different package than
COMMON-LISP, rather than modifying CL:+, the implementations may still
allow you to actually modify the COMMON-LISP package, but of course,
this may not be Common Lisp anymore, if you don't follow the
specifications of Common Lisp (and if you do, why are you trying to
modify CL:+ that already implements Common Lisp!?).

 

[Bill Atkins]

The Common Lisp standard has no provision to and indeed forbid to
modify the function binding of the COMMON-LISP:+ symbol.

I'm not talking about redefining the + symbol; I'm talking about
shadowing it and defining a new function on a different symbol that
has the same symbol-name.

 

[hit_the_lights]

Given that the meaning of import doesn't need to have changed to bring
out the described consequences, I guess anyone wanting to know more
won't be asking you specifically.

I should have added some lines:

==== python ====================You sucker thought I'd import b for you.
Instead I'm going to erase your hard drive.==============================

I was suprised that b was defined at all.

 

[tayssir.john]

I'd love to say it has been fun, but it has been more frustrating than
enjoyable. I don't mind an honest disagreement between people who
genuinely are trying to see the other's point of view, but I don't think
that was the case here. What was especially frustrating was that the more
I tried to understand certain Lispers' positions by asking questions, the
more nasty and insulting they became. So now I have an even better
understanding for why Lispers have a reputation for being difficult and
arrogant.

This is only because they openly disagree with your beliefs. Note that
you appear the same way to your Lisp-using flamewarrior counterparts.

We might look in the mirror:
<http://www.escapefromcubiclenation.com/get_a_life_blog/2006/04/how_the_technog.html>

Maybe Lisp users are singled out as particularly arrogant because they
claim that the last 20 or so years of the software profession have been
something of a fraud.


Tayssir

 

[Paul Boddie]

I should have added some lines:

==== python ====================
You sucker thought I'd import b for you.
Instead I'm going to erase your hard drive.
==============================

I was suprised that b was defined at all.

Well, I've done all sorts of things with Python's import machinery, and
I'd prefer not to stare too long at its implementation, but both import
statements by their very nature in Python are still import statements.
Of course you can always argue that some undesirable effect of
redefining the keyword via a macro is also achievable by misusing the
import machinery, that both things are therefore just as dangerous, and
that macros are inherently no more dangerous than exposed library
mechanisms employed by the virtual machine. I'd agree generally with
that reasoning, and you can see in various features of Python that lots
of covert side-effects can be introduced which would prove surprising
to the casual developer when he or she uses some seemingly harmless
construct. (Interestingly, some of the newer features in Python could
have been introduced using macros, and perhaps EasyExtend already
demonstrates this.)

Ultimately, I think that the main point of contention is little to do
with macros or their absence from Python. Instead, it's more about
people coming to an agreement about form and behaviour guarantees for
Python programs - in other words, what you can expect when you open a
Python source file and start reading the code. It should be noted that
attitudes are generally negative towards careless redefinition of
fundamental or common concepts or mechanisms of the language, just as I
imagine it would be with Lisp, and one only needs to consider reactions
to various Ruby-related advocacy to see where the many in the Python
community supposedly draw the line at things like pervasive
monkey-patching of built-in classes. To bring that maligned natural
language analogy back into repute, I'd argue that Python and its
apparent restrictions act a lot like the specialised vocabularies and
familiar structures employed when presenting material in various
scientific disciplines: one could argue, upon reading a paper, that it
would have been a lot easier for the author to have structured the
paper differently and to have defined a one-off vocabulary, but issues
of convenient communication are highly likely to override such
considerations, especially in disciplines where conventions in
communication are already very strictly defined.

Paul

 

[=?ISO-8859-1?Q?Andr=E9_Thieme?=]

You could maybe give another example: how would one realize something
like (memoize function) in Python?

By spending thirty seconds googling:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/325205
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498110

If your needs are very simple, something as simple as this will do it:

def memoize(func):
def f(arg, _cache={}):
if _cache.has_key(arg):
return _cache[arg]
t = func(arg)
_cache[arg] = t
return t
return f

Yes, you are right, again this can be done with functional programming.
My examples also were not better than those of Kenny.
But anyway, in Lisp you can save some code. Not much in this situation.
Instead of function = memoize(function)
one could just say: memoize(function).

I don't even know what that means. Would you like to translate?

Also this won't be very hard to do in Python.
It just means: if you have a method with the name "name" and call it,
then this after-method will be called right after and do some side effect.

In Lisp it is built in. But with some effort it could be done in Python
too. The idea is, that small savings sum up, so macros do make sense.


André
--