On 7 November 2012 22:16, Joshua Landau <joshua.landau...@gmail.com> wrote: > On 7 November 2012 14:00, Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: >> On 7 November 2012 13:39, Joshua Landau <joshua.landau...@gmail.com> >> wrote: >> > On 7 November 2012 11:11, Oscar Benjamin <oscar.j.benja...@gmail.com> >> > wrote: >> >> A more modest addition for the limited case described in this thread >> >> could >> >> be to use exponentiation: >> >> >> >> >>> [0] ** (2, 3) >> >> [[0, 0, 0], [0, 0, 0]] >> >> Exponentiation is expected to be asymmetric and is currently unused so >> there is no ambiguity. The problem is if someone has already >> subclassed list and added an exponentiation method. > > How is that a problem? They just wont get the functionality.
This is absolutely contrived but: Library A defines a subclass of list that adds an exponentiation operator thinking that it's okay to still use these objects as lists. Library B has an API that expects a list and tries to use the list copy-exponentiation on its input. A user passes a list type object from library A into library B and hopefully gets an error but possibly gets a subtle bug that is hard to track down. It doesn't sound plausible to me but at least in principle there is a backward compatibility problem. > That said, losing: > [0] * (2, 3) == [0] * [2, 3] > would mean losing duck-typing in general. *Thus*, I fully agree with your > choice of exponentiation. Also there's no reason why tuples couldn't have the same exponentiation operator (although for them it would be no different from repeated multiplication). Oscar -- http://mail.python.org/mailman/listinfo/python-list
