Unary plus operator and __pos__

[Carlos Ribeiro]

I was checking the Prolog recipe in the Cookbook:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/303057

It's a clever implementation that explores some aspects of Python that
I wasn't aware of. One of them is the unary plus operator, that calls
the __pos__ method. It's something that can be highly useful in my own
experiments with the use of classes as a tool for generic declarative
descriptions of objects -- UI forms, reports, webpages, etc.

Now I'm curious about the operator itself. Why is the unary plus
operator associated with the __pos__ magic method? I' can't see a
relation here, and I could not find much info (although I haven't
really looked very hard

Anyone knows why is it so?

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Erik Max Francis]

Now I'm curious about the operator itself. Why is the unary plus
operator associated with the __pos__ magic method? I' can't see a
relation here, and I could not find much info (although I haven't
really looked very hard

Anyone knows why is it so?

Unary plus is __pos__ for positive, unary minus is __neg__ for negative.

The unary plus operator, I'm sure, is a holdover from C. Since the
unary plus operator is a no-op for normal numeric values, I would be
hesitant to use it to mean something else; I'm a firm believer in
careful use of operator overloading, prefering to do so hopefully only
when the meaning is apparent from conventional operator usage. Since
unary + is a no-op, I don't think it would be a great idea to use it to
mean something vastly different, like "add a fact to the database." But
to each his own.

 

[Gerrit]

Unary plus is __pos__ for positive, unary minus is __neg__ for negative.

The unary plus operator, I'm sure, is a holdover from C. Since the
unary plus operator is a no-op for normal numeric values, I would be
hesitant to use it to mean something else;

The Decimal class does:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/local/lib/python2.4/decimal.py", line 863, in __pos__
ans = self._check_nans(context=context)
File "/usr/local/lib/python2.4/decimal.py", line 619, in _check_nans
1, self)
File "/usr/local/lib/python2.4/decimal.py", line 2243, in _raise_error
raise error, explanation
decimal.InvalidOperation: sNaN

yours,
Gerrit.

--
Weather in Twenthe, Netherlands 28/09 08:55:
15.0°C mist overcast wind 4.0 m/s SW (57 m above NAP)
--
In the councils of government, we must guard against the acquisition of
unwarranted influence, whether sought or unsought, by the
military-industrial complex. The potential for the disastrous rise of
misplaced power exists and will persist.
-Dwight David Eisenhower, January 17, 1961

 

[Erik Max Francis]

The Decimal class does:

Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/local/lib/python2.4/decimal.py", line 863, in __pos__
ans = self._check_nans(context=context)
File "/usr/local/lib/python2.4/decimal.py", line 619, in _check_nans
1, self)
File "/usr/local/lib/python2.4/decimal.py", line 2243, in _raise_error
raise error, explanation
decimal.InvalidOperation: sNaN

I don't see how that's at all a useful feature. Besides, one add-on
module as a counterexample doesn't exactly invalidate the point, which
was a personal opinion on a design goal, anyway.