Mark Dickinson schrieb:
On Thu, Mar 27, 2008 at 4:46 AM, Georg Brandl [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
As Nick said, a drop-in replacement in C isn't feasible
But probably users of decimal won't really care if they have to slightly
adapt their code if they
Nick Coghlan wrote:
What features do you find particularly unfortunate?
Whichever ones are making people think that implementing
it in C is infeasible.
Just because
something isn't particularly amenable to implementation in C, doesn't
make it a bad API for a Python library
No, but for
Nick Coghlan wrote:
I believe the list of incompatibilities and kludges and the subsequent
comments in the following file give the gist of the problems:
http://svn.python.org/projects/sandbox/trunk/decimal-c/_decimal.c
It sounds like some aspects of the API weren't thought
through very well
Greg Ewing schrieb:
Nick Coghlan wrote:
I believe the list of incompatibilities and kludges and the subsequent
comments in the following file give the gist of the problems:
http://svn.python.org/projects/sandbox/trunk/decimal-c/_decimal.c
It sounds like some aspects of the API weren't
On Thu, Mar 27, 2008 at 4:46 AM, Georg Brandl [EMAIL PROTECTED] wrote:
As Nick said, a drop-in replacement in C isn't feasible
But probably users of decimal won't really care if they have to slightly
adapt their code if they get the speed increase instead.
We had a SOC student working on
Greg Ewing wrote:
I thought Decimal was going to be replaced by a C
implementation soon anyway. If so, is it worth going
to much trouble over this?
I believe that was found to be more trouble than it was worth. So the
optimisations focused on various ways of making the Python
Martin v. Löwis wrote:
For binary representations, we already have the struct module to handle
the parsing, but for byte sequences with embedded ASCII digits it's
reasonably common practice to use strings along with the respective type
constructors.
Sure, but why can't you write
foo
On 2008-03-26 07:11, Martin v. Löwis wrote:
For binary representations, we already have the struct module to handle
the parsing, but for byte sequences with embedded ASCII digits it's
reasonably common practice to use strings along with the respective type
constructors.
Sure, but why
On Wed, Mar 26, 2008 at 2:57 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Greg Ewing wrote:
I thought Decimal was going to be replaced by a C
implementation soon anyway. If so, is it worth going
to much trouble over this?
I believe that was found to be more trouble than it was worth. So
2008/3/26, Mark Dickinson [EMAIL PROTECTED]:
I think it's still worth considering a hybrid implementation of Decimal:
C code for the basic integer arithmetic (that is, supply a long int
replacement whose underlying implementation works in base a
power of 10), and Python for all the
Mark Dickinson wrote:
On Wed, Mar 26, 2008 at 2:57 AM, Nick Coghlan [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Greg Ewing wrote:
I thought Decimal was going to be replaced by a C
implementation soon anyway. If so, is it worth going
to much trouble over this?
Nick Coghlan wrote:
Greg Ewing wrote:
I thought Decimal was going to be replaced by a C
implementation soon anyway.
I believe that was found to be more trouble than it was worth.
That's very disappointing. Was there any discussion of
the problems that killed it? I don't remember seeing
Nick Coghlan wrote:
Yeah, this thread has convinced me that it would be better to start
rejecting bytes in int() and float() as well rather than implicitly
assuming an ASCII encoding.
I had another thought -- would it be feasible to have
some kind of wrapper object that would make a byte
Greg Ewing wrote:
Nick Coghlan wrote:
Greg Ewing wrote:
I thought Decimal was going to be replaced by a C
implementation soon anyway.
I believe that was found to be more trouble than it was worth.
That's very disappointing. Was there any discussion of
the problems that killed it? I don't
Hello. In Python 2.5.1 the code
import decimal
for d in '123', u'123':
x = decimal.Decimal(d)
print type(x.to_eng_string())
prints
type 'str'
type 'str'
In 2.5.2 it prints
type 'str'
type 'unicode'
Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
always
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann [EMAIL PROTECTED] wrote:
In 2.5.2 it prints
type 'str'
type 'unicode'
Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
always return a str?
I'd call this a bug. The change is an accident, a side-effect of the
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann [EMAIL PROTECTED] wrote:
In 2.5.2 it prints
type 'str'
type 'unicode'
Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
always return a str?
I'd call this a bug. The change is an accident, a side-effect of the
2008/3/25, Mark Dickinson [EMAIL PROTECTED]:
I'd call this a bug. The change is an accident, a side-effect of the fact
that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a
tuple, and in 2.5.2 it's stored as a string (which greatly improves
efficiency).
Clearly in 2.5.2
Mark Dickinson wrote:
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann [EMAIL PROTECTED] wrote:
In 2.5.2 it prints
type 'str'
type 'unicode'
Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
always return a str?
I'd call this a bug. The change is an accident,
On Tue, Mar 25, 2008 at 10:47:42AM -0400, Mark Dickinson wrote:
On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann [EMAIL PROTECTED] wrote:
In 2.5.2 it prints
type 'str'
type 'unicode'
Why the change? Is it a bug or a feature? Shouldn't .to_eng_string()
always return a str?
On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
I thought that might be what happened, but I couldn't remember if that
optimisation was a 2.6 only change or not (I suspect it was included in
2.5 as a prereq to the spec compliance updates).
Exactly.
Anyway, +1 on
2008/3/25, Nick Coghlan [EMAIL PROTECTED]:
Anyway, +1 on coercing the mantissa to a str() instance in 2.5.
I don't know about 2.5, I'm sure about 2.6.
To fix this, decimal probably needs to grow something like the following
near the top of the module:
try:
_bytes = bytes
On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
The isinstance(value, str) check in Py3k is too restrictive - it needs
to accept bytes instances as well.
Hmm. There's not a lot of consistency here:
int(b'1')
1
float(b'1')
1.0
complex(b'1')
Traceback (most recent
2008/3/25, Mark Dickinson [EMAIL PROTECTED]:
So int and float accepts bytes, while complex, Decimal and Fraction do
not...
I'm -1 to accept bytes as input for Decimal, I don't see a case of
use, and I think that conceptually there's no reason to do it.
Of course, I can be wrong, ;)
Regards,
On Tue, Mar 25, 2008 at 11:57 AM, Facundo Batista [EMAIL PROTECTED]
wrote:
2008/3/25, Mark Dickinson [EMAIL PROTECTED]:
So int and float accepts bytes, while complex, Decimal and Fraction do
not...
I'm -1 to accept bytes as input for Decimal, I don't see a case of
use, and I think that
Facundo Batista wrote:
2008/3/25, Mark Dickinson [EMAIL PROTECTED]:
So int and float accepts bytes, while complex, Decimal and Fraction do
not...
I'm -1 to accept bytes as input for Decimal, I don't see a case of
use, and I think that conceptually there's no reason to do it.
Of course,
On Tue, Mar 25, 2008 at 9:43 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
...
Since we have some strong use cases at least for the bytes-int case,
consistency then suggests that the other numeric types should all accept
bytes as well (interpreting them as ASCII encoded strings).
+1 -- it
Mark Dickinson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| On Tue, Mar 25, 2008 at 11:29 AM, Nick Coghlan [EMAIL PROTECTED]
wrote:
|
| The isinstance(value, str) check in Py3k is too restrictive - it needs
| to accept bytes instances as well.
|
|
| Hmm. There's not a lot of
I'd call this a bug. The change is an accident, a side-effect of the fact
that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a
tuple, and in 2.5.2 it's stored as a string (which greatly improves
efficiency).
Clearly in 2.5.2 the mantissa is being stored as a unicode
Martin v. Löwis wrote:
I'd call this a bug. The change is an accident, a side-effect of the fact
that in 2.5.1 the coefficient (mantissa) of a Decimal was stored as a
tuple, and in 2.5.2 it's stored as a string (which greatly improves
efficiency).
Clearly in 2.5.2 the mantissa is being
Nick Coghlan wrote:
Since we have some strong use cases at least for the bytes-int case,
consistency then suggests that the other numeric types should all accept
bytes as well (interpreting them as ASCII encoded strings).
How far should this go? Is conversion to numbers really
so special, or
Terry Reedy wrote:
The purpose of type constructors is to construct instances from reasonable
inputs. I think all number constructors should accept bytes
What should bytes as input to a number constructor
mean, though?
People seem to be assuming it should be interpreted
as ASCII-encoded
Greg Ewing wrote:
Terry Reedy wrote:
The purpose of type constructors is to construct instances from reasonable
inputs. I think all number constructors should accept bytes
What should bytes as input to a number constructor
mean, though?
People seem to be assuming it should be
2008/3/25, Alex Martelli [EMAIL PROTECTED]:
Since we have some strong use cases at least for the bytes-int case,
consistency then suggests that the other numeric types should all accept
bytes as well (interpreting them as ASCII encoded strings).
+1 -- it seems very practical as well
I thought Decimal was going to be replaced by a C
implementation soon anyway. If so, is it worth going
to much trouble over this?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
35 matches
Mail list logo
