Gregory Ewing <greg.ew...@canterbury.ac.nz>: > Marko Rauhamaa wrote: >> At any rate, it demonstrates how the idiom has its place in Python. > > Perhaps it does, but I think I'd still prefer it to be explicit.
Don't get me wrong. The method doesn't depend on tail call elimination. It couldn't because its sibling method has the same recursion depth without the possibility of tail call elimination. I was just showing an example of an iteration expressed idiomatically through a tail call. > The call in Marko's example is not actually a tail call as written. To > make it a tail call, a return would need to be added: > >> return child.setvalue(keyseq, value, offset + 1) Adding the return statement there would be bad because it would suggest to the maintainer of the code that the method has a meaningful return value, which it doesn't. > To someone reading the code, it's not obvious why the return is there. > It looks redundant, and is likely to get removed by someone who thinks > it's a mistake. Exactly. That's why I said also that it is unfortunate for Python to promise to return None implicitly. That stipulation of the language specification is against the de-facto semantics of procedures (your sentence above) and effectively prevents automatic tail call optimizations. > Using a dedicated keyword would make it clear that tail call behaviour > is being relied upon, and avoid looking like a spurious return. A dedicated keyword would indeed work as advertised. However, I'm not too keen on the idea. My position is: Python probably should have made tail call elimination a matter of course, but since it doesn't, oh well. Marko -- https://mail.python.org/mailman/listinfo/python-list
