On Fri, Oct 19, 2012 at 10:13 AM, 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 val
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 i
Daniel Holth writes:
> Tweaked at http://hg.python.org/peps/rev/75474fb879d3
I'll take a look later; I have some other commitments now I should do
first.
> On Thu, Oct 18, 2012 at 10:55 PM, Stephen J. Turnbull
> wrote:
> > Executive summary:
> >
> > You probably should include a full ABNF
Maciej Fijalkowski writes:
> Nick just said it's a bug that cmath type checks are too strict.
It's a design bug, yes. The question is, does it conform to
documented behavior? If so, it's not an implementation bug that
should be fixed in 2.7.
___
Pyth
On Sat, Oct 20, 2012 at 2:23 AM, Maciej Fijalkowski wrote:
> On Fri, Oct 19, 2012 at 5:56 PM, Benjamin Peterson
> wrote:
>> It's a new feature. Also, it's possible that someone is relying on it
>> throwing for non-complex values.
>>
>
> Nick just said it's a bug that cmath type checks are too st
On Oct 19, 2012, at 08:07 PM, Daniel Holth wrote:
>The email parser is significantly more permissive than the RFC.
Don't forget that the email package now supports policies (experimentally), so
it may be possible to tweak a policy setting to fit the bill. Anyway, it
might at least be interesting
Tweaked at http://hg.python.org/peps/rev/75474fb879d3
On Thu, Oct 18, 2012 at 10:55 PM, Stephen J. Turnbull
wrote:
> Executive summary:
>
> You probably should include a full ABNF grammar
The legacy PKG-INFO does not have email parse-ability. How about an
example parser implementation instea
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
On 10/19/2012 06:44 PM, Tres Seaver wrote:
> On 10/19/2012 11:56 AM, Benjamin Peterson wrote:
>> 2012/10/19 Tres Seaver :
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> On 10/19/2012 11:26 AM, Benjamin Peterson wrote:
2012/10/19 Antonio Cuni :
> indeed, you are right. So I suppo
On Fri, Oct 19, 2012 at 12:48 PM, Benjamin Peterson wrote:
> 2012/10/19 Tres Seaver :
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 10/19/2012 11:56 AM, Benjamin Peterson wrote:
> >> 2012/10/19 Tres Seaver :
> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>>
> >>> On 10/1
2012/10/19 Tres Seaver :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/19/2012 11:56 AM, Benjamin Peterson wrote:
>> 2012/10/19 Tres Seaver :
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> On 10/19/2012 11:26 AM, Benjamin Peterson wrote:
2012/10/19 Antonio Cuni :
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/19/2012 11:56 AM, Benjamin Peterson wrote:
> 2012/10/19 Tres Seaver :
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>> On 10/19/2012 11:26 AM, Benjamin Peterson wrote:
>>> 2012/10/19 Antonio Cuni :
indeed, you are right. So I suppose
On Fri, Oct 19, 2012 at 5:31 PM, Christian Heimes wrote:
> In order to fix the bug the code in PyComplex_AsCComplex() must be
> altered to support float as return type from __complex__(). That's a
> major change.
Agreed that this doesn't seem appropriate for bugfix releases.
We might also want t
Am 19.10.2012 18:23, schrieb Maciej Fijalkowski:
> Nick just said it's a bug that cmath type checks are too strict.
I'm not so sure about that. cmath just uses PyArg_ParseTuple with "D"
which itself relies upon PyComplex_AsCComplex().
D (complex) [Py_complex]
Convert a Python complex number t
On Fri, Oct 19, 2012 at 4:26 PM, Benjamin Peterson wrote:
> 2012/10/19 Antonio Cuni :
>> indeed, you are right. So I suppose that in pypy we could just relax the
>> check
>> in cmath and be happy. Is there any chance that this will be changed in 2.7
>> and/or 3.x?
>
> Certainly 3.x, but not 2.7.
On Fri, Oct 19, 2012 at 5:56 PM, Benjamin Peterson wrote:
> 2012/10/19 Tres Seaver :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 10/19/2012 11:26 AM, Benjamin Peterson wrote:
>>> 2012/10/19 Antonio Cuni :
indeed, you are right. So I suppose that in pypy we could just relax
>>
ACTIVITY SUMMARY (2012-10-12 - 2012-10-19)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3815 (+26)
closed 24249 (+48)
total 28064 (+74)
Open issues wit
2012/10/19 Tres Seaver :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/19/2012 11:26 AM, Benjamin Peterson wrote:
>> 2012/10/19 Antonio Cuni :
>>> indeed, you are right. So I suppose that in pypy we could just relax
>>> the check in cmath and be happy. Is there any chance that this wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/19/2012 11:26 AM, Benjamin Peterson wrote:
> 2012/10/19 Antonio Cuni :
>> indeed, you are right. So I suppose that in pypy we could just relax
>> the check in cmath and be happy. Is there any chance that this will
>> be changed in 2.7 and/or 3.x?
2012/10/19 Antonio Cuni :
> indeed, you are right. So I suppose that in pypy we could just relax the check
> in cmath and be happy. Is there any chance that this will be changed in 2.7
> and/or 3.x?
Certainly 3.x, but not 2.7.
--
Regards,
Benjamin
__
On 10/19/2012 04:13 PM, 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 l
On Fri, Oct 19, 2012 at 10:20 AM, Barry Warsaw wrote:
> On Oct 18, 2012, at 09:23 PM, Daniel Holth wrote:
>
>>The email module provides an ordered multidict interface to the data.
>>The first tag wins (if you improperly define Name: twice for example),
>>but the order of everything is preserved. W
On Sat, Oct 20, 2012 at 12:14 AM, Barry Warsaw wrote:
> On Oct 19, 2012, at 09:33 PM, Nick Coghlan wrote:
>
>>At the moment, with the "3.4" used throughout the examples in both
>>PEPs, it's a little confusing w.r.t the actual 3.4 release PEP. I
>>could live with "Deferred" instead of "Rejected", b
On Fri, Oct 19, 2012 at 4:13 PM, 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 valu
On Oct 18, 2012, at 09:23 PM, Daniel Holth wrote:
>The email module provides an ordered multidict interface to the data.
>The first tag wins (if you improperly define Name: twice for example),
>but the order of everything is preserved. We just don't need it,
>except that it might be surprising to
On Oct 19, 2012, at 09:33 PM, Nick Coghlan wrote:
>At the moment, with the "3.4" used throughout the examples in both
>PEPs, it's a little confusing w.r.t the actual 3.4 release PEP. I
>could live with "Deferred" instead of "Rejected", but one or the other
>should happen.
I no longer have much in
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.
Otherw
On Fri, Oct 19, 2012 at 11:36 PM, Serhiy Storchaka wrote:
> Why not just
>
> return (name + os.extsep + "py",
>
> name + os.extsep + "pyc",
> name + os.extsep + "pyo",
> name + os.extsep + "pyw",
> name + "$py.class")
No good reason - I copied t
Hi,
while fixing pypy to pass CPython 3.2 tests, I found what I think it's a
inconsistency in how CPython (both 2.7 and 3.2) handles __complex__:
>>> class Obj:
... def __complex__(self):
... return 2.0
...
>>> obj = Obj()
>>> complex(obj)
(2+0j)
>>>
>>> import cmath
>>> cmath.acos(ob
On Fri, Oct 19, 2012 at 8:36 AM, Victor Stinner wrote:
> 2012/10/19 Benjamin Peterson :
> > It would be interesting to see how common it is for strings which have
> > their hash computed to be compared.
>
> I implemented a quick hack. When running "./python -m test test_os":
> Python calls PyUnico
On 19.10.12 14:58, nick.coghlan wrote:
http://hg.python.org/cpython/rev/321414874b26
changeset: 79827:321414874b26
branch: 2.7
parent: 79814:2f0770cc6d3f
user:Nick Coghlan
date:Fri Oct 19 21:58:18 2012 +1000
summary:
Issue #6074: Restore the long-broken support for
On 19 October 2012 11:02, Duncan Booth
wrote:
> Hrvoje Niksic wrote:
>
>> On 10/19/2012 03:22 AM, Benjamin Peterson wrote:
>>> It would be interesting to see how common it is for strings which have
>>> their hash computed to be compared.
>>
>> Since all identifier-like strings mentioned in Python
2012/10/19 Duncan Booth :
> Hrvoje Niksic wrote:
>
>> On 10/19/2012 03:22 AM, Benjamin Peterson wrote:
>>> It would be interesting to see how common it is for strings which have
>>> their hash computed to be compared.
>>
>> Since all identifier-like strings mentioned in Python are interned, and
>>
2012/10/19 Benjamin Peterson :
> It would be interesting to see how common it is for strings which have
> their hash computed to be compared.
I implemented a quick hack. When running "./python -m test test_os":
Python calls PyUnicode_RichCompare() 15206 times with Py_EQ or Py_NE
operator. In 41.4%
On Fri, Oct 19, 2012 at 9:01 PM, Larry Hastings wrote:
> FWIW I don't think those peps should be rejected simply because I didn't
> follow either for the 3.4 release schedule. I think they should both have
> their day in the court of public opinion. (Of course, maybe that day has
> already passe
On 10/18/2012 08:02 PM, Nick Coghlan wrote:
With the 3.4 release PEP published using a traditional schedule,
perhaps MvL would care to do the honours as BDFL-Delegate in rejecting
the two "faster release cycle for the standard library" PEPs?
(I know I asked to hold off on that when MvL last brou
Hrvoje Niksic wrote:
> On 10/19/2012 03:22 AM, Benjamin Peterson wrote:
>> It would be interesting to see how common it is for strings which have
>> their hash computed to be compared.
>
> Since all identifier-like strings mentioned in Python are interned, and
> therefore have had their hash co
On 10/19/2012 03:22 AM, Benjamin Peterson wrote:
It would be interesting to see how common it is for strings which have
their hash computed to be compared.
Since all identifier-like strings mentioned in Python are interned, and
therefore have had their hash computed, I would imagine comparing
38 matches
Mail list logo
