On Sat, Mar 20, 2010 at 22:48, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Note that Antoine's point was that float("0.1") and
>> Decimal.from_float(0.1) should compare equal.
>
> That would mean that Decimal("0.1") != float("0.1"), which might be
> surprising to someone who didn't realise they w
Nick Coghlan wrote:
int -> Decimal -> Fraction -> float -> complex
I don't think it's a good idea to put Decimal below Fraction,
because Decimal has to be considered an implicitly inexact
type like float, and we don't want to coerce from an inexact
type to an exact one.
--
Greg
__
Michael Foord wrote:
Well, the documentation you pointed to specifies that __getattr__ will
be called if __getattribute__ raises an AttributeError, it just doesn't
specify that it is done by object.__getattribute__ (which it isn't).
If __getattribute__ raises an exception, it won't get a chan
Nick Coghlan wrote:
Note that Antoine's point was that float("0.1") and
Decimal.from_float(0.1) should compare equal.
That would mean that Decimal("0.1") != float("0.1"), which might be
surprising to someone who didn't realise they were mixing floats
and decimals.
--
Greg
Mark Dickinson wrote:
Except that float is fixed-width (typically 53 bits of precision),
while Decimal allows a user-specified, arbitrarily large, precision;
Yes, but it still has *some* fixed limit at any given
moment, so the result of an operation on Decimals always
has the potential to prod
On Mar 20, 2010, at 4:27 PM, Jeffrey Yasskin wrote:
>
> When designing it, I tried to include a notion of exact/inexact types,
> but we couldn't find anything practical to do with them, so we took
> them out.
The were also other reasons that they were taken out. The notion of
inexactness is a
On Mar 20, 2010, at 6:54 PM, Nick Coghlan wrote:
>
> I suggest a 'linearised' numeric tower that looks like:
>
> int -> Decimal -> Fraction -> float -> complex
Is that a typo? Shouldn't Decimal and float go between Fraction and complex?
The abstract numeric tower is:
Number Complex R
Michael Foord wrote:
> Well, the documentation you pointed to specifies that __getattr__ will
> be called if __getattribute__ raises an AttributeError, it just doesn't
> specify that it is done by object.__getattribute__ (which it isn't).
And as for why not: because __getattribute__ implementation
Guido van Rossum wrote:
> I think we should seriously reconsider allowing mixed arithmetic
> involving Decimal, not just mixed comparisons.
I'm glad I'm not the only one that started wondering that. I
wasn't quite game enough to actually suggest it though :)
> There is one choice which I'm not s
On 20/03/2010 12:00, Pascal Chambon wrote:
Michael Foord a écrit :
On 19/03/2010 18:58, Pascal Chambon wrote:
Hello
I've already crossed a bunch of articles detailing python's
attribute lookup semantic (__dict__, descriptors, order of base
class traversing...), but I have never seen, so far
Glenn Linderman wrote:
> Thanks, though for the nice chart from an internals guy, you confirmed
> all that I thought I knew about how this presently works, from PEP and
> manual reading, a bit of experimentation, and the discussions here.
I'll confess to a bit of interpreter prompt experimentation
Greg Ewing wrote:
> Antoine Pitrou wrote:
>
>> We forbid comparisons when there is a real danger or ambiguity, such
>> as unicode
>> vs. bytes. There is no such danger or ambiguity when comparing a
>> decimal with a
>> float.
>
> So do you think that float("0.1") and Decimal("0.1") should be
> eq
On Sat, Mar 20, 2010 at 17:20, Greg Ewing wrote:
> There are two ways in which that linear tower is overly
> simplistic:
>
> * It conflates the notions of exactness and width. They're
> really orthogonal concepts, and to reflect this you would
> need two parallel towers, with exact and inexact ver
On Sat, Mar 20, 2010 at 4:46 PM, Mark Dickinson wrote:
> On Sat, Mar 20, 2010 at 11:20 PM, Greg Ewing
> wrote:
>> * Decimal and float really belong side-by-side in the
>> tower, rather than one above the other. Neither of them is
>> inherently any more precise or exact than the other.
>
> Except
On Sat, Mar 20, 2010 at 11:20 PM, Greg Ewing
wrote:
> * Decimal and float really belong side-by-side in the
> tower, rather than one above the other. Neither of them is
> inherently any more precise or exact than the other.
Except that float is fixed-width (typically 53 bits of precision),
while
On Sat, Mar 20, 2010 at 4:20 PM, Greg Ewing wrote:
> Adam Olsen wrote:
>
>> For a little context, we have this numeric tower:
>>
>> int -> Fraction -> float -> complex
>>
>> Decimal is more precise, and pays a performance cost for it. It also
>> seems odd to stick it between float and complex (no
Adam Olsen wrote:
For a little context, we have this numeric tower:
int -> Fraction -> float -> complex
Decimal is more precise, and pays a performance cost for it. It also
seems odd to stick it between float and complex (nobody's planning a
ComplexDecimal, right?) That suggests it should go
Glenn Linderman wrote:
One can argue that either way, that it is completely different, or
completely the same.
An important difference is that there is no intermediate type
that can be compared with both ints and strings.
Another relevant difference is that numbers are just one of
many possib
On Sat, Mar 6, 2010 at 12:43, Brett Cannon wrote:
> I see two possible fixes for this. One is to not silence DeprecationWarning
> if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new
> subclass of DeprecationWarning called IntegerDivisionWarning and have that
> added to the wa
On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum wrote:
> I propose to reduce all hashes to the hash of a normalized fraction,
> which we can define as a combination of the hashes for the numerator
> and the denominator. Then all we have to do is figure fairly efficient
> ways to convert floats a
On Sat, Mar 20, 2010 at 4:16 AM, Mark Dickinson wrote:
> True. The reason I was concentrating on the hashes is that it's not
> immediately obvious that it's even *possible* to find a decent hash
> function that's efficient to compute and gives equal results for
> numerically equal inputs (regardl
> Darn. I bet I broke it when I added the 'languishing' status. I even
> thought about that at the time but didn't follow up on it. I'll see
> if I can figure out where the script lives.
My guess is that the Debian upgrade killed it.
Regards,
Martin
__
On Sat, Mar 20, 2010 at 4:58 AM, Mark Dickinson wrote:
> On Sat, Mar 20, 2010 at 11:41 AM, Paul Moore wrote:
>> On 20 March 2010 04:20, Nick Coghlan wrote:
>>> In the case of floats and Decimals, there's no ambiguity here that
>>> creates any temptation to guess - to determine a true/false resul
On Sat, 20 Mar 2010 11:11:17 -0600, Brian Curtin wrote:
> On Sat, Mar 20, 2010 at 11:02, Terry Reedy wrote:
> > I did not receive the usual Friday tracker post on issues opened and closed
> > during the past week.
> > Did anyone else?
> > I am reading via gmane.
> >
> > Terry Jan Reedy
> >
>
> I
On Sat, Mar 20, 2010 at 10:05 AM, Mark Dickinson wrote:
> On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen wrote:
>> On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson wrote:
>>> What external modules are there that rely on existing hash behaviour?
>>
>> I'm only aware of gmpy and SAGE.
>>
>>> And
On Sat, Mar 20, 2010 at 11:02, Terry Reedy wrote:
> I did not receive the usual Friday tracker post on issues opened and closed
> during the past week.
> Did anyone else?
> I am reading via gmane.
>
> Terry Jan Reedy
>
I actually haven't seen that mail in a few weeks (subscribed to the list via
On Sat, Mar 20, 2010 at 3:17 PM, Case Vanhorsen wrote:
> On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson wrote:
>> What external modules are there that rely on existing hash behaviour?
>
> I'm only aware of gmpy and SAGE.
>
>> And exactly what behaviour do they rely on?
>
> Instead of calculatin
On Sat, Mar 20, 2010 at 09:11, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>>
>> On Fri, Mar 19, 2010 at 9:50 PM, Guido van Rossum python.org>
> wrote:
>> > There is one choice which I'm not sure about. Should a mixed
>> > float/Decimal operation return a float or a Decimal?
>>
>>
I did not receive the usual Friday tracker post on issues opened and
closed during the past week.
Did anyone else?
I am reading via gmane.
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Sean Reifschneider tummy.com> writes:
>
> I would propose changing the Python syslog() call to do the C equivalent of:
>
>if openlog_hasnt_been_called_before_now:
> if sys.argv[0]:
> syslog.openlog(os.path.basename(sys.argv[0]))
>
> In other words, if there's a script name an
On 3/20/2010 7:06 AM, Mark Dickinson wrote:
Will this change the result of hashing a long? I know that both gmpy
and SAGE use their own hash implementations for performance reasons. I
understand that CPython's hash function is an implementation detail,
but there are external modules that rely on
On Fri, 19 Mar 2010 23:20:52 -0400, Alexander Belopolsky
wrote:
> I will not go into details here beyond referring to
> http://bugs.python.org/issue8154, but if you follow the link, you'll
> see that there was not a consensus on how the issue should be
> addressed and even whether or not it was a
On Sat, Mar 20, 2010 at 4:06 AM, Mark Dickinson wrote:
> On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen wrote:
>> On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson wrote:
>>> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
Making hashes of int,
float, Decimal *and* Fraction all
Mark Dickinson gmail.com> writes:
>
> On Fri, Mar 19, 2010 at 9:50 PM, Guido van Rossum python.org>
wrote:
> > There is one choice which I'm not sure about. Should a mixed
> > float/Decimal operation return a float or a Decimal?
>
> I'll just say that it's much easier to return a Decimal if you
Michael Foord a écrit :
On 19/03/2010 18:58, Pascal Chambon wrote:
Hello
I've already crossed a bunch of articles detailing python's attribute
lookup semantic (__dict__, descriptors, order of base class
traversing...), but I have never seen, so far, an explanation of
WHICH method did waht,
On Sat, Mar 20, 2010 at 11:41 AM, Paul Moore wrote:
> On 20 March 2010 04:20, Nick Coghlan wrote:
>> In the case of floats and Decimals, there's no ambiguity here that
>> creates any temptation to guess - to determine a true/false result for a
>> comparison, floats can be converted explicitly to
On 20 March 2010 04:20, Nick Coghlan wrote:
> In the case of floats and Decimals, there's no ambiguity here that
> creates any temptation to guess - to determine a true/false result for a
> comparison, floats can be converted explicitly to Decimals without any
> loss of accuracy. For Fractions, th
On Sat, Mar 20, 2010 at 12:10 AM, Greg Ewing
wrote:
> Nick Coghlan wrote:
>>
>> Mark Dickinson wrote:
>
>> It seems to me that given the existing conflation of numeric equivalence
>> and containment testing, going the whole hog and fixing the set
>> membership problem for all of our rational types
On Fri, Mar 19, 2010 at 1:17 PM, Case Vanhorsen wrote:
> On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson wrote:
>> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson wrote:
>>> Making hashes of int,
>>> float, Decimal *and* Fraction all compatible with one another,
>>> efficient for ints and floats
39 matches
Mail list logo
