Re: [Python-Dev] Improved evaluator added to ast module

2012-10-20 Thread Andrea Griffini 
On Thu, Oct 18, 2012 at 5:41 PM, Georg Brandl  wrote:
> On 10/18/2012 03:16 PM, Daniel Holth wrote:
>> On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip  wrote:
>>> Daniel Holth  gmail.com> writes:
>>>
 How does this compare to the markerlib approach? In markerlib you just
 make sure all the AST nodes are in a set of allowed nodes, currently
 (Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop), and then
 use the normal eval(). Is one way more secure / fast / flexible than
 the other?
>>>
>>> I don't think performance is an issue, and the markerlib approach seems just
>>> as reasonable as the one I've taken, except that it calls eval(), whereas my
>>> approach doesn't. It boils down to what should be allowed in expressions, 
>>> and
>>> what shouldn't be.

I'm not sure if this is pertinent to the safe eval discussion, but
currently it's possible to make python crash with a segfault even by
just *parsing* an expression.

See http://bugs.python.org/issue5765

Andrea
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Mark Dickinson 
On Fri, Oct 19, 2012 at 3:13 PM, Nick Coghlan  wrote:
> Given the way complex numbers interact with floats generally,
> returning a complex number with no imaginary component as a floating
> point value seems legitimate and the checks in cmath overly strict.
> Otherwise you would get redundancy like:
>
> def __complex__(self):
> return complex(value)
>
> or
>
> def __complex__(self):
> return value + 0j

I've opened bugs.python.org/issue16290 to track this.

-- 
Mark
___
Python-Dev mailing list
[email protected]
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

2012-10-20 Thread Daniel Holth 
The troublesome Description: parses fine -- as long as there is
anything but a \r\n - for example "\r\n " - on successive blank lines.
This tends to happen already.

Another solution comes to mind. Put the description in the payload.
The description can have any form, and the installer can stop parsing
at the first linesep pair because it only inspects Name, Version, and
requirements. A little bit of a pain because you might have to also
allow the description in the headers or rewrite it on install.


Metadata-Version: 1.3
Name: package
Version: 0.13.0
Summary: A package.
Classifier: Development Status :: 3 - Alpha
Classifier: Intended Audience :: Developers
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 2.7
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.3


Wheel
=

A built-package format for Python.

A wheel is a ZIP-format archive with a specially formatted filename
and the .whl extension. It is designed to contain all the files for a
PEP 376 compatible install in a way that is very close to the on-disk
format. Many packages will be properly installed with only the "Unpack"
step (simply extracting the file onto sys.path), and the unpacked archive
preserves enough information to "Spread" (copy data and scripts to their
final locations) at any later time.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improved evaluator added to ast module

2012-10-20 Thread Georg Brandl 
On 10/20/2012 10:24 AM, Andrea Griffini wrote:
> On Thu, Oct 18, 2012 at 5:41 PM, Georg Brandl  wrote:
>> On 10/18/2012 03:16 PM, Daniel Holth wrote:
>>> On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip  
>>> wrote:
 Daniel Holth  gmail.com> writes:

> How does this compare to the markerlib approach? In markerlib you just
> make sure all the AST nodes are in a set of allowed nodes, currently
> (Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop), and then
> use the normal eval(). Is one way more secure / fast / flexible than
> the other?

 I don't think performance is an issue, and the markerlib approach seems 
 just
 as reasonable as the one I've taken, except that it calls eval(), whereas 
 my
 approach doesn't. It boils down to what should be allowed in expressions, 
 and
 what shouldn't be.
> 
> I'm not sure if this is pertinent to the safe eval discussion, but
> currently it's possible to make python crash with a segfault even by
> just *parsing* an expression.
> 
> See http://bugs.python.org/issue5765

There's a big difference between being able to pass anything to an eval()
invocation, and having to exploit a segfault due to a stack overflow.

Even if your eval() argument overflows the stack, it's still much safer
than if you pass '__import__("os").unlink(...)' :)

Georg

