On Aug 18, 2:40 am, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Jasper wrote: > > Uggg! /That's/ an intuitive side-effect/wart. :-/ > > it's done that way on purpose, of course, because evaluating a full > closure for each default argument at every call would greatly hurt > performance (and lead to another set of surprises, of course). > > please don't label things that you don't understand and haven't spent > any time reflecting over as bugs or warts; that's disrespectful to the > designers and probably not good for your blood pressure. > > </F>
I understand it's done that way on purpose, and that there are tradeoffs involved, but frankly your /guess/ that I don't understand is wrong. Having used Python for some 15 years, I'm hardly a neophyte -- it's pure serendipity that this hasn't bitten me before. I can see the elegance from a language design perspective, the speed advantage, etc. Nonetheless, it's an unintuitive wart, hurting Python's clarity -- as evidence I'll point out all the warnings that need to be sprinkled through the various docs. And no, the alternative /does not/ have an equivalent set of surprises -- it's not like Python is unique in having default arguments. Frankly, if I wanted speed, I wouldn't be using python, and if I wanted clever tricks, I'd use Perl. Surprise caching as a side-effect is /very/ Perl-like. -Jasper -- http://mail.python.org/mailman/listinfo/python-list
