On 11/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 11/25/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > Personally, I stand by my assessment that they can make metaclasses > > look straightforward -- but that is partly because metaclasses have > > had their roughest edges worn off already. (For example, they no > > longer require compiling a C class so odd that the pattern gets named > > after someone.) If GF explanations start to come from several > > different people, the same process should eventually simplify them. > > If that happened quickly enough, it would change the tradeoffs. > > Did you read my blog post where I give my own interpretation and > implementation? > > http://www.artima.com/weblogs/viewpost.jsp?thread=155514
Yes, and also the comments. If overloaded functions were proposed as an optional 3rd party module (a possibility you did mention), they would be interesting. When they are proposed as a fundamental part of the language itself, it is crucial that there be a quick, easy explanation available as soon as people need to work with them. For metaclasses, people don't need to work with them for quite a while. For something like print or len ... they need it sooner. (And 3rd party registration means that someone else's misunderstanding can cause bugs in your code.) I felt that there was still too much confusion for something that is proposed as a fundamental building block. I expect that the confusion would get worse once you have to start debugging multiple 3rd-party overloads. The "TypeError: hex() argument can't be converted to hex" is a hint at the problems, but I expect them to be worse when the chosen function is a match -- just not the one you expected. -jJ _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
