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 a
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
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
[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 th
> 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 mod
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.
> 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 exp
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 expect
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 op
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 o
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'v
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 op
12 matches
Mail list logo
