Chris Angelico wrote:
Python 2 (future directives aside) also required you to explicitly ask
for floating point. That was also changed in Python 3.
The solution adopted was different, though: use different
operators for int and float division. This means you can't
accidentally end up with a
Devin Jeanpierre wrote:
(Complex
numbers get a free pass because complex numbers with rational real
and imaginary parts is not a memorable name for a type.)
Complexional?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
On Sun, Oct 21, 2012 at 5:11 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Devin Jeanpierre wrote:
(Complex
numbers get a free pass because complex numbers with rational real
and imaginary parts is not a memorable name for a type.)
Complexional?
Oh is there not one maiden here
Whose
On 21.10.12 03:15, Antoine Pitrou wrote:
The redundancy sounds like a non-issue to me, since you can implement
__float__ instead:
class C:
... def __init__(self, v):
... self.v = v
... def __complex__(self):
... return self.v**0.5
...
import cmath
cmath.cos(C(-1))
On 21.10.12 05:40, Chris Angelico wrote:
Anyway. Py3 says that int/int -- float is
acceptable, so float**float -- complex is equally plausible.
The difference is that int/int -- always float, but float**float --
float or complex.
___
Python-Dev
On 21.10.12 09:05, Greg Ewing wrote:
The equivalent solution here would be to add a new operator
for complex exponentiation that coerces its operands to
complex, and restrict the existing one to floats only.
In case of division a new operator (//) restricted to ints only, and the
existing one
On 21/10/12 19:47, Serhiy Storchaka wrote:
On 21.10.12 09:05, Greg Ewing wrote:
The equivalent solution here would be to add a new operator
for complex exponentiation that coerces its operands to
complex, and restrict the existing one to floats only.
In case of division a new operator (//)
On Sun, Oct 21, 2012 at 6:26 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
I think I've changed my mind on this, since it was pointed
out that if you're going to return a float instead of a
complex, you should really be implementing __float__, not
__complex__.
Yes, I'm wavering on this,
On Sun, 21 Oct 2012 13:38:48 +1100
Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 21, 2012 at 12:53 PM, Steven D'Aprano st...@pearwood.info wrote:
Python 2.x legitimately distinguished between floats and complex, e.g.:
py (-100.0)**0.5
Traceback (most recent call last):
File
On Sun, Oct 21, 2012 at 3:06 PM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
On Sat, Oct 20, 2012 at 10:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
PEP 3141 is indeed the driver for these changes, and it's based on the
Python 3.x numeric tower consisting of strict supersets: Complex
Real
On Sun, Oct 21, 2012 at 8:11 PM, Antoine Pitrou solip...@pitrou.net wrote:
I'm also not sure why we have several variants of the power operator:
**, built-in pow(), math.pow().
Built-in pow() is provided for efficient modular arithmetic (via the
3-argument pow(x, y, z) form that means x ** y %
On 21/10/12 21:11, Antoine Pitrou wrote:
On Sun, 21 Oct 2012 13:38:48 +1100
Chris Angelicoros...@gmail.com wrote:
On Sun, Oct 21, 2012 at 12:53 PM, Steven D'Apranost...@pearwood.info wrote:
Python 2.x legitimately distinguished between floats and complex, e.g.:
py (-100.0)**0.5
Traceback
On Sun, 21 Oct 2012 22:02:17 +1100
Steven D'Aprano st...@pearwood.info wrote:
In Python 3.3, math.pow is the builtin pow. Presumably for backwards
compatibility reasons when they were different? If so, it was a LONG
time ago:
[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012,
On Sun, Oct 21, 2012 at 10:08 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 21 Oct 2012 22:02:17 +1100
Steven D'Aprano st...@pearwood.info wrote:
In Python 3.3, math.pow is the builtin pow. Presumably for backwards
compatibility reasons when they were different? If so, it was a LONG
Greg Ewing writes:
Stephen J. Turnbull wrote:
It's a design bug, yes. The question is, does it conform to
documented behavior?
The 2.7 docs say this about __complex__:
Called to implement the built-in function complex() ...
Should return a value of the appropriate
Daniel Holth writes:
Another solution comes to mind. Put the description in the payload.
That would work for me, but it would cause extensibility problems if
anybody later found a use for other formatted fields. I have no
intuition for that.
___
On Sun, Oct 21, 2012 at 8:27 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Daniel Holth writes:
Another solution comes to mind. Put the description in the payload.
That would work for me, but it would cause extensibility problems if
anybody later found a use for other formatted fields.
On Sun, Oct 21, 2012 at 1:23 PM, Stephen J. Turnbull step...@xemacs.org wrote:
I probably not say that, but even so my personal taste would be to fix
the docs to describe the current behavior in 2.7. Evidently somebody
thought float was appropriate
The implementation of complex_new is
On 10/20/2012 11:27 PM, Benjamin Peterson wrote:
2012/10/20 Andrew Moffat andrew.robert.mof...@gmail.com:
Hi,
I'm the author of sh.py, a subprocess module rewrite for Linux and OSX. It
serves as a powerful and intuitive interface to launching subprocesses
http://amoffat.github.com/sh/. It
Math.pow() predates ** by many releases.
On Sunday, October 21, 2012, Steven D'Aprano wrote:
On 21/10/12 21:11, Antoine Pitrou wrote:
On Sun, 21 Oct 2012 13:38:48 +1100
Chris Angelicoros...@gmail.com wrote:
On Sun, Oct 21, 2012 at 12:53 PM, Steven D'Apranost...@pearwood.info
wrote:
Am 21.10.2012 17:23, schrieb antoine.pitrou:
http://hg.python.org/cpython/rev/ce9c9cbd1b11
changeset: 79875:ce9c9cbd1b11
user:Antoine Pitrou solip...@pitrou.net
date:Sun Oct 21 17:21:04 2012 +0200
summary:
Build the _sha3 module with VS 2008.
For VS 2010 I decided
On 10/21/2012 5:45 AM, Mark Dickinson wrote:
On Sun, Oct 21, 2012 at 6:26 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
I think I've changed my mind on this, since it was pointed
out that if you're going to return a float instead of a
complex, you should really be implementing __float__,
On 10/21/2012 8:23 AM, Stephen J. Turnbull wrote:
Greg Ewing writes:
Stephen J. Turnbull wrote:
It's a design bug, yes. The question is, does it conform to
documented behavior?
The 2.7 docs say this about __complex__:
Called to implement the built-in function
On Sun, 21 Oct 2012 09:14:03 -0400, Daniel Holth dho...@gmail.com wrote:
On Sun, Oct 21, 2012 at 8:27 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
Daniel Holth writes:
Another solution comes to mind. Put the description in the payload.
That would work for me, but it would cause
I guess I was asking for this. (Sorry for OT conversation.)
On Sun, Oct 21, 2012 at 6:31 AM, Nick Coghlan ncogh...@gmail.com wrote:
(Also, floats aren't reals and no computer can store any number that
is not rational and we should stop pretending they can. (Complex
numbers get a free pass
On Sun, 21 Oct 2012 17:32:02 +0200
Christian Heimes christ...@python.org wrote:
Am 21.10.2012 17:23, schrieb antoine.pitrou:
http://hg.python.org/cpython/rev/ce9c9cbd1b11
changeset: 79875:ce9c9cbd1b11
user:Antoine Pitrou solip...@pitrou.net
date:Sun Oct 21 17:21:04 2012
Am 21.10.12 17:32, schrieb Christian Heimes:
Am 21.10.2012 17:23, schrieb antoine.pitrou:
http://hg.python.org/cpython/rev/ce9c9cbd1b11
changeset: 79875:ce9c9cbd1b11
user:Antoine Pitrou solip...@pitrou.net
date:Sun Oct 21 17:21:04 2012 +0200
summary:
Build the _sha3 module
Am 21.10.2012 20:53, schrieb Antoine Pitrou:
I don't know. If it breaks VS 2010 then it should be reverted. On the
other hand I'd like to continue building Python under Windows without
needing to install yet another MSVC version.
I backed out your commit and committed a _sha3.vcproj file
On Sun, 21 Oct 2012 21:31:02 +0200
Christian Heimes christ...@python.org wrote:
Am 21.10.2012 20:53, schrieb Antoine Pitrou:
I don't know. If it breaks VS 2010 then it should be reverted. On the
other hand I'd like to continue building Python under Windows without
needing to install yet
Am 21.10.2012 21:27, schrieb Martin v. Löwis:
It's a packaging and maintenance issue. If it is in pythonxy.dll, the
project file becomes easier to maintain. That's why I was always opposed
to splitting up the existing pythonxy.dll into many project files.
OTOH, when adding a module, a
On Sun, Oct 21, 2012 at 10:27 PM, Stephen J. Turnbull
step...@xemacs.org wrote:
Daniel Holth writes:
Another solution comes to mind. Put the description in the payload.
That would work for me, but it would cause extensibility problems if
anybody later found a use for other formatted
Steven D'Aprano wrote:
When you're dealing with numbers that represent real quantities, getting
a complex result is nearly always an error condition. Better to get an
exception at the point that occurs, than somewhere distant when the number
gets fed to %f formatting, or worse, no error at all,
Stephen J. Turnbull wrote:
Evidently somebody
thought float was appropriate, or they would have just written
Returns a complex value.
It's not quite as simple as that, because that paragraph in the
docs is actually shared between the descriptions of __int__,
__float__ and __complex__. So it's
On Mon, Oct 22, 2012 at 11:10 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Steven D'Aprano wrote:
When you're dealing with numbers that represent real quantities, getting
a complex result is nearly always an error condition. Better to get an
exception at the point that occurs, than
On Mon, Oct 22, 2012 at 02:25:45PM +1100, Chris Angelico wrote:
There really aren't that many situations where a program will be
completely oblivious of complex/imaginary numbers and be able to
encounter them... are there?
Fortunately the math module does not promote float to complex:
py
35 matches
Mail list logo
