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
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.
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:
>
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
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
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
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
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:
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
[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
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
[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
[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.
>
[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
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 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:
[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
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
> >
> 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, 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
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
[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
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
---
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")
[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
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.23456789012345
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
[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
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
[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
> 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
[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
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
34 matches
Mail list logo
