Re: [Python-Dev] return type of __complex__

[Serhiy Storchaka]

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))
(1.5430806348152437-7.195794243779206e-17j)
>>> cmath.cos(C(1))
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __complex__ should return a complex object

Returned value can be computed and result can be float or complex 
depending on values. The author of the class with defined __complex__() 
may not even be aware that under certain circumstances he would get a float.


*Always* write "return complex(...)" is too redundant.


___
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] return type of __complex__

[Serhiy Storchaka]

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 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] return type of __complex__

[Serhiy Storchaka]

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 coerces its operands to floats.



___
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] return type of __complex__

[Steven D'Aprano]

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 (//) restricted to ints only,
and the existing one coerces its operands to floats.


That is incorrect. // works fine with non-ints.


py> 42.9//3.4
12.0



--
Steven
___
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] return type of __complex__

[Mark Dickinson]

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 convinced that the
complex constructor is wrong to accept a float return from
__complex__.  But it's not clear to me whether it's better to break
backwards compatibility by fixing that in 3.4, or to accept the
mistake and make cmath behave analogously.

> Also PyComplex_AsComplex() should perhaps enforce that.

It already does.  `complex_new` doesn't use `PyComplex_AsCComplex`.

-- 
Mark
___
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] return type of __complex__

[Antoine Pitrou]

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 
> > ValueError: negative number cannot be raised to a fractional power
> >
> > If you wanted a complex result, you can explicitly ask for one:
> >
> > py> (-100.0+0j)**0.5
> > (6.123031769111886e-16+10j)
> >
> >
> > I see that behaviour is changed in Python 3.
> 
> Python 2 (future directives aside) also required you to explicitly ask
> for floating point. That was also changed in Python 3. That doesn't
> mean that this is necessarily the right thing to do, but it does have
> precedent. The square root of a negative number is by nature a complex
> number.

In the set of complex numbers, it is. But in the set of float numbers,
a negative number has no square root. I think Steven may be worried
about the impact on people who don't know about complex numbers, which
is a reasonable concern.

I'm also not sure why we have several variants of the power operator:
**, built-in pow(), math.pow().

Regards

Antoine.


___
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] return type of __complex__

[Nick Coghlan]

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 mode: That numeric tower is wrong as it applies to Python -- we
> have some rational types that can represent some numbers that can't be
> represented by our complex and """real""" types.
>
> >>> int(float(10**100)) == 10**100
> False
>
> (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 numbers with rational real
> and imaginary parts" is not a memorable name for a type.))

Floats are not rational either, since they allow infinities and NaN as
values. Both float and Decimal are approximations to the Real number
set, as int and Fraction are approximations to the Integer and
Rational sets. In all cases, they cannot express the full scope of the
associated numeric concept, because they're limited by their physical
representations as bit patterns inside the computer (while that limit
is technically available memory for the unbounded representations, the
practical limit is lower than that if you want vaguely reasonable
running times for arbitrary arithmetic operations).

As far as the conversion operators go, I don't recall there being any
discussion one way or the other - the question simply never came up,
presumably because all code tested already returned complex objects
from __complex__.

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] return type of __complex__

[Nick Coghlan]

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 know the rationale math.pow() though - it may just stem from
the time when the math module was just a really thin wrapper around
the underlying C library's floating point math support.

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] return type of __complex__

[Steven D'Aprano]

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 to a fractional power

If you wanted a complex result, you can explicitly ask for one:

py>  (-100.0+0j)**0.5
(6.123031769111886e-16+10j)


I see that behaviour is changed in Python 3. Was this discussed before
being changed? I see a single sample docstring buried in PEP 3141 that:

"""a**b; should promote to float or complex when necessary."""

but I can't find any discussion of the consequences of this for the
majority of users who would be surprised by the unexpected appearance
of a "j" inside their numbers.


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

If an operation at one level of the tower produces a result in one of
the larger supersets, then *that's what it will do* rather than
throwing TypeError. int / int promoting to float is one example, as is
raising a negative number to a fractional power promoting to complex.

The general philosophy is described in
http://www.python.org/dev/peps/pep-3141/#implementing-the-arithmetic-operations


Yes, I've read that. But it seems to me that this change appears to have
been driven by type-purity (floats are Liskov-substituable for complex)
rather than practical considerations for people who may not know what
complex numbers are, or at best may have vague recollections of being
told about them in high school, and who now have to deal with the
unexpected appearance of complex numbers in calculations which previously
gave an exception.

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, just a silently
generating garbage results.



--
Steven
___
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] return type of __complex__

[Steven D'Aprano]

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 "", line 1, in
ValueError: negative number cannot be raised to a fractional power

If you wanted a complex result, you can explicitly ask for one:

py>  (-100.0+0j)**0.5
(6.123031769111886e-16+10j)


I see that behaviour is changed in Python 3.


Python 2 (future directives aside) also required you to explicitly ask
for floating point. That was also changed in Python 3. That doesn't
mean that this is necessarily the right thing to do, but it does have
precedent. The square root of a negative number is by nature a complex
number.


In the set of complex numbers, it is. But in the set of float numbers,
a negative number has no square root. I think Steven may be worried
about the impact on people who don't know about complex numbers, which
is a reasonable concern.


Precisely.



I'm also not sure why we have several variants of the power operator:
**, built-in pow(), math.pow().


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.2 20080704 (Red Hat 
4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam

import math
math.pow




And yet strangely there's never been a cmath.pow.



--
Steven
___
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] return type of __complex__

[Antoine Pitrou]

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.2 20080704 (Red Hat 
> 4.1.2-52)] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import math
> >>> math.pow
> 

You are being too optimistic:

>>> pow

>>> math.pow

>>> pow is math.pow
False


Regards

Antoine.


___
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] return type of __complex__

[Chris Angelico]

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 ~]$ python1.5
>> Python 1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 (Red Hat 
>> 4.1.2-52)] on linux2
>> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>> >>> import math
>> >>> math.pow
>> 
>
> You are being too optimistic:
>
 pow
> 
 math.pow
> 
 pow is math.pow
> False

The one in math doesn't take three args.

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit
(Intel)] on win32
>>> math.pow(1,2,3)
Traceback (most recent call last):
  File "", line 1, in 
math.pow(1,2,3)
TypeError: pow expected 2 arguments, got 3

I conducted a brief survey of a non-technical nature (that is to say,
I rambled to my brother and listened to what he said in response), and
he's of the opinion that many programmers would be surprised and
confused by the sudden appearance of complex numbers in programs that
weren't using them. On the flip side, it's kinda like a NaN - you
don't get an error immediately, but you'll either see it in your
output or get an exception later on.

His suggestion was that an expression unexpectedly returning a complex
should issue a warning. Warnings aren't really useful in Python as
most people have them off, but would there be any way that this sort
of thing could be caught by a linter? It'd probably require some
fairly deep code analysis to figure out that you're taking the square
root of something that could be negative, though.

ChrisA
___
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] return type of __complex__

[Stephen J. Turnbull]

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 type.
 > 
 > So the question is whether float is an "appropriate type" when
 > you're expecting a complex.

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, or they would have just written
"Returns a complex value."  Stability is more important than catering
to my taste (even if it happens to represent a majority in some sense).

___
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] accept the wheel PEPs 425, 426, 427

[Stephen J. Turnbull]

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.

___
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] accept the wheel PEPs 425, 426, 427

[Daniel Holth]

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
> intuition for that.

It's OK to limit the extensibility of this format. IIUC pypi usually
gets the metadata as a pre-parsed dict anyway, and the installer /
runtime does not need formatted fields at all (only parsing the name,
version, requirements to do dependency resolution).
___
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] return type of __complex__

[Mark Dickinson]

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 that it's not
at all evident that anyone thought 'float' was appropriate;  that it's
accepted may have just been a side-effect of the implementation.

-- 
Mark
___
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] Interest in seeing sh.py in the stdlib