___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/19/2012 07:35 PM, Greg Ewing wrote:
> Antonio Cuni wrote:
>> Traceback (most recent call last): File "", line 1, in
>>  TypeError: __complex__ should return a complex object
>> 
>> i.e., the complex constructor does not check that __complex__
>> returns an actual complex, while the cmath functions do.
> 
> Looks to me like cmath is being excessively finicky here. Why
> shouldn't a float be usable in *any* context expecting a complex?

Exactly:  float is perfectly Liskov-substituable for complex;  only
applications which do explicit type sniffing can tell the difference,
which makes the sniffing bogus.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCC+1wACgkQ+gerLs4ltQ7S1QCfUjvUsmMiHuW8DDXue0HPzvXE
Qv4Anissl8zNnx8KZyJQfcDxWlddTXGA
=6KUH
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Interest in seeing sh.py in the stdlib

2012-10-20 Thread 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?

Thanks
Andrew Moffat
___
Python-Dev mailing list
[email protected]
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

2012-10-20 Thread Benjamin Peterson 
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.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Guido van Rossum 
On Sat, Oct 20, 2012 at 12:28 PM, Tres Seaver  wrote:
> Exactly:  float is perfectly Liskov-substituable for complex;  only
> applications which do explicit type sniffing can tell the difference,
> which makes the sniffing bogus.

You don't have to do explicit sniffing. You could also be catching
exceptions, e.g. ordering floats works, but ordering complex raises
TypeError.

All in all I'm still in favor of treating this as a new feature. It
would otherwise encourage people writing code "for Python 2.7" that
would actually break on older versions of 2.7. Yes, I'm aware that
every bugfix release makes *some* code work that was broken before.
But this is still different. "API X now supports argument type Y"
smells like a new feature to me, no matter what you substitute for X
and Y.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Steven D'Aprano 

On 20/10/12 01:13, Nick Coghlan wrote:

On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cuni  wrote:

Is that the real intended behavior?


Given the way complex numbers interact with floats generally,
returning a complex number with no imaginary component as a floating
point value seems legitimate



Surely the intention is for __complex__ to return a complex number? That
is, that it is desirable to have the invariant:

isinstance(x.__complex__(), complex)

?

We expect that __int__ returns an int, and raise an exception if it
doesn't, even in the case that the value returned is numerically integral:

py> class X:
... def __int__(self):
... return 2.0
...
py> x = X()
py> int(x)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __int__ returned non-int (type float)


Conceptually, I see returning a float when you expect a complex as
equally dubious as returning an integral float when you expect an int.
I think there is something dirty about a __complex__ that returns a
non-complex. Why would you deliberately do such a thing? If a class
does so, that's surely indicative of a bug, so the earlier it gets
caught, the better.




and the checks in cmath overly strict.

Otherwise you would get redundancy like:

 def __complex__(self):
 return complex(value)
or

 def __complex__(self):
 return value + 0j



For the record, I think Nick is referring to the fact that the complex
constructor will fall back on __float__ if __complex__ does not exist,
adding 0j to x.__float__.

I don't see this as a problem. So what if people write redundant code?
It still works. And when they learn better, they can write better code.



--
Steven
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Antoine Pitrou 
On Sat, 20 Oct 2012 00:13:51 +1000
Nick Coghlan  wrote:
> On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cuni  wrote:
> > Is that the real intended behavior?
> 
> Given the way complex numbers interact with floats generally,
> returning a complex number with no imaginary component as a floating
> point value seems legitimate and the checks in cmath overly strict.
> Otherwise you would get redundancy like:
> 
> def __complex__(self):
> return complex(value)
> 
> or
> 
> def __complex__(self):
> return value + 0j

The redundancy sounds like a non-issue to me, since you can implement
__float__ instead:

>>> class C:
... def __float__(self): return 5.0
... 
>>> complex(C())
(5+0j)
>>> cmath.cos(C())
(0.28366218546322625+0j)

Regards

Antoine.


-- 
Software development and contracting: http://pro.pitrou.net


___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Steven D'Aprano 

On 21/10/12 06:28, Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/19/2012 07:35 PM, Greg Ewing wrote:

Antonio Cuni wrote:

Traceback (most recent call last): File "", line 1, in
  TypeError: __complex__ should return a complex object

i.e., the complex constructor does not check that __complex__
returns an actual complex, while the cmath functions do.


Looks to me like cmath is being excessively finicky here. Why
shouldn't a float be usable in *any* context expecting a complex?


Exactly:  float is perfectly Liskov-substituable for complex;  only
applications which do explicit type sniffing can tell the difference,
which makes the sniffing bogus.



But float is not *numerically* substitutable for complex, which is why
type-sniffing is not bogus at all. If you have an application which
assumes numeric quantities represent real values, then you need to
distinguish between real-valued and complex-valued arithmetic, and
treating floats as implicitly complex is the wrong thing to do.

Since most applications are based on real-values, implicit promotion to
complex is in my opinion an anti-feature.

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.

Nor is there any hint in the docs for pow and ** that they will promote
floats to complex:

http://docs.python.org/dev/library/functions.html#pow

http://docs.python.org/dev/library/stdtypes.html#numeric-types-int-float-complex



--
Steven
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Guido van Rossum 
You can check the .image attribute, which exists on floats too (and ints).

--Guido van Rossum (sent from Android phone)
On Oct 20, 2012 6:54 PM, "Steven D'Aprano"  wrote:

> On 21/10/12 06:28, Tres Seaver wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/19/2012 07:35 PM, Greg Ewing wrote:
>>
>>> Antonio Cuni wrote:
>>>
 Traceback (most recent call last): File "", line 1, in
   TypeError: __complex__ should return a complex object

 i.e., the complex constructor does not check that __complex__
 returns an actual complex, while the cmath functions do.

>>>
>>> Looks to me like cmath is being excessively finicky here. Why
>>> shouldn't a float be usable in *any* context expecting a complex?
>>>
>>
>> Exactly:  float is perfectly Liskov-substituable for complex;  only
>> applications which do explicit type sniffing can tell the difference,
>> which makes the sniffing bogus.
>>
>
>
> But float is not *numerically* substitutable for complex, which is why
> type-sniffing is not bogus at all. If you have an application which
> assumes numeric quantities represent real values, then you need to
> distinguish between real-valued and complex-valued arithmetic, and
> treating floats as implicitly complex is the wrong thing to do.
>
> Since most applications are based on real-values, implicit promotion to
> complex is in my opinion an anti-feature.
>
> 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.
>
> Nor is there any hint in the docs for pow and ** that they will promote
> floats to complex:
>
> http://docs.python.org/dev/**library/functions.html#pow
>
> http://docs.python.org/dev/**library/stdtypes.html#numeric-**
> types-int-float-complex
>
>
>
> --
> Steven
> __**_
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/**mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> guido%40python.org
>
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Chris Angelico 
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.

ChrisA
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Chris Angelico 
On Sun, Oct 21, 2012 at 1:38 PM, Chris Angelico  wrote:
> Python 2 (future directives aside) also required you to explicitly ask
> for floating point. That was also changed in Python 3.

Er, should have said that I was referring to division here...
incomplete information. Anyway. Py3 says that int/int --> float is
acceptable, so float**float --> complex is equally plausible.

ChrisA
___
Python-Dev mailing list
[email protected]
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

2012-10-20 Thread Daniel Holth 
I'm really happy with moving the troublesome Description: field to the
payload. Email Policy() is useful too.

http://hg.python.org/peps/rev/74868fe8ba17

Metadata 1.3 is a ...

+format with no maximum line length, followed by a blank line and an
+arbitrary payload.  It is parseable by the ``email`` module with an
+appropriate ``email.policy.Policy()``.

description is deprecated...

+Since Metadata 1.3 the recommended place for the description is in the
+payload section of the document, after the last header.  The description
+needs no special formatting when included in the payload.

includes a handy...

# Metadata 1.3 demo
from email.generator import Generator
from email import header
from email.parser import Parser
from email.policy import Compat32
from email.utils import _has_surrogates

class MetadataPolicy(Compat32):
max_line_length = 0
continuation_whitespace = '\t'

def _sanitize_header(self, name, value):
if not isinstance(value, str):
return value
if _has_surrogates(value):
raise NotImplementedError()
else:
return value

def _fold(self, name, value, sanitize):
body = ((self.linesep+self.continuation_whitespace)
.join(value.splitlines()))
return ''.join((name, ': ', body, self.linesep))

if __name__ == "__main__":
import sys
import textwrap

pkg_info = """\
Metadata-Version: 1.3
Name: package
Version: 0.1.0
Summary: A package.
Description: Description
===


A description of the package.

"""

m = Parser(policy=MetadataPolicy()).parsestr(pkg_info)

m['License'] = 'GPL'
description = m['Description']
description_lines = description.splitlines()
m.set_payload(description_lines[0]
+ '\n'
+ textwrap.dedent('\n'.join(description_lines[1:]))
+ '\n')
del m['Description']

# Correct if sys.stdout.encoding == 'UTF-8':
Generator(sys.stdout, maxheaderlen=0).flatten(m)
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Nick Coghlan 
On Sun, Oct 21, 2012 at 11:53 AM, Steven D'Aprano  wrote:
> On 21/10/12 06:28, Tres Seaver wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/19/2012 07:35 PM, Greg Ewing wrote:
>>>
>>> Antonio Cuni wrote:

 Traceback (most recent call last): File "", line 1, in
   TypeError: __complex__ should return a complex object

 i.e., the complex constructor does not check that __complex__
 returns an actual complex, while the cmath functions do.
>>>
>>>
>>> Looks to me like cmath is being excessively finicky here. Why
>>> shouldn't a float be usable in *any* context expecting a complex?
>>
>>
>> Exactly:  float is perfectly Liskov-substituable for complex;  only
>> applications which do explicit type sniffing can tell the difference,
>> which makes the sniffing bogus.
>
>
>
> But float is not *numerically* substitutable for complex, which is why
> type-sniffing is not bogus at all. If you have an application which
> assumes numeric quantities represent real values, then you need to
> distinguish between real-valued and complex-valued arithmetic, and
> treating floats as implicitly complex is the wrong thing to do.
>
> Since most applications are based on real-values, implicit promotion to
> complex is in my opinion an anti-feature.
>
> 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

It sounds like cmath (or, more specifically, the "D" conversion code)
missed out on the associated updates).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Devin Jeanpierre 
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.))

*Pedant mode deactivated*

> 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
>
> It sounds like cmath (or, more specifically, the "D" conversion code)
> missed out on the associated updates).

No, no no. The return type of conversion methods has nothing to do
with the interoperability of types in arithmetic. If it did there
would've been a systematic purging of old behaviors in these
conversion functions, and there evidently hasn't been because float(),
cmath, and math all behave "wrong", and those are collectively fairly
hard to miss.

Since float(), cmath, and math all behave the same, I'd assert that
it's complex() (and int()) that is weird and unusual.

>>> class A:
... def __complex__(self):
... return 1
... def __float__(self):
... return 1
...
>>> complex(A())
(1+0j)
>>> float(A())
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __float__ returned non-float (type int)
>>> cmath.sqrt(A())
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __complex__ should return a complex object
>>> math.sqrt(A())
Traceback (most recent call last):
  File "", line 1, in 
TypeError: nb_float should return float object
>>>

-- Devin
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Greg Ewing 

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__.

So I think it's fine to require __complex__ to return a
complex, and the docs should perhaps be clarified on that
point.

Also PyComplex_AsComplex() should perhaps enforce that.

--
Greg
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Greg Ewing 

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 float when an int is what you
intended.

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.

--
Greg
___
Python-Dev mailing list
[email protected]
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__

2012-10-20 Thread Greg Ewing 

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
[email protected]
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__

2012-10-20 Thread Chris Angelico 
On Sun, Oct 21, 2012 at 5:11 PM, Greg Ewing  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 homely face and bad complexion
Have caused all hope to disappear
Of ever winning man's affection?"

I'm hoping your name was a joke, because it's rather unwieldy. But
really, computers are no different from anything else; they have to
represent numbers somehow. That pretty much means it has to be
rational, as it's awkward trying to do arithmetic with surds floating
around everywhere.

ChrisA
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com