Michael P. Soulier wrote: > > which, based on the law of design based on random sampling of c.l.python, > > indicates that the current situation is not optimal. > > I for one found the move to put join() as a string method _very_ > unintiutive, and rather arbitrary. Lets just be different for the sake > of being different. > > It makes far more sense to put the method on the data that you are > acting upon. If you're joining a list, then join() should be a list > method.
the problem is that sequences are abstract interfaces in Python, and join() doesn't only work on sequences, it also works on anything that can be iterated over. if you move join to the list type, you'll narrow down the interface for functions using join from "pass me something that supports iteration" to "pass me a list or a subtype thereof". (but some days, I wonder if we shouldn't just nuke the entire instance- based dispatch and replace it with something derived from PJE's im- plementation of the Chambers/Chen global dispatch machinery, so we can provide global join methods for anything that implements either __iter__ or __getitem__) </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
