Thomas Wouters wrote: > > can anyone point to one other example where "call method on > > literal" is used in Python ? > > It doesn't matter.
it doesn't matter to you when the preferred way to do things don't look like Python code? > Either case is confusing, one way or another, as Tim has > already argued. this far, people have argued that it's confusing when methods have more than one argument (which is pure rubbish), and that people seem to recall that this was a common issue on comp.lang.python (it wasn't; especially not compared to the amount of "how do I join things" posts we're seeing these days and the amount of "eww. that's ugly" I hear when teaching Python...). you're also forgetting that I wrote the Unicode type, and was among the first persons to bring up the "how the heck do we handle join" issue. there's no frigging way anyone can convince me that the current design is the result of a careful design process; the whole argument went "we need an implementation hook anyway, so we might as well expose it". if you think that's a good design guideline, please explain why we shouldn't remove "len", "getattr", "int/float/complex/str/repr" (as converters), and a ton of other things from the language. after all, isn't obj.__getattr__(name) a lot less error-prone than getattr(obj, name) ? > Changing it would be a big mistake. nonsense. keeping a design mistake is a big mistake. fixing a design mistake is a good thing, and it'll make Python a nicer language. </F> _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
