Larry Hastings wrote:
>
> M.-A. Lemburg wrote:
>> Backporting PyCapsule is fine, but the changes you made to all
>> those PyCObject uses does not look backwards compatible.
>>
>> The C APIs exposed by the modules (e.g. the datetime module)
>> are used in lots of 3rd party extension modules and cha
M.-A. Lemburg, 26.03.2010 10:20:
Larry Hastings wrote:
3. Because CObject is unsafe, I want to deprecate it in 2.7, and if we
ever made a 2.8 I want to remove it completely.
Please remember that PyCObjects are not only used internally
in CPython, but also in other 3rd party modules to expose C
On Fri, Mar 26, 2010 at 10:19 AM, P.J. Eby wrote:
> At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote:
>>
>> But they're not -- they're *signals* for "your calculation has gone screwy
>> and the result you get is garbage", so to speak. You shouldn't even think of
>> a specific NAN as a piece of s
On Mar 25, 2010, at 7:19 PM, P.J. Eby wrote:
> At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote:
>> But they're not -- they're *signals* for "your calculation has gone screwy
>> and the result you get is garbage", so to speak. You shouldn't even think of
>> a specific NAN as a piece of specif
On 26 Mar 2010, at 18:40 , Casey Duncan wrote:
>
>
> On Mar 25, 2010, at 7:19 PM, P.J. Eby wrote:
>
>> At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote:
>>> But they're not -- they're *signals* for "your calculation has gone screwy
>>> and the result you get is garbage", so to speak. You shou
On Mar 26, 2010, at 3:16 PM, Xavier Morel wrote:
> On 26 Mar 2010, at 18:40 , Casey Duncan wrote:
>>
>>
>> On Mar 25, 2010, at 7:19 PM, P.J. Eby wrote:
>>
>>> At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote:
But they're not -- they're *signals* for "your calculation has gone screwy
>>
On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote:
>>
> How about raising an exception instead of creating nans in the first place,
> except maybe within specific contexts (so that the IEEE-754 minded can get
> their nans working as they currently do)?
-1
The numeric community uses NaNs as pl
On Fri, 26 Mar 2010 12:19:06 pm P.J. Eby wrote:
> At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote:
> >But they're not -- they're *signals* for "your calculation has gone
> >screwy and the result you get is garbage", so to speak. You
> >shouldn't even think of a specific NAN as a piece of specifi
Hello all,
A user has suggested an optional argument to
unittest.TestCase.assertAlmostEqual for specifying a maximum difference
between the expected and actual values, instead of using rounding.
This sounds great to me as the default implementation of
assertAlmostEqual has *never* been usefu
On Sat, Mar 27, 2010 at 8:16 AM, Raymond Hettinger
wrote:
>
> On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote:
>
> How about raising an exception instead of creating nans in the first place,
> except maybe within specific contexts (so that the IEEE-754 minded can get
> their nans working as they c
10 matches
Mail list logo
