On Wednesday, July 15, 2015 at 4:54:51 PM UTC+5:30, Marko Rauhamaa wrote: > Ned Batchelder: > > > On Wednesday, July 15, 2015 at 6:56:10 AM UTC-4, Marko Rauhamaa wrote: > >> Ned Batchelder : > >> > I don't understand this, can you explain more? Are you saying that the > >> > Python specification shouldn't specify what x becomes?: > >> > > >> > def who_knows(): > >> > pass > >> > > >> > x = who_knows() > >> > >> Yes, that's what I'm saying. The implementation would be free to assign > >> any value whatsoever to x. > > > > I don't understand why that is helpful for TCE? Can you explain? How does > > specifying None make "smooth TCE" difficult? > > As Chris already pointed out, tail procedure calls can't be eliminated > otherwise. An example: > > def some_func(): > do_stuff() > more_stuff() > > Now, for Python to replace the call to "more_stuff()" with a simple > jump, there can't be an implicit "return None" following it. Instead, > "some_func()" must be allowed to return whatever "more_stuff()" returns. > > You could require the programmer to write: > > def some_func(): > do_stuff() > return more_stuff() > > but that's not good style. In fact, it is not good style to write code > that omits "return None" when None needs to be returned. IOW, the > unspecifiedness of procedure return values is already the unwritten > assumption in good Python code. An interesting insight. For sometime now I am seeing that C's void-return's are a mess-up of Pascal procedures. And python's None-returns are a mess-up of C's void-return: http://blog.languager.org/2015/06/functional-programming-moving-target.html
This was mostly from pedagogic data of observing student confusions Now you are giving a new take on why None-return could be a language-design anti-pattern. So thanks for that. -- https://mail.python.org/mailman/listinfo/python-list
