Game theorist here. wfdc via Python-ideas writes:
> Do you see why it's useful to have immutability? Sure, it's potentially hashable. But I can't recall ever finding that useful in working with matrix games (loosely speaking, I mean games with a finite set of players, each with a finite strategy space). I've used (subclasses of) tuple for strategy profiles, but I always wanted more additional attributes than just 'replace' (thus subclasses), and I call it "deviate" (usually) or "disturbance" (when computing perfect or proper equilibria; of course those implicate the mixed extension, which complicates thing, and also they involve changing all the non-interior strategies simultaneously). Really curious to hear enough about your use case to understand why adding this method to tuple is so much preferable to using a list (which is what I do when calculating best replies in an abstract matrix game, eg toy examples for introductory classes) or some class based on dict, list, or tuple (when the game is a model of some social phenomenon and I want to access various summaries of performance "at" a profile). > > This could cause confusion because str.replace() has a completely > > different API. > > We're talking about tuples here, not strings. You are, and you have every right to. I want to talk about immutable sequences, and that's fine, too. The point is that str and tuples are both immutable sequences, and both "replace at index" and "replace value" make sense for all sequences. Of course mutable sequences already have the usual indexing and slicing APIs for replacement, so this would be immutables only. BTW, bytes.replace has the same signature as str.replace. It's true that namedtuple has a replace method with a different signature, but that signature relates to namedtuple as a (general) *mapping*, not as a *sequence* (which, although it's a special case of mapping, is sufficiently important to have two builtin implementations). > Saying that a method's API differs for a completely different type, > especially when such a difference would be expected given the > difference in types, is not a valid objection. True. I wouldn't expect the replace method on ints to be the same as the replace method on tuples. I would expect the replace method on immutable sequences to be consistent across subtypes. I don't yet see a reason why "replace value" wouldn't be at least as useful "replace at index". And in fact "replace value" is plausible for list, as well, with that signature. Based on the precedent set by other immutable sequences, I'm firmly -1 on the name "replace" for "replace at". I'm -1 on adding it to tuple with any name, but I could be convinced otherwise based on systematic evidence that it's broadly useful, such as a survey of the stdlib. Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QDL76JVLFX7DALV6ZSPB5V2YCYQTK2HD/ Code of Conduct: http://python.org/psf/codeofconduct/
