[Python-Dev] Decimal(unicode)

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 In 2.5.2 it prints Why the change? Is it a bug or a feature? Shouldn't .to_eng_string() always return a str? Oleg. -- Oleg Broytmann

Re: [Python-Dev] Decimal(unicode)

On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: >In 2.5.2 it prints > > > > >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 fact that in 2.5.1

Re: [Python-Dev] Decimal(unicode)

On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: >In 2.5.2 it prints > > > > >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 fact that in 2.5.1

Re: [Python-Dev] Decimal(unicode)

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 i

Re: [Python-Dev] Decimal(unicode)

Mark Dickinson wrote: > On Tue, Mar 25, 2008 at 9:46 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: >>In 2.5.2 it prints >> >> >> >> >>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 sid

Re: [Python-Dev] Decimal(unicode)

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 > > > > > > > > > >Why the change? Is it a bug or a feature? Shouldn't .to_eng_string() > > always return a str? > > I'd c

Re: [Python-Dev] Decimal(unicode)

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

Re: [Python-Dev] Decimal(unicode)

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 = byte

Re: [Python-Dev] Decimal(unicode)

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 (m

Re: [Python-Dev] Decimal(unicode)

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, ;) Regard

Re: [Python-Dev] Decimal(unicode)

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

Re: [Python-Dev] Decimal(unicode)

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. >

Re: [Python-Dev] Decimal(unicode)

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 --

Re: [Python-Dev] Decimal(unicode)

"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

Re: [Python-Dev] Decimal(unicode)

> 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 ins

Re: [Python-Dev] Decimal(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 b

Re: [Python-Dev] Decimal(unicode)

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,

Re: [Python-Dev] Decimal(unicode)

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 cha

Re: [Python-Dev] Decimal(unicode)

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

Re: [Python-Dev] Decimal(unicode)

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 practica

Re: [Python-Dev] Decimal(unicode)

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:

Re: [Python-Dev] Decimal(unicode)

> 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 = int(bar[start:stop].de

Re: [Python-Dev] Decimal(unicode)

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 implementa

Re: [Python-Dev] Decimal(unicode)

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

Re: [Python-Dev] Decimal(unicode)

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, bu

Re: [Python-Dev] Decimal(unicode)

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

Re: [Python-Dev] Decimal(unicode)

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 comp

Re: [Python-Dev] Decimal(unicode)

Mark Dickinson wrote: > 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

Re: [Python-Dev] Decimal(unicode)

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 se

Re: [Python-Dev] Decimal(unicode)

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

Re: [Python-Dev] Decimal(unicode)

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 kil

Re: [Python-Dev] Decimal(unicode)

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

Re: [Python-Dev] Decimal(unicode)

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 were

Re: [Python-Dev] Decimal(unicode)

2008/3/26, Nick Coghlan <[EMAIL PROTECTED]>: > Basically, while it makes a lot of sense to move the *arithmetic* to C > (as Mark mentioned in his other post), there's a lot of ancillary stuff > related to flags and exceptions and context handling that is much easier > to handle in Python. Tha

Re: [Python-Dev] Decimal(unicode)

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 workin

Re: [Python-Dev] Decimal(unicode)

Georg Brandl wrote: > As Nick said, a drop-in replacement in C isn't feasible Yes, but that appears to be so only because of some unfortunate features of the Python version's API. Seems to me it would be better to undergo a little pain now and get a well-designed C-friendly API. -- Greg __

Re: [Python-Dev] Decimal(unicode)

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. > Could you give me an examp

Re: [Python-Dev] Decimal(unicode)

Greg Ewing wrote: > Georg Brandl wrote: > >> As Nick said, a drop-in replacement in C isn't feasible > > Yes, but that appears to be so only because of some > unfortunate features of the Python version's API. > > Seems to me it would be better to undergo a little > pain now and get a well-design

Re: [Python-Dev] Decimal(unicode)

Mark Dickinson schrieb: > 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 co

Re: [Python-Dev] Decimal(unicode)

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