> > Even if an example or two is found, it is worth complicating the API. > > Keep in mind the difficulties that plague str.split() -- that is what > > happens when a function grows beyond a single, clear, unified, > > cohesive > > concept. > > I am not aware of these difficulties, any pointers?
Yes. From memory, write-down what you think str.split() does. Then look at the docs and see how much you got wrong and how much you missed. A thorough answer would cover empty string behaviors, the return type, whether None is allowed, whether a keyword argument is acceptable, and the effects of using a unicode or UserString argument. For extra credit, write down the length invariant and determine whether a string.join() invariant would always hold. The str.split() API has led to countless doc revisions, invalid error reports, newsgroup discussions, and questions on the tutor list. We ought to keep it unchanged for Py3.0 just to serve as a warning to future generations ;-) > From an API pow, I do not think it neccessarily complicates it Please stop smoking crack before posting to python-dev ;-) Try updating the doc string, library reference entry, and the test suite. Be sure to specify that the proposed arguments are non-commutative and whether general iterables are allowed. Then report back that there was no change in complexity. >, but > rather generalizes it in a way that may not be very usable :) > I can understand that it would probably not be worth the effort > though... Hmm, that suggests another design principle, "If a proposer lacks faith in his or her own proposal, it is doomed." Raymond _______________________________________________ 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
