Re: [Python-Dev] In-place operators
Martin v. Löwis wrote: Certainly, the doc string is wrong: isub(a, b) -- Same as a -= b. That's not quite the same - you would have to write a = isub(a, b) -- Same as a -= b. It seems a perfectly fine solution is simply to fix the docstring, exactly like that: a = isub(a, b) -- Same as a -= b. This both corrects the error when using isub with immutable types and educates user as to how a -= b actually works. ___ 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
Re: [Python-Dev] In-place operators
Raymond Hettinger wrote: > > [Martin v. Löwis] >> I would object to their removal, though, >> because it would hurt my sense of symmetry. > > I wasn't going to propose removal. If everyone had > agreed that the operator in-place functions were > problematic, I was going to suggest moving their > docs to a second page and documenting their limatations > (like we had done long ago with some of the builtins > that were no longer essential and had become obsolete). > That would leave the main page full of the operator > functions that have real utility. Splitting their documentation out to a separate page that explains their lack of usefulness when dealing with containers or immutable objects sounds like a great idea. As you say, due to their reliance on a separate assignment step they really are more limited than the other functions in the operator module. You didn't actually make that proposal in your original message though - you just asked if people thought it was a mistake to have added them to the operator module (which implied, at least to me, that you were going to suggest deprecating them). So +1 from me for changing the operator module docs as you suggest. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] In-place operators
Raymond Hettinger wrote: Does anyone think it was not a good idea to put in-place operations in the operator module? For some objects, they don't map() as well as their regular counterparts. Some in-place operations rely on the interpreter to take care of the actual assignment. I've not yet seen good use cases for operator.isub() for example. Given that Python has augmented assignment delimiters, but no 'in-place operators', and that the 'in-place operations' used to partially implemented them cannot be 'in-place' for immutables (and hence are actually aliases for the corresponding 'regular' operations, I agree that they are a bit odd and mostly useless. About the only use case I can think of is something like map(operator.iadd, mutable_seqs, items), where mutable_seqs includes instances of user classes than defind .__iadd__ but not .append ;-) On the other hand, the kitchen-sink policy saves debate. tjr ___ 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
Re: [Python-Dev] In-place operators
[Martin v. Löwis] I would object to their removal, though, because it would hurt my sense of symmetry. I wasn't going to propose removal. If everyone had agreed that the operator in-place functions were problematic, I was going to suggest moving their docs to a second page and documenting their limatations (like we had done long ago with some of the builtins that were no longer essential and had become obsolete). That would leave the main page full of the operator functions that have real utility. But, if we want them to remain first-class citizens, they are probably fine where they are. 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
Re: [Python-Dev] In-place operators
> I give up. My original question was whether anyone thought these > were a good idea. Look's like the answer is yes, Correct. > everyone is happy with > the functions and are glad they were added in 2.5. No. I don't really care - I don't use them, nor do I use anything else of the operator module (so I wouldn't miss it if it was removed entirely). I would object to their removal, though, because it would hurt my sense of symmetry. Regards, Martin P.S. If anything was to be removed, I would remove the in-place operations altogether; i.e. a+=b should always be a=a+b. Allowing them to be in-place complicates matters for little added value. ___ 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
Re: [Python-Dev] In-place operators
Maybe someone somewhere has some interesting use for these in-place operator function. I hope so. It could be important if you want apply it to mutable objects, i.e. where the assignment doesn't do anything. I give up. My original question was whether anyone thought these were a good idea. Look's like the answer is yes, everyone is happy with the functions and are glad they were added in 2.5. 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
Re: [Python-Dev] In-place operators
> I'm sure that consistency/completeness/safe_vs_sorry was the reason they > were added. But, if they aren't useful, they never should have been > (IMO). Why is that? [you are then giving a reason:] > It wastes the time of people who try to use them and then > find-out that they don't act as expected What people in particular? Certainly, the doc string is wrong: isub(a, b) -- Same as a -= b. That's not quite the same - you would have to write a = isub(a, b) -- Same as a -= b. (right?) However, anybody who understands what isub does already knows that property. I can't imagine users browsing through the operator module and thinking "hmm, what might that isub function do?". > or that you can't use them with containers s[k] += x etc.) Why not? s[k] = iadd(s[k], x) works fine, no? > Maybe someone somewhere has some interesting use for > these in-place operator function. I hope so. It could be important if you want apply it to mutable objects, i.e. where the assignment doesn't do anything. Regards, Martin ___ 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
Re: [Python-Dev] In-place operators
Raymond Hettinger rcn.com> writes: > > I'm sure that consistency/completeness/safe_vs_sorry > was the reason they were added. But, if they aren't useful, > they never should have been (IMO). It wastes the time of > people who try to use them and then find-out that they don't > act as expected (the assignment doesn't take place) >>> l = [] >>> operator.iadd(l, [5]) [5] >>> l [5] The operation /does/ occur in-place for mutable types. Yes, the semantics are non-obvious for non-mutable types, but that doesn't make it completely useless. ___ 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
Re: [Python-Dev] In-place operators
Right. Since Python doesn't have a notation like "operator +" for turning operators into functions, the operator module provides this functionality. Better safe than sorry. It doesn't really expose this functionality because some of the functionality is buried in ceval.c and is not exposed by operator.isub() for example. I don't see that it offers anything useful that can't be accomplished by calling a magic method directly. I'm sure that consistency/completeness/safe_vs_sorry was the reason they were added. But, if they aren't useful, they never should have been (IMO). It wastes the time of people who try to use them and then find-out that they don't act as expected (the assignment doesn't take place) or that you can't use them with containers s[k] += x etc.) Maybe someone somewhere has some interesting use for these in-place operator function. I hope so. 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
Re: [Python-Dev] In-place operators
On Tue, Mar 17, 2009 at 2:54 PM, Benjamin Peterson wrote: > 2009/3/17 Raymond Hettinger : >> Does anyone think it was not a good idea to put in-place operations in the >> operator module? For some objects, they don't map() as well as their >> regular counterparts. Some in-place operations rely on the interpreter to >> take care of the actual assignment. I've not yet seen good use cases for >> operator.isub() for example. > > I thought the point of the operator module (unlike most modules) was > to provide a comprehensive set of Python operators as functions for > consistency even if there usefulness was questionable. Right. Since Python doesn't have a notation like "operator +" for turning operators into functions, the operator module provides this functionality. Better safe than sorry. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] In-place operators
2009/3/17 Raymond Hettinger : > Does anyone think it was not a good idea to put in-place operations in the > operator module? For some objects, they don't map() as well as their > regular counterparts. Some in-place operations rely on the interpreter to > take care of the actual assignment. I've not yet seen good use cases for > operator.isub() for example. I thought the point of the operator module (unlike most modules) was to provide a comprehensive set of Python operators as functions for consistency even if there usefulness was questionable. -- Regards, Benjamin ___ 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
[Python-Dev] In-place operators
Does anyone think it was not a good idea to put in-place operations in the operator module? For some objects, they don't map() as well as their regular counterparts. Some in-place operations rely on the interpreter to take care of the actual assignment. I've not yet seen good use cases for operator.isub() for example. 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
