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
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-De
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 (//) res
On Sun, Oct 21, 2012 at 6:26 AM, Greg Ewing 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, too. I'm reasonably conv
On Sun, 21 Oct 2012 13:38:48 +1100
Chris Angelico wrote:
> On Sun, Oct 21, 2012 at 12:53 PM, Steven D'Aprano wrote:
> > Python 2.x legitimately distinguished between floats and complex, e.g.:
> >
> > py> (-100.0)**0.5
> >
> > Traceback (most recent call last):
> > File "", line 1, in
> > Value
On Sun, Oct 21, 2012 at 3:06 PM, Devin Jeanpierre
wrote:
> On Sat, Oct 20, 2012 at 10:57 PM, Nick Coghlan 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 > Rational > Integral
>
> Pedant
On Sun, Oct 21, 2012 at 8:11 PM, Antoine Pitrou 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 % z")
I don't kn
On 21/10/12 13:57, Nick Coghlan wrote:
On Sun, Oct 21, 2012 at 11:53 AM, Steven D'Aprano wrote:
Python 2.x legitimately distinguished between floats and complex, e.g.:
py> (-100.0)**0.5
Traceback (most recent call last):
File "", line 1, in
ValueError: negative number cannot be raised t
On 21/10/12 21:11, Antoine Pitrou wrote:
On Sun, 21 Oct 2012 13:38:48 +1100
Chris Angelico wrote:
On Sun, Oct 21, 2012 at 12:53 PM, Steven D'Aprano 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, 21 Oct 2012 22:02:17 +1100
Steven D'Aprano 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, 09:09:18) [GCC 4.1
On Sun, Oct 21, 2012 at 10:08 PM, Antoine Pitrou wrote:
> On Sun, 21 Oct 2012 22:02:17 +1100
> Steven D'Aprano 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 ~
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 appropr
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.
___
Py
On Sun, Oct 21, 2012 at 8:27 AM, Stephen J. Turnbull 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. I have no
On Sun, Oct 21, 2012 at 1:23 PM, Stephen J. Turnbull 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 complicated enough th
On 10/20/2012 11:27 PM, Benjamin Peterson wrote:
> 2012/10/20 Andrew Moffat :
>> 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 has been maintained
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 Angelico wrote:
>>
>>> On Sun, Oct 21, 2012 at 12:53 PM, Steven D'Aprano
>>> wrote:
>>>
Python 2.x legiti
Am 21.10.2012 17:23, schrieb antoine.pitrou:
> http://hg.python.org/cpython/rev/ce9c9cbd1b11
> changeset: 79875:ce9c9cbd1b11
> user:Antoine Pitrou
> date:Sun Oct 21 17:21:04 2012 +0200
> summary:
> Build the _sha3 module with VS 2008.
For VS 2010 I decided against this approac
On 10/21/2012 5:45 AM, Mark Dickinson wrote:
On Sun, Oct 21, 2012 at 6:26 AM, Greg Ewing 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 wa
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 wrote:
> On Sun, Oct 21, 2012 at 8:27 AM, Stephen J. Turnbull
> 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 problem
I guess I was asking for this. (Sorry for OT conversation.)
On Sun, Oct 21, 2012 at 6:31 AM, Nick Coghlan 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 because "complex
On Sun, 21 Oct 2012 17:32:02 +0200
Christian Heimes wrote:
> Am 21.10.2012 17:23, schrieb antoine.pitrou:
> > http://hg.python.org/cpython/rev/ce9c9cbd1b11
> > changeset: 79875:ce9c9cbd1b11
> > user:Antoine Pitrou
> > date:Sun Oct 21 17:21:04 2012 +0200
> > summary:
> > Build
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
date:Sun Oct 21 17:21:04 2012 +0200
summary:
Build the _sha3 module with VS 2008.
For
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 ins
On Sun, 21 Oct 2012 21:31:02 +0200
Christian Heimes 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 another MSVC vers
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
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. I have no
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
On Mon, Oct 22, 2012 at 11:10 AM, Greg Ewing
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 somewhere distant when th
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>
Chris Angelico writes:
> 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?
Stats. Happens in naive student programs with naive student models.
Specifically, in computing variance
34 matches
Mail list logo
