[Python-ideas] Python-ideas Digest, Vol 103, Issue 16

Tue Jun 2 05:55:55 CEST 2015

Thanks for making that patch!

On Mon, Jun 1, 2015 at 8:48 PM,  <python-ideas-request at python.org> wrote:
> Send Python-ideas mailing list submissions to
>         python-ideas at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
>         python-ideas-request at python.org
>
> You can reach the person managing the list at
>         python-ideas-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
>
> Today's Topics:
>
>    1. Re: Python-ideas Digest, Vol 103, Issue 14
>       (u8y7541 The Awesome Person)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 1 Jun 2015 20:48:51 -0700
> From: u8y7541 The Awesome Person <surya.subbarao1 at gmail.com>
> To: python-ideas at python.org, abarnert at yahoo.com
> Subject: Re: [Python-ideas] Python-ideas Digest, Vol 103, Issue 14
> Message-ID:
>         <CA+o1fZNoPAmTP_ZwPnqtEEdyBL8Gq=CjLRvohoeT7aeW+n0sEg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> That patch sounds nice, I don't have to edit my Python distribution! We'll
> have to do with this.
>
> On Mon, Jun 1, 2015 at 7:03 PM, <python-ideas-request at python.org> wrote:
>
>> Send Python-ideas mailing list submissions to
>>         python-ideas at python.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://mail.python.org/mailman/listinfo/python-ideas
>> or, via email, send a message with subject or body 'help' to
>>         python-ideas-request at python.org
>>
>> You can reach the person managing the list at
>>         python-ideas-owner at python.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Python-ideas digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Python Float Update (Nick Coghlan)
>>    2. Re: Python Float Update (Andrew Barnert)
>>    3. Re: Python Float Update (Andrew Barnert)
>>    4. Re: Python Float Update (Steven D'Aprano)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 2 Jun 2015 10:08:37 +1000
>> From: Nick Coghlan <ncoghlan at gmail.com>
>> To: Andrew Barnert <abarnert at yahoo.com>
>> Cc: python-ideas <python-ideas at python.org>
>> Subject: Re: [Python-ideas] Python Float Update
>> Message-ID:
>>         <
>> CADiSq7fjhS_XrKe3QfF58hXdhLSSbX6NvsFZZKjRq-+OLOQ-eQ at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On 2 Jun 2015 08:44, "Andrew Barnert via Python-ideas"
>> <python-ideas at python.org> wrote:
>> >But the basic idea can be extracted out and Pythonified:
>> >
>> > The literal 1.23 no longer gives you a float, but a FloatLiteral, which
>> is either a subclass of float, or an unrelated class that has a __float__
>> method. Doing any calculation on it gives you a float. But as long as you
>> leave it alone as a FloatLiteral, it has its literal characters available
>> for any function that wants to distinguish FloatLiteral from float, like
>> the Decimal constructor.
>> >
>> > The problem that Python faces that Swift doesn't is that Python doesn't
>> use static typing and implicit compile-time conversions. So in Python,
>> you'd be passing around these larger values and doing the slow conversions
>> at runtime. That may or may not be unacceptable; without actually building
>> it and testing some realistic programs it's pretty hard to guess.
>>
>> Joonas's suggestion of storing the original text representation passed
>> to the float constructor is at least a novel one - it's only the idea
>> of actual decimal literals that was ruled out in the past.
>>
>> Aside from the practical implementation question, the main concern I
>> have with it is that we'd be trading the status quo for a situation
>> where "Decimal(1.3)" and "Decimal(13/10)" gave different answers.
>>
>> It seems to me that a potentially better option might be to adjust the
>> implicit float->Decimal conversion in the Decimal constructor to use
>> the same algorithm as we now use for float.__repr__ [1], where we look
>> for the shortest decimal representation that gives the same answer
>> when rendered as a float. At the moment you have to indirect through
>> str() or repr() to get that behaviour:
>>
>>  >>> from decimal import Decimal as D
>>  >>> 1.3
>>  1.3
>>  >>> D('1.3')
>>  Decimal('1.3')
>>  >>> D(1.3)
>>  Decimal('1.3000000000000000444089209850062616169452667236328125')
>>  >>> D(str(1.3))
>>  Decimal('1.3')
>>
>> Cheers,
>> Nick.
>>
>> [1] http://bugs.python.org/issue1580
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 1 Jun 2015 18:27:32 -0700
>> From: Andrew Barnert <abarnert at yahoo.com>
>> To: Nick Coghlan <ncoghlan at gmail.com>
>> Cc: python-ideas <python-ideas at python.org>
>> Subject: Re: [Python-ideas] Python Float Update
>> Message-ID: <EBB58361-19F4-4275-B6A6-E5AF2F77EF9C at yahoo.com>
>> Content-Type: text/plain;       charset=us-ascii
>>
>> On Jun 1, 2015, at 17:08, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> >
>> > On 2 Jun 2015 08:44, "Andrew Barnert via Python-ideas"
>> > <python-ideas at python.org> wrote:
>> >> But the basic idea can be extracted out and Pythonified:
>> >>
>> >> The literal 1.23 no longer gives you a float, but a FloatLiteral, which
>> is either a subclass of float, or an unrelated class that has a __float__
>> method. Doing any calculation on it gives you a float. But as long as you
>> leave it alone as a FloatLiteral, it has its literal characters available
>> for any function that wants to distinguish FloatLiteral from float, like
>> the Decimal constructor.
>> >>
>> >> The problem that Python faces that Swift doesn't is that Python doesn't
>> use static typing and implicit compile-time conversions. So in Python,
>> you'd be passing around these larger values and doing the slow conversions
>> at runtime. That may or may not be unacceptable; without actually building
>> it and testing some realistic programs it's pretty hard to guess.
>> >
>> > Joonas's suggestion of storing the original text representation passed
>> > to the float constructor is at least a novel one - it's only the idea
>> > of actual decimal literals that was ruled out in the past.
>>
>> I actually built about half an implementation of something like Swift's
>> LiteralConvertible protocol back when I was teaching myself Swift. But I
>> think I have a simpler version that I could implement much more easily.
>>
>> Basically, FloatLiteral is just a subclass of float whose __new__ stores
>> its constructor argument. Then decimal.Decimal checks for that stored
>> string and uses it instead of the float value if present. Then there's an
>> import hook that replaces every Num with a call to FloatLiteral.
>>
>> This design doesn't actually fix everything; in effect, 1.3 actually
>> compiles to FloatLiteral(str(float('1.3')) (because by the time you get to
>> the AST it's too late to avoid that first conversion). Which does actually
>> solve the problem with 1.3, but doesn't solve everything in general (e.g.,
>> just feed in a number that has more precision than a double can hold but
>> less than your current decimal context can...).
>>
>> But it just lets you test whether the implementation makes sense and what
>> the performance effects are, and it's only an hour of work, and doesn't
>> require anyone to patch their interpreter to play with it. If it seems
>> promising, then hacking the compiler so 2.3 compiles to FloatLiteral('2.3')
>> may be worth doing for a test of the actual functionality.
>>
>> I'll be glad to hack it up when I get a chance tonight. But personally, I
>> think decimal literals are a better way to go here. Decimal(1.20) magically
>> doing what you want still has all the same downsides as 1.20d (or implicit
>> decimal literals), plus it's more complex, adds performance costs, and
>> doesn't provide nearly as much benefit. (Yes, Decimal(1.20) is a little
>> nicer than Decimal('1.20'), but only a little--and nowhere near as nice as
>> 1.20d).
>>
>> > Aside from the practical implementation question, the main concern I
>> > have with it is that we'd be trading the status quo for a situation
>> > where "Decimal(1.3)" and "Decimal(13/10)" gave different answers.
>>
>> Yes, to solve that you really need Decimal(13)/Decimal(10)... Which
>> implies that maybe the simplification in Decimal(1.3) is more misleading
>> than helpful. (Notice that this problem also doesn't arise for decimal
>> literals--13/10d is int vs. Decimal division, which is correct out of the
>> box. Or, if you want prefixes, d13/10 is Decimal vs. int division.)
>>
>> > It seems to me that a potentially better option might be to adjust the
>> > implicit float->Decimal conversion in the Decimal constructor to use
>> > the same algorithm as we now use for float.__repr__ [1], where we look
>> > for the shortest decimal representation that gives the same answer
>> > when rendered as a float. At the moment you have to indirect through
>> > str() or repr() to get that behaviour:
>> >
>> >>>> from decimal import Decimal as D
>> >>>> 1.3
>> > 1.3
>> >>>> D('1.3')
>> > Decimal('1.3')
>> >>>> D(1.3)
>> > Decimal('1.3000000000000000444089209850062616169452667236328125')
>> >>>> D(str(1.3))
>> > Decimal('1.3')
>> >
>> > Cheers,
>> > Nick.
>> >
>> > [1] http://bugs.python.org/issue1580
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Mon, 1 Jun 2015 19:00:48 -0700
>> From: Andrew Barnert <abarnert at yahoo.com>
>> To: Andrew Barnert <abarnert at yahoo.com>
>> Cc: Nick Coghlan <ncoghlan at gmail.com>, python-ideas
>>         <python-ideas at python.org>
>> Subject: Re: [Python-ideas] Python Float Update
>> Message-ID: <90691306-98E3-421B-ABEB-BA2DE05962C6 at yahoo.com>
>> Content-Type: text/plain;       charset=us-ascii
>>
>> On Jun 1, 2015, at 18:27, Andrew Barnert via Python-ideas <
>> python-ideas at python.org> wrote:
>> >
>> >> On Jun 1, 2015, at 17:08, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> >>
>> >> On 2 Jun 2015 08:44, "Andrew Barnert via Python-ideas"
>> >> <python-ideas at python.org> wrote:
>> >>> But the basic idea can be extracted out and Pythonified:
>> >>>
>> >>> The literal 1.23 no longer gives you a float, but a FloatLiteral,
>> which is either a subclass of float, or an unrelated class that has a
>> __float__ method. Doing any calculation on it gives you a float. But as
>> long as you leave it alone as a FloatLiteral, it has its literal characters
>> available for any function that wants to distinguish FloatLiteral from
>> float, like the Decimal constructor.
>> >>>
>> >>> The problem that Python faces that Swift doesn't is that Python
>> doesn't use static typing and implicit compile-time conversions. So in
>> Python, you'd be passing around these larger values and doing the slow
>> conversions at runtime. That may or may not be unacceptable; without
>> actually building it and testing some realistic programs it's pretty hard
>> to guess.
>> >>
>> >> Joonas's suggestion of storing the original text representation passed
>> >> to the float constructor is at least a novel one - it's only the idea
>> >> of actual decimal literals that was ruled out in the past.
>> >
>> > I actually built about half an implementation of something like Swift's
>> LiteralConvertible protocol back when I was teaching myself Swift. But I
>> think I have a simpler version that I could implement much more easily.
>> >
>> > Basically, FloatLiteral is just a subclass of float whose __new__ stores
>> its constructor argument. Then decimal.Decimal checks for that stored
>> string and uses it instead of the float value if present. Then there's an
>> import hook that replaces every Num with a call to FloatLiteral.
>> >
>> > This design doesn't actually fix everything; in effect, 1.3 actually
>> compiles to FloatLiteral(str(float('1.3')) (because by the time you get to
>> the AST it's too late to avoid that first conversion). Which does actually
>> solve the problem with 1.3, but doesn't solve everything in general (e.g.,
>> just feed in a number that has more precision than a double can hold but
>> less than your current decimal context can...).
>> >
>> > But it just lets you test whether the implementation makes sense and
>> what the performance effects are, and it's only an hour of work,
>>
>> Make that 15 minutes.
>>
>> https://github.com/abarnert/floatliteralhack
>>
>> > and doesn't require anyone to patch their interpreter to play with it.
>> If it seems promising, then hacking the compiler so 2.3 compiles to
>> FloatLiteral('2.3') may be worth doing for a test of the actual
>> functionality.
>> >
>> > I'll be glad to hack it up when I get a chance tonight. But personally,
>> I think decimal literals are a better way to go here. Decimal(1.20)
>> magically doing what you want still has all the same downsides as 1.20d (or
>> implicit decimal literals), plus it's more complex, adds performance costs,
>> and doesn't provide nearly as much benefit. (Yes, Decimal(1.20) is a little
>> nicer than Decimal('1.20'), but only a little--and nowhere near as nice as
>> 1.20d).
>> >
>> >> Aside from the practical implementation question, the main concern I
>> >> have with it is that we'd be trading the status quo for a situation
>> >> where "Decimal(1.3)" and "Decimal(13/10)" gave different answers.
>> >
>> > Yes, to solve that you really need Decimal(13)/Decimal(10)... Which
>> implies that maybe the simplification in Decimal(1.3) is more misleading
>> than helpful. (Notice that this problem also doesn't arise for decimal
>> literals--13/10d is int vs. Decimal division, which is correct out of the
>> box. Or, if you want prefixes, d13/10 is Decimal vs. int division.)
>> >
>> >> It seems to me that a potentially better option might be to adjust the
>> >> implicit float->Decimal conversion in the Decimal constructor to use
>> >> the same algorithm as we now use for float.__repr__ [1], where we look
>> >> for the shortest decimal representation that gives the same answer
>> >> when rendered as a float. At the moment you have to indirect through
>> >> str() or repr() to get that behaviour:
>> >>
>> >>>>> from decimal import Decimal as D
>> >>>>> 1.3
>> >> 1.3
>> >>>>> D('1.3')
>> >> Decimal('1.3')
>> >>>>> D(1.3)
>> >> Decimal('1.3000000000000000444089209850062616169452667236328125')
>> >>>>> D(str(1.3))
>> >> Decimal('1.3')
>> >>
>> >> Cheers,
>> >> Nick.
>> >>
>> >> [1] http://bugs.python.org/issue1580
>> > _______________________________________________
>> > Python-ideas mailing list
>> > Python-ideas at python.org
>> > https://mail.python.org/mailman/listinfo/python-ideas
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 2 Jun 2015 11:58:09 +1000
>> From: Steven D'Aprano <steve at pearwood.info>
>> To: python-ideas at python.org
>> Subject: Re: [Python-ideas] Python Float Update
>> Message-ID: <20150602015809.GE932 at ando.pearwood.info>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Tue, Jun 02, 2015 at 10:08:37AM +1000, Nick Coghlan wrote:
>>
>> > It seems to me that a potentially better option might be to adjust the
>> > implicit float->Decimal conversion in the Decimal constructor to use
>> > the same algorithm as we now use for float.__repr__ [1], where we look
>> > for the shortest decimal representation that gives the same answer
>> > when rendered as a float. At the moment you have to indirect through
>> > str() or repr() to get that behaviour:
>>
>> Apart from the questions of whether such a change would be allowed by
>> the Decimal specification, and the breaking of backwards compatibility,
>> I would really hate that change for another reason.
>>
>> At the moment, a good, cheap way to find out what a binary float "really
>> is" (in some sense) is to convert it to Decimal and see what you get:
>>
>> Decimal(1.3)
>> -> Decimal('1.3000000000000000444089209850062616169452667236328125')
>>
>> If you want conversion from repr, then you can be explicit about it:
>>
>> Decimal(repr(1.3))
>> -> Decimal('1.3')
>>
>> ("Explicit is better than implicit", as they say...)
>>
>> Although in fairness I suppose that if this change happens, we could
>> keep the old behaviour in the from_float method:
>>
>> # hypothetical future behaviour
>> Decimal(1.3)
>> -> Decimal('1.3')
>> Decimal.from_float(1.3)
>> -> Decimal('1.3000000000000000444089209850062616169452667236328125')
>>
>> But all things considered, I don't think we're doing people any favours
>> by changing the behaviour of float->Decimal conversions to implicitly
>> use the repr() instead of being exact. I expect this strategy is like
>> trying to flatten a bubble under wallpaper: all you can do is push the
>> gotchas and surprises to somewhere else.
>>
>> Oh, another thought... Decimals could gain yet another conversion
>> method, one which implicitly uses the float repr, but signals if it was
>> an inexact conversion or not. Explicitly calling repr can never signal,
>> since the conversion occurs outside of the Decimal constructor and
>> Decimal sees only the string:
>>
>> Decimal(repr(1.3)) cannot signal Inexact.
>>
>> But:
>>
>> Decimal.from_nearest_float(1.5)  # exact
>> Decimal.from_nearest_float(1.3)  # signals Inexact
>>
>> That might be useful, but probably not to beginners.
>>
>>
>> --
>> Steve
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>>
>>
>> ------------------------------
>>
>> End of Python-ideas Digest, Vol 103, Issue 14
>> *********************************************
>>
>
>
>
> --
> -Surya Subbarao
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150601/b2e1ea11/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> ------------------------------
>
> End of Python-ideas Digest, Vol 103, Issue 16
> *********************************************

-- 
-Surya Subbarao