[Georg Brandl]

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 on github
>> https://github.com/amoffat/sh for about 10 months and currently has about
>> 25k installs, according to pythonpackages.com.
>>
>> Andy Grover maintains the Fedora rpm for sh.py
>> http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=94247  and Nick
>> Moffit has submitted an older version of sh.py (which was called pbs) to be
>> included in Debian distros
>> http://pkgs.org/debian-wheezy/debian-main-i386/python-pbs_0.95-1_all.deb.html
>>
>> I'm interested in making sh.py more accessible to help bring Python forward
>> in the area of shell scripting, so I'm interested in seeing if sh would be
>> suitable for the standard library.  Is there any other interest in something
>> like this?
> 
> You should try the python-ideas list.

In addition, let me say upfront that while the library looks very nice at
a glance, its behavior is much too magical to be included as a standard
library IMO.

cheers,
Georg

___
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] return type of __complex__

[Guido van Rossum]

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 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 to a fractional power

 If you wanted a complex result, you can explicitly ask for one:

 py>  (-100.0+0j)**0.5
 (6.123031769111886e-16+10j)


 I see that behaviour is changed in Python 3.

>>>
>>> Python 2 (future directives aside) also required you to explicitly ask
>>> for floating point. That was also changed in Python 3. That doesn't
>>> mean that this is necessarily the right thing to do, but it does have
>>> precedent. The square root of a negative number is by nature a complex
>>> number.
>>>
>>
>> In the set of complex numbers, it is. But in the set of float numbers,
>> a negative number has no square root. I think Steven may be worried
>> about the impact on people who don't know about complex numbers, which
>> is a reasonable concern.
>>
>
> Precisely.
>
>
>  I'm also not sure why we have several variants of the power operator:
>> **, built-in pow(), math.pow().
>>
>
> 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.2 20080704 (Red Hat
> 4.1.2-52)] on linux2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>
>> import math
 math.pow

>>> 
>
>
> And yet strangely there's never been a cmath.pow.
>
>
>
> --
> Steven
> __**_
> 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/**
> guido%40python.org
>


-- 
--Guido van Rossum (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] cpython: Build the _sha3 module with VS 2008.

[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 VS 2010 I decided against this approach and built the extension as a
separate .pyd extension because the _sha3 module is rather large (> 200
kB). I think your change is going to break VS 2010.

What do the other think? Should the code by built-in by default?
___
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] return type of __complex__

[Terry Reedy]

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 wavering on this, too.  I'm reasonably convinced that the
complex constructor is wrong to accept a float return from
__complex__.  But it's not clear to me whether it's better to break
backwards compatibility by fixing that in 3.4, or to accept the
mistake and make cmath behave analogously.


I think we should fix it. A float return appears very rare, as well as 
wrong.



--
Terry Jan Reedy

___
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] return type of __complex__

[Terry Reedy]

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 complex() ...
  > Should return a value of the appropriate type.


I would take that as meaning complex or subclass thereof or whatever is 
consistent with float() and int().



  >
  > So the question is whether float is an "appropriate type" when
  > you're expecting a complex.

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, or they would have just written
"Returns a complex value."  Stability is more important than catering
to my taste (even if it happens to represent a majority in some sense).




--
Terry Jan Reedy

___
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] accept the wheel PEPs 425, 426, 427

[R. David Murray]

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 problems if
> > anybody later found a use for other formatted fields.  I have no
> > intuition for that.
> 
> It's OK to limit the extensibility of this format. IIUC pypi usually
> gets the metadata as a pre-parsed dict anyway, and the installer /
> runtime does not need formatted fields at all (only parsing the name,
> version, requirements to do dependency resolution).

Well, if you did want to maintain extensibility, you could go whole
hog and allow MIME types and Content-Type: mulitpart/mixed :)

--David
___
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] return type of __complex__

[Devin Jeanpierre]

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 numbers with rational real
>> and imaginary parts" is not a memorable name for a type.))
>
> Floats are not rational either, since they allow infinities and NaN as
> values. Both float and Decimal are approximations to the Real number
> set, as int and Fraction are approximations to the Integer and
> Rational sets.

You're missing a step here. Are you claiming that the real numbers
have infinities or NaN?

Why do floats approximate the reals, while Fraction approximates the
rationals? After all, for any real number, a Fraction instance can
become arbitrarily close to it (given sufficient memory). The same is
not true of a float, which can only get to a relative distance of
machine epsilon, and then only when the real number is close to zero.
It would seem as if Fractions approximate the reals and rationals, and
floats do not approximate anything at all (at least, not arbitrarily
closely*).

* I think "can be made arbitrarily close to the value in question" is
the usual meaning of "approximates" in mathematics, but I'm not sure
about numerical computing (maybe it just means "with sufficiently
small difference for values we care about"?)

> In all cases, they cannot express the full scope of the
> associated numeric concept, because they're limited by their physical
> representations as bit patterns inside the computer (while that limit
> is technically available memory for the unbounded representations, the
> practical limit is lower than that if you want vaguely reasonable
> running times for arbitrary arithmetic operations).

There is a deeper difference in how badly we can represent the
rationals versus the reals. For an arbitrary rational number, we can
represent it precisely on a computer with sufficiently many bytes of
memory. That is not true for real numbers: the vast majority of real
numbers cannot be represented precisely in any form on a computer, no
matter how large it is. And while there are irrational numbers we can
represent precisely on a computer, floats don't represent any of them;
they only represent a selection of rational numbers, and nan/inf/-inf.

> As far as the conversion operators go, I don't recall there being any
> discussion one way or the other - the question simply never came up,
> presumably because all code tested already returned complex objects
> from __complex__.

That's a fair objection to what I said. I guess the discussion is here/now.

-- Devin
___
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] cpython: Build the _sha3 module with VS 2008.

[Antoine Pitrou]

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 the _sha3 module with VS 2008.
> 
> For VS 2010 I decided against this approach and built the extension as a
> separate .pyd extension because the _sha3 module is rather large (> 200
> kB). I think your change is going to break VS 2010.

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.

Regards

Antoine.


___
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] [Python-checkins] cpython: Build the _sha3 module with VS 2008.

[Martin v. Löwis]

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 VS 2010 I decided against this approach and built the extension as a
separate .pyd extension because the _sha3 module is rather large (> 200
kB). I think your change is going to break VS 2010.

What do the other think? Should the code by built-in by default?


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 decision can be made based on size (e.g.);
if the module depends on extra libraries, it shouldn't be in
pythonxy.dll.

For VS 2008, I don't care - this set of project files isn't really
intended for production use, but rather for ongoing development.

In the long term, I wish we could use the platform implementations
of SHA-3 rather than shipping our own.

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] cpython: Build the _sha3 module with VS 2008.

[Christian Heimes]

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 instead:

http://hg.python.org/cpython/rev/c8217046e2cd

That fixes the issue with VS 2008. I don't have any older versions of
MSVC on my box so I can't fix the other projects.
___
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] cpython: Build the _sha3 module with VS 2008.

[Antoine Pitrou]

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 version.
> 
> I backed out your commit and committed a _sha3.vcproj file instead:
> 
> http://hg.python.org/cpython/rev/c8217046e2cd
> 
> That fixes the issue with VS 2008. I don't have any older versions of
> MSVC on my box so I can't fix the other projects.

Thank you :)

Antoine.
___
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] cpython: Build the _sha3 module with VS 2008.

[Christian Heimes]

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 decision can be made based on size (e.g.);
> if the module depends on extra libraries, it shouldn't be in
> pythonxy.dll.
> 
> For VS 2008, I don't care - this set of project files isn't really
> intended for production use, but rather for ongoing development.
> 
> In the long term, I wish we could use the platform implementations
> of SHA-3 rather than shipping our own.

Hello Martin,

Ultimately it's your decision. You are the expert and build master for
Windows releases. I've no hard feelings if you prefer to include the
code in the main dll. Just say so and I will change the module ASAP.

The sha3 module depends on the Keccak reference implementation. I guess
the loop unrolling and massive usage of macros in the optimized
implementation increases the size of the code considerable. I didn't
want to increase the main python.dll from 2.7 MB to almost 3 MB.

We may have to ship our own SHA-3 code for quite a while. OpenSSL hasn't
even began to include SHA-3. The bugs.python.org entry about Keccak is
still the number one hit of a Google search about "openssl keccak".

Christian
___
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] accept the wheel PEPs 425, 426, 427

[Nick Coghlan]

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
> intuition for that.

That level of extensibility mainly shows up with the extra metadata
files in the .dist-info directory (so it's part of the wheel and
installation database formats, but not a concern for the main metadata
file).

An in-memory metadata interchange format would need to deal with it,
but such a format can also use properly structured datatypes.

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] return type of __complex__

[Greg Ewing]

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, just a silently
generating garbage results.


Yeah. I don't think Inland Revenue would be very impressed if
I tried to tell them I had imaginary tax-to-pay, advantageous
though it might be for me.

--
Greg
___
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] return type of __complex__

[Greg Ewing]

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 ambiguous whether "appropriate"
means of the exact type corresponding to the name of the function,
or something substitutable for that type.

--
Greg
___
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] return type of __complex__

[Chris Angelico]

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 the number
>> gets fed to %f formatting, or worse, no error at all, just a silently
>> generating garbage results.
>
>
> Yeah. I don't think Inland Revenue would be very impressed if
> I tried to tell them I had imaginary tax-to-pay, advantageous
> though it might be for me.

Unless the IRS instructs you to submit the square root of your income,
I doubt that this will ever come up. Amusing though the notion be.

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?

ChrisA
___
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] return type of __complex__

[Steven D'Aprano]

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> math.asin(2)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: math domain error

(although the error message could be a bit nicer...)

so as far as I can tell, the only way you could accidentally get a 
complex number without expecting one is by exponentiation, either by ** 
or the builtin pow. This includes square roots. Exponentiation isn't as 
common as the basic four arithmetic operators, but it is hardly exotic.

Any time you have a non-integer power and a negative base, you will get 
a complex number. So there are two error conditions which used to give 
an exception but now promote to complex:

- taking the root (square root, cube root, etc.) of a number which 
  should be positive, but accidentally becomes negative (perhaps due to
  round-off error, you get a small -ve number instead of zero);

- the base may legitimately be negative, and the exponent is supposed
  to be a positive integer but accidentally because non-integral.

I suppose as someone who is rather fond of complex numbers, I should be 
pleased about this change, which raises the profile of complex and makes 
it closer to a "first class" numeric type. But my concern is that people 
who never dreamed that complex numbers even existed suddenly need to 
beware of them, and write LBYL code to avoid them, rather than relying 
on Python raising an exception.

In a nutshell, the semantics of ** have changed between 2.x and 3.x, and 
that's going to have consequences when porting code from 2 to 3. Perhaps 
2to3 needs to warn about the use of ** and pow?

[wishful thinking]
If we had floating point contexts, we could just tell people to stick 

import float
float.context.promote_to_complex = False

at the top of their module and they'd be fine.


-- 
Steven
___
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] return type of __complex__

[Stephen J. Turnbull]

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 or SSE, it's often convenient to
subtract the square of the mean from the sum of the squares.  With
ill-conditioned data (specifically, perfectly multicollinear series
that arise when you do a linear regression on an accounting identity)
I occasionally[1] see a negative variance in submitted output.  That
implies a complex standard deviation.

Unlike Inland Revenue or even the IRS, third-rate MBA students are
completely able to take complex results in stride.  That's the value
of a higher education! ;-)

Of course regressing an accounting identity is a (big) mistake anyway,
but the students are more likely to argue with a professor than with a
computer.

You might also see this in various applications in computational
geometry.

Footnotes: 
[1]  Every couple of years.

___
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