"Martin v. Löwis"
martin at v.loewis.de
Sat Feb 18 17:22:01 CET 2006
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() and len() 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!
More information about the Python-Dev