Michael Hudson wrote: > There's one extremely significant example where the *value* of > something impacts on the type of something else: functions. The types > of everything involved in str([1]) and len([1]) are the same but the > results are different. This shows up in PyPy's type annotation; most > of the time we just track types indeed, but when something is called > we need to have a pretty good idea of the potential values, too. > > Relavent to the point at hand? No. Apologies for wasting your time > :)
Actually, I think it is relevant. I never thought about it this way, but now that you mention it, you are right. This demonstrates that the string argument to .encode is actually a function name, atleast the way it is implemented now. So .encode("uu") and .encode("rot13") are *two* different methods, instead of being a single method. This brings me back to my original point: "rot13" should be a function, not a parameter to some function. In essence, .encode reimplements apply(), with the added feature of not having to pass the function itself, but just its name. Maybe this design results from a really deep understanding of Namespaces are one honking great idea -- let's do more of those! Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com