Sure, and I don't know if anyone will ever want ipow() -- but I've never seen real code use the three-argument pow() either. The fact is that all the in-place modifying hooks return the result (which may or may not be self, and may or may not be mutated) so an in-place three-argument pow() would have to do the same. I would prefer keeping the similarity between __ipow__ and __pow__, although I don't care if that means keeping the always-unused third argument to __ipow__ (which isn't really in the way, after all) or adding a new hook for the three-argument pow(). On 2/14/07, "Martin v. Löwis" <martin at v.loewis.de> wrote: > > Thomas Wouters schrieb: > > > > The same way += et al. are in-place: it would ask 'x' to modify itself, > > if it can. If not, no harm done. (It would be called as 'x = ipow(x, n, > > 10)' of course, just like 'x += n' is really 'x = x.__iadd__(n)') > > I think this would violate the policy that a mutating function shouldn't > give the object being modified as the result - just as list.reverse > doesn't return the list, in addition to reversing it in-place. > > Regards, > Martin > > -- Thomas Wouters <thomas at python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20070214/0587b53b/attachment.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4