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
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
http://mail.python.
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 flo
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 th
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
h
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
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`
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/
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 w
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, Gr
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 n
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
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
S
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
e
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 m
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 inst
-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__
>>
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
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 par
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 lik
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
21 matches
Mail list logo
