On Fri, May 20, 2005, Raymond Hettinger wrote:
>
> k.) The biggest client of all these methods is the Decimal module
> itself. Throughout the implementation, the code calls the Decimal
> constructor to create intermediate values. Every one of those calls
> would need to be changed to specify a co
[Tim]
> I'm sorry, but if you mentally reduced everything I've written about
> this to "the sole argument", rational discussion has become impossible
> here.
Forgive me one melodramatic email.
I've laid out my reasoning and understand yours.
Crossing light sabers with one such as yourself is of
> It looks like if you pass in a context, the Decimal constructor still
> ignores that context:
>
> >>> import decimal as d
> >>> d.getcontext().prec = 4
> >>>
d.Decimal("1.234567890123456789012345678901234567890123456789",
> d.getcontext())
> Decimal("1.234567890123456789012345678901234567890
[Guido]
> > You know that, but Raymond seems confused. From one of his posts
(point
> (k)):
[Raymond]
> > "Throughout the implementation, the code calls the Decimal
> > constructor to create intermediate values. Every one of those calls
> > would need to be changed to specify a context."
[Facun
Michael Chermside wrote:
> Frankly, I have no idea WHAT purpose is served by passing a context
> to the decimal constructor... I didn't even realize it was allowed!
As Tim pointed out, it's solely to control whether or not ConversionSyntax
errors are exceptions or not:
Py> decimal.Decimal("a")
T
[Michael Chermside]
> Frankly, I have no idea WHAT purpose is served by passing a context
> to the decimal constructor... I didn't even realize it was allowed!
Quoth the docs for the Decimal constructor:
"""
The context precision does not affect how many digits are stored. That
is determined excl
On 5/20/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Python's Decimal constructor accepts a context argument, but the only
> > use made of it is to possibly signal a ConversionSyntax condition.
>
> You know that, but Raymond seems confused. From one of his posts (point (k)):
>
> "Through
> [Guido]
> > It looks like if you pass in a context, the Decimal constructor
> > still ignores that context:
> >
> > >>> import decimal as d
> > >>> d.getcontext().prec = 4
> > >>> d.Decimal("1.234567890123456789012345678901234567890123456789",
> > d.getcontext())
> > Decimal("1.23456789012345
Guido writes:
> It looks like if you pass in a context, the Decimal constructor still
> ignores that context
No, you just need to use the right syntax. The correct syntax for
converting a string to a Decimal using a context object is to use
the create_decimal() method of the context object:
>>> i
[Guido]
> It looks like if you pass in a context, the Decimal constructor
> still ignores that context:
>
> >>> import decimal as d
> >>> d.getcontext().prec = 4
> >>> d.Decimal("1.234567890123456789012345678901234567890123456789",
> d.getcontext())
> Decimal("1.2345678901234567890123456789012
It looks like if you pass in a context, the Decimal constructor still
ignores that context:
>>> import decimal as d
>>> d.getcontext().prec = 4
>>> d.Decimal("1.234567890123456789012345678901234567890123456789",
d.getcontext())
Decimal("1.234567890123456789012345678901234567890123456789")
The PyPy 0.6 release
*The PyPy Development Team is happy to announce the first
public release of PyPy after two years of spare-time and
half a year of EU funded development. The 0.6 release
is eminently a preview release.*
What it is and where to start
---
[Raymond Hettinger]
> The word deviate inaccurately suggests that we do not have
> a compliant method which, of course, we do. There are two
> methods, one context aware and the other context free. The
> proposal is to change the behavior of the context free version,
> treat it as a bug, and alte
On May 20, 2005, at 4:31 AM, Ka-Ping Yee wrote:
> Guido van Rossum wrote:
>
>> Do we really need both __context__ and __cause__?
>>
>
> Well, it depends whose needs we're trying to meet.
>
> If we want to satisfy those who have been asking for chaining
> of unexpected secondary exceptions, then w
On 5/20/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> In other words, Java's behavior is much closer to the current behavior
> of Python, at least in terms of features that are user-visible. The
> default behavior in Java is to have infinite precision unless a context
> is supplied that says
> Does it really need to be argued interminably that deviating from a
> standard is a Big Deal?
The word deviate inaccurately suggests that we do not have a compliant
method which, of course, we do. There are two methods, one context
aware and the other context free. The proposal is to change t
On 5/20/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> That's not my interest here. My interest is in a consistent,
Point. Every time I explain Decimal, I have to say "always the context
is applied EXCEPT at construction time".
> > If someone wants to craft another module to wrap around and
> >
[Guido]
> > Here's a bunch of commentary:
[Ping]
> Thanks. Sorry it's taken me a couple of days to get back to this.
> I think i'm caught up on the mail now.
No problem!
> > Also, in that same example, according to your specs, the TypeError
> > raised by bar() has the ZeroDivisionError raised
Tim Peters writes:
> Other important
> implementations of the standard didn't make this mistake; for example,
> Java's BigDecimal|(java.lang.String) constructor follows the rules
> here:
[...]
> Hmm -- or maybe it doesn't! The text says:
[...]
Here is the actual behavior:
Maybe they just meant it as an explanation of "standard form",
clarifying that -0 is turned into +0? (That's what adding 0 does,
right?)
On 5/20/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim Peters]
> > ...
> > Other important implementations of the standard didn't
> > make this mistake; for ex
[Tim Peters]
> ...
> Other important implementations of the standard didn't
> make this mistake; for example, Java's BigDecimal
> (java.lang.String) constructor follows the rules here:
>
>http://www2.hursley.ibm.com/decimalj/deccons.html
Hmm -- or maybe it doesn't! The text says:
The Big
[Guido van Rossum]
> > Do we really need both __context__ and __cause__?
[Ka-Ping Yee]
> Well, it depends whose needs we're trying to meet.
>
> If we want to satisfy those who have been asking for chaining
> of unexpected secondary exceptions, then we have to provide that
> on some attribute.
>
[Michael Chermside]
> Tim, I find Raymond's arguments to be much more persuasive.
> (And that's even BEFORE I read his 11-point missive.) I
> understood the concept that *operations* are context-
> dependent, but decimal *objects* are not, and thus it made
> sense to me that *constructors* were not
Michael Hudson wrote:
> Walter Dörwald <[EMAIL PROTECTED]> writes:
>
>>Ka-Ping Yee wrote:
>>
>>>[...]
>>>(a) ban string exceptions
>>>(b) require all exceptions to derive from Exception
>>>(c) ban bare "except:"
>>>(d) eliminate sys.exc_*
>>
>>I think somewhere in this list should
[Tim and Raymond are slugging it out about whether Decimal constructors
should respect context precision]
Tim, I find Raymond's arguments to be much more persuasive. (And that's
even BEFORE I read his 11-point missive.) I understood the concept that
*operations* are contex-dependent, but decimal
Walter Dörwald <[EMAIL PROTECTED]> writes:
> Ka-Ping Yee wrote:
>
>> [...]
>> (a) ban string exceptions
>> (b) require all exceptions to derive from Exception
>> (c) ban bare "except:"
>> (d) eliminate sys.exc_*
>
> I think somewhere in this list should be:
>
>(?) Remove st
Ka-Ping Yee wrote:
> [...]
> (a) ban string exceptions
> (b) require all exceptions to derive from Exception
> (c) ban bare "except:"
> (d) eliminate sys.exc_*
I think somewhere in this list should be:
(?) Remove string exceptions from the Python stdlib
and perhaps:
Tim Lesher wrote:
> Here's the first draft of the python-dev summary for the first half of
> May. Please send any corrections or suggestions to the summarizers (CC'ed).
Nice work again, folks.
This summary has convinced me that the right thing to do with PEP 3XX is to fix
the formatting, submit
Raymond Hettinger wrote:
> Be careful with this proposed change. It is a can of worms.
> Better yet, don't do it. We already have a context aware
> constructor method if that is what you really want.
And don't forgot that 'context-aware-construction' can also be written:
val = +Decimal(strin
On Fri, 20 May 2005, Ka-Ping Yee wrote:
> Can be back up and see if we can agree on a specification at a semantic
> level first? I've been trying to narrow down exactly what you seem to
> intuitively want -- how do you like the following:
>
>Definition of "context": An exception-raise event X
Guido van Rossum wrote:
> Do we really need both __context__ and __cause__?
Well, it depends whose needs we're trying to meet.
If we want to satisfy those who have been asking for chaining
of unexpected secondary exceptions, then we have to provide that
on some attribute.
If we also want to prov
Guido van Rossum wrote:
> try:
> BLOCK
> except EXCEPTION, VAR:
> HANDLER
>
> I'd like to see this translated into
>
> try:
> BLOCK
> except EXCEPTION, VAR:
> __context = VAR
> try:
> HANDLER
> except Exception, __error:
>
On Mon, 16 May 2005, Guido van Rossum wrote:
> Here's a bunch of commentary:
Thanks. Sorry it's taken me a couple of days to get back to this.
I think i'm caught up on the mail now.
> You're not giving enough credit to Java, which has the "cause" part
> nailed IMO.
You're right. I missed that.
Addenda:
j.) The same rules would need to apply to all forms of the Decimal
contructor, so Decimal(someint) would also need to truncate/round if it
has more than precision digits -- likewise with Decimal(fromtuple) and
Decimal(fromdecimal). All are problematic. Integer conversions are
expected t
34 matches
Mail list logo
