Mailman 3 June 2015 - Python-ideas

Explicitly shared objects with sub modules vs import
by Ron Adam 02 Jun '15

02 Jun '15

While trying to debug a problem and thinking that it may be an issue with circular imports, I come up with an interesting idea that might be of value. It wasn't a circular import problem in this case, but I may have found the actual bug sooner if I didn't need to be concerned about that possibility. I have had some difficulty splitting larger modules into smaller modules in the past where if I split the code by functionality, it doesn't correspond with how the code is organized by dependency. The result is an imported module needs to import the module it's imported into. Which just doesn't feel right to me. The solution I found was to call a function to explicitly set the shared items in the imported module. (The example is from a language I'm experimenting with written in python. So don't be concerned about the shared object names in this case.) In the main module... import parse parse.set_main(List=List, Keyword=Keyword, Name=Name, String=String, Express=Express, keywords=keywords, raise_with=raise_with, nil=nil) And in parse... # Sets shared objects from main module. from collections import namedtuple def set_main(**d): global main main = namedtuple(__name__, d.keys()) for k, v in d.items(): setattr(main, k, v) After this, the sub module access's the parent modules objects with... main.Keyword Just the same as if the parent module was imported as main, but it only shares what is intended to be shared within this specific imported module. I think that is better than using "import from" in the sub module. And an improvement over importing the whole module which can possibly expose too much. The benifits: * The shared items are explicitly set by the parent module. * If an item is missing, it results in a nice error message * Accessing objects works the same as if import was used. * It avoids (most) circular import problems. * It's easier to think about once you understand what it does. The problem is the submodule needs a function to make it work. I think it would be nice if it could be made a builtin but doing that may be tricky. Where I've used "main", it could set the name of the shared parent module(s) automatically. The name of the function probably should be "shared" or "sharing". (Or some other thing that makes sense.) I would like to hear what other here think, and of course if there are any obvious improvements that can be made. Would this be a good candidate for a new builtin? Cheers, Ron

4 6

Re: [Python-ideas] Python-ideas Digest, Vol 103, Issue 16
by u8y7541 The Awesome Person 02 Jun '15

02 Jun '15

Thanks for making that patch! On Mon, Jun 1, 2015 at 8:48 PM, <python-ideas-request(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)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(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)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(a)gmail.com> > To: python-ideas(a)python.org, abarnert(a)yahoo.com > Subject: Re: [Python-ideas] Python-ideas Digest, Vol 103, Issue 14 > Message-ID: > <CA+o1fZNoPAmTP_ZwPnqtEEdyBL8Gq=CjLRvohoeT7aeW+n0sEg(a)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(a)python.org> wrote: > >> Send Python-ideas mailing list submissions to >> python-ideas(a)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(a)python.org >> >> You can reach the person managing the list at >> python-ideas-owner(a)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(a)gmail.com> >> To: Andrew Barnert <abarnert(a)yahoo.com> >> Cc: python-ideas <python-ideas(a)python.org> >> Subject: Re: [Python-ideas] Python Float Update >> Message-ID: >> < >> CADiSq7fjhS_XrKe3QfF58hXdhLSSbX6NvsFZZKjRq-+OLOQ-eQ(a)mail.gmail.com> >> Content-Type: text/plain; charset=UTF-8 >> >> On 2 Jun 2015 08:44, "Andrew Barnert via Python-ideas" >> <python-ideas(a)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(a)yahoo.com> >> To: Nick Coghlan <ncoghlan(a)gmail.com> >> Cc: python-ideas <python-ideas(a)python.org> >> Subject: Re: [Python-ideas] Python Float Update >> Message-ID: <EBB58361-19F4-4275-B6A6-E5AF2F77EF9C(a)yahoo.com> >> Content-Type: text/plain; charset=us-ascii >> >> On Jun 1, 2015, at 17:08, Nick Coghlan <ncoghlan(a)gmail.com> wrote: >> > >> > On 2 Jun 2015 08:44, "Andrew Barnert via Python-ideas" >> > <python-ideas(a)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(a)yahoo.com> >> To: Andrew Barnert <abarnert(a)yahoo.com> >> Cc: Nick Coghlan <ncoghlan(a)gmail.com>, python-ideas >> <python-ideas(a)python.org> >> Subject: Re: [Python-ideas] Python Float Update >> Message-ID: <90691306-98E3-421B-ABEB-BA2DE05962C6(a)yahoo.com> >> Content-Type: text/plain; charset=us-ascii >> >> On Jun 1, 2015, at 18:27, Andrew Barnert via Python-ideas < >> python-ideas(a)python.org> wrote: >> > >> >> On Jun 1, 2015, at 17:08, Nick Coghlan <ncoghlan(a)gmail.com> wrote: >> >> >> >> On 2 Jun 2015 08:44, "Andrew Barnert via Python-ideas" >> >> <python-ideas(a)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(a)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(a)pearwood.info> >> To: python-ideas(a)python.org >> Subject: Re: [Python-ideas] Python Float Update >> Message-ID: <20150602015809.GE932(a)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(a)python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> >> >> ------------------------------ >> >> End of Python-ideas Digest, Vol 103, Issue 14 >> ********************************************* >> > > > > -- > -Surya Subbarao >

1 0

Re: [Python-ideas] Python-ideas Digest, Vol 103, Issue 14
by u8y7541 The Awesome Person 02 Jun '15

02 Jun '15

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(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)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(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)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(a)gmail.com> > To: Andrew Barnert <abarnert(a)yahoo.com> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Python Float Update > Message-ID: > < > CADiSq7fjhS_XrKe3QfF58hXdhLSSbX6NvsFZZKjRq-+OLOQ-eQ(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 2 Jun 2015 08:44, "Andrew Barnert via Python-ideas" > <python-ideas(a)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(a)yahoo.com> > To: Nick Coghlan <ncoghlan(a)gmail.com> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Python Float Update > Message-ID: <EBB58361-19F4-4275-B6A6-E5AF2F77EF9C(a)yahoo.com> > Content-Type: text/plain; charset=us-ascii > > On Jun 1, 2015, at 17:08, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > > > > On 2 Jun 2015 08:44, "Andrew Barnert via Python-ideas" > > <python-ideas(a)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(a)yahoo.com> > To: Andrew Barnert <abarnert(a)yahoo.com> > Cc: Nick Coghlan <ncoghlan(a)gmail.com>, python-ideas > <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Python Float Update > Message-ID: <90691306-98E3-421B-ABEB-BA2DE05962C6(a)yahoo.com> > Content-Type: text/plain; charset=us-ascii > > On Jun 1, 2015, at 18:27, Andrew Barnert via Python-ideas < > python-ideas(a)python.org> wrote: > > > >> On Jun 1, 2015, at 17:08, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > >> > >> On 2 Jun 2015 08:44, "Andrew Barnert via Python-ideas" > >> <python-ideas(a)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(a)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(a)pearwood.info> > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] Python Float Update > Message-ID: <20150602015809.GE932(a)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(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > > > ------------------------------ > > End of Python-ideas Digest, Vol 103, Issue 14 > ********************************************* > -- -Surya Subbarao

1 0

Re: [Python-ideas] Python-ideas Digest, Vol 103, Issue 10
by u8y7541 The Awesome Person 01 Jun '15

01 Jun '15

Thanks Stefan for quicktions! On Mon, Jun 1, 2015 at 1:18 PM, <python-ideas-request(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)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(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)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 3 > (u8y7541 The Awesome Person) > 2. Re: Python Float Update (Stefan Behnel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 1 Jun 2015 12:22:40 -0700 > From: u8y7541 The Awesome Person <surya.subbarao1(a)gmail.com> > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] Python-ideas Digest, Vol 103, Issue 3 > Message-ID: > <CA+o1fZMHxNybOjMWr7Uqk8= > AKBncpAKXy+QO+vhF8ENtAXL6qg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Maybe we could make a C implementation of the Fraction module? That would > be nice. > > On Sun, May 31, 2015 at 8:28 PM, <python-ideas-request(a)python.org> wrote: > > > Send Python-ideas mailing list submissions to > > python-ideas(a)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(a)python.org > > > > You can reach the person managing the list at > > python-ideas-owner(a)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 (Chris Angelico) > > 2. Re: Python Float Update (random832(a)fastmail.us) > > 3. Re: Python Float Update (Jim Witschey) > > 4. Re: Python Float Update (David Mertz) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 1 Jun 2015 12:48:12 +1000 > > From: Chris Angelico <rosuav(a)gmail.com> > > Cc: python-ideas <python-ideas(a)python.org> > > Subject: Re: [Python-ideas] Python Float Update > > Message-ID: > > <CAPTjJmr=LurRUoKH3KVVYpMFc= > > W5h6etG5TscV5uU6zWhxVbgQ(a)mail.gmail.com> > > Content-Type: text/plain; charset=UTF-8 > > > > On Mon, Jun 1, 2015 at 12:25 PM, u8y7541 The Awesome Person > > <surya.subbarao1(a)gmail.com> wrote: > > > > > > I will be presenting a modification to the float class, which will > > improve its speed and accuracy (reduce floating point errors). This is > > applicable because Python uses a numerator and denominator rather than a > > sign and mantissa to represent floats. > > > > > > First, I propose that a float's integer ratio should be accurate. For > > example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it > > returns(6004799503160661, 18014398509481984). > > > > > > > I think you're misunderstanding the as_integer_ratio method. That > > isn't how Python works internally; that's a service provided for > > parsing out float internals into something more readable. What you > > _actually_ are working with is IEEE 754 binary64. (Caveat: I have no > > idea what Python-the-language stipulates, nor what other Python > > implementations use, but that's what CPython uses, and you did your > > initial experiments with CPython. None of this discussion applies *at > > all* if a Python implementation doesn't use IEEE 754.) So internally, > > 1/3 is stored as: > > > > 0 <-- sign bit (positive) > > 01111111101 <-- exponent (1021) > > 0101010101010101010101010101010101010101010101010101 <-- mantissa (52 > > bits, repeating) > > > > The exponent is offset by 1023, so this means 1.010101.... divided by > > 2?; the original repeating value is exactly equal to 4/3, so this is > > correct, but as soon as it's squeezed into a finite-sized mantissa, it > > gets rounded - in this case, rounded down. > > > > That's where your result comes from. It's been rounded such that it > > fits inside IEEE 754, and then converted back to a fraction > > afterwards. You're never going to get an exact result for anything > > with a denominator that isn't a power of two. Fortunately, Python does > > offer a solution: store your number as a pair of integers, rather than > > as a packed floating point value, and all calculations truly will be > > exact (at the cost of performance): > > > > >>> one_third = fractions.Fraction(1, 3) > > >>> one_eighth = fractions.Fraction(1, 8) > > >>> one_third + one_eighth > > Fraction(11, 24) > > > > This is possibly more what you want to work with. > > > > ChrisA > > > > > > ------------------------------ > > > > Message: 2 > > Date: Sun, 31 May 2015 23:14:06 -0400 > > From: random832(a)fastmail.us > > To: python-ideas(a)python.org > > Subject: Re: [Python-ideas] Python Float Update > > Message-ID: > > <1433128446.31560.283106753.6D60F98F(a)webmail.messagingengine.com > > > > Content-Type: text/plain > > > > On Sun, May 31, 2015, at 22:25, u8y7541 The Awesome Person wrote: > > > First, I propose that a float's integer ratio should be accurate. For > > > example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it > > > returns(6004799503160661, 18014398509481984). > > > > Even though he's mistaken about the core premise, I do think there's a > > kernel of a good idea here - it would be nice to have a method (maybe > > as_integer_ratio, maybe with some parameter added, maybe a different > > method) to return with the smallest denominator that would result in > > exactly the original float if divided out, rather than merely the > > smallest power of two. > > > > > > ------------------------------ > > > > Message: 3 > > Date: Mon, 01 Jun 2015 03:21:36 +0000 > > From: Jim Witschey <jim.witschey(a)gmail.com> > > To: Chris Angelico <rosuav(a)gmail.com> > > Cc: python-ideas <python-ideas(a)python.org> > > Subject: Re: [Python-ideas] Python Float Update > > Message-ID: > > <CAF+a8-q6kbOwcWk3F47+9PXf2vKgM9ao1uh5=qBw10jqzTC= > > kg(a)mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Teachable moments about the implementation of floating-point aside, > > something in this neighborhood has been considered and rejected before, > in > > PEP 240. However, that was in 2001 - it was apparently created the same > day > > as PEP 237, which introduced transparent conversion of machine ints to > > bignums in the int type. > > > > I think hiding hardware number implementations has been a success for > > integers - it's a far superior API. It could be for rationals as well. > > > > Has something like this thread's original proposal - interpeting > > decimal-number literals as fractional values and using fractions as the > > result of integer arithmetic - been seriously discussed more recently > than > > PEP 240? If so, why haven't they been implemented? Perhaps enough has > > changed that it's worth reconsidering. > > > > > > On Sun, May 31, 2015 at 22:49 Chris Angelico <rosuav(a)gmail.com> wrote: > > > > > On Mon, Jun 1, 2015 at 12:25 PM, u8y7541 The Awesome Person > > > <surya.subbarao1(a)gmail.com> wrote: > > > > > > > > I will be presenting a modification to the float class, which will > > > improve its speed and accuracy (reduce floating point errors). This is > > > applicable because Python uses a numerator and denominator rather than > a > > > sign and mantissa to represent floats. > > > > > > > > First, I propose that a float's integer ratio should be accurate. For > > > example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it > > > returns(6004799503160661, 18014398509481984). > > > > > > > > > > I think you're misunderstanding the as_integer_ratio method. That > > > isn't how Python works internally; that's a service provided for > > > parsing out float internals into something more readable. What you > > > _actually_ are working with is IEEE 754 binary64. (Caveat: I have no > > > idea what Python-the-language stipulates, nor what other Python > > > implementations use, but that's what CPython uses, and you did your > > > initial experiments with CPython. None of this discussion applies *at > > > all* if a Python implementation doesn't use IEEE 754.) So internally, > > > 1/3 is stored as: > > > > > > 0 <-- sign bit (positive) > > > 01111111101 <-- exponent (1021) > > > 0101010101010101010101010101010101010101010101010101 <-- mantissa (52 > > > bits, repeating) > > > > > > The exponent is offset by 1023, so this means 1.010101.... divided by > > > 2?; the original repeating value is exactly equal to 4/3, so this is > > > correct, but as soon as it's squeezed into a finite-sized mantissa, it > > > gets rounded - in this case, rounded down. > > > > > > That's where your result comes from. It's been rounded such that it > > > fits inside IEEE 754, and then converted back to a fraction > > > afterwards. You're never going to get an exact result for anything > > > with a denominator that isn't a power of two. Fortunately, Python does > > > offer a solution: store your number as a pair of integers, rather than > > > as a packed floating point value, and all calculations truly will be > > > exact (at the cost of performance): > > > > > > >>> one_third = fractions.Fraction(1, 3) > > > >>> one_eighth = fractions.Fraction(1, 8) > > > >>> one_third + one_eighth > > > Fraction(11, 24) > > > > > > This is possibly more what you want to work with. > > > > > > ChrisA > > > _______________________________________________ > > > Python-ideas mailing list > > > Python-ideas(a)python.org > > > https://mail.python.org/mailman/listinfo/python-ideas > > > Code of Conduct: http://python.org/psf/codeofconduct/ > >

1 0

Why decode()/encode() name is harmful
by anatoly techtonik 01 Jun '15

01 Jun '15

First, let me start with The Curse of Knowledge https://en.wikipedia.org/wiki/Curse_of_knowledge which can be summarized as: "Once you get something, it becomes hard to think how it was to be without it". I assume that all of you know difference between decode() and encode(), so you're cursed and therefore think that getting that right it is just a matter of reading documentation, experience and time. But quite a lot of had passed and Python 2 is still there, and Python 3, which is all unicode at the core (and which is great for people who finally get it) is not as popular. So, remember that you are biased towards (or against) decode/unicode perception. Now imaging a person who has a text file. The person need to process that with Python. That person is probably a journalist and doesn't know anything that "any developer should know about unicode". In Python 2 he just copy pastes regular expressions to match the letter and is happy. In Python 3 he needs to *convert* that text to unicode. Then he tries to read the documentation, it already starts to bring conflict to his mind. It says to him to "decode" the text. I don't know about you, but when I'm being told to decode the text, I assume that it is crypted, because I watched a few spy movies including ones with Sherlock Holmes and Stierlitz. But the text looks legit to me, I can clearly see and read it and now you say that I need to decode it. You're basically ruining my world right here. No wonder that I will resist. I probably stressed, has a lot of stuff to do, and you are trying to load me with all those abstract concepts that conflict with what I know. No way! Unless I have a really strong motivation (or scientific background) there is no chance to get this stuff for me right on this day. I will probably repeat the exercise and after a few tries will get the output right, but there is no chance I will remember this thing on that day. Because rewiring neural paths in my brain is much harder that paving them from scratch. -- anatoly t.

7 8

Re: [Python-ideas] Python-ideas Digest, Vol 103, Issue 2
by u8y7541 The Awesome Person 01 Jun '15

01 Jun '15

Floats internally use numerator and denominator (float.as_integer_ratio().) It makes no sense to have sign and mantissa while displaying numerator and denominator. Perhaps a redo of the class? I believe fractions should be the standard, and just keep the ieee754 floats as a side option. On Sun, May 31, 2015 at 7:37 PM, <python-ideas-request(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)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(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)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. Python Float Update (u8y7541 The Awesome Person) > 2. Re: Python Float Update (Nathaniel Smith) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 31 May 2015 19:25:46 -0700 > From: u8y7541 The Awesome Person <surya.subbarao1(a)gmail.com> > To: python-ideas(a)python.org > Subject: [Python-ideas] Python Float Update > Message-ID: > < > CA+o1fZONRG_dZzct_VZwcUvtwD-5rJ6zOFxNR34jWFrpUXiw9Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Python Developers: > > I will be presenting a modification to the float class, which will improve > its speed and accuracy (reduce floating point errors). This is applicable > because Python uses a numerator and denominator rather than a sign and > mantissa to represent floats. > > First, I propose that a float's integer ratio should be accurate. For > example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it > returns(6004799503160661, 18014398509481984). > > Second of all, even though 1 * 3 = 3 (last example), 6004799503160661 * 3 > does not equal 18014398509481984. Instead, it equals 1801439850948198**3**, > one less than the value in the ratio. This means the ratio is inaccurate, > as well as completely not simplified. > > > [image: Inline image 1] > > > Even if the value displayed for a float is a rounded value, the internal > numerator and denominator should divide to equal to completely accurate > value. > > Thanks for considering this improvement! > > Sincerely, > u8y7541 >

2 1

Re: [Python-ideas] Python-ideas Digest, Vol 103, Issue 3
by u8y7541 The Awesome Person 01 Jun '15

01 Jun '15

Maybe we could make a C implementation of the Fraction module? That would be nice. On Sun, May 31, 2015 at 8:28 PM, <python-ideas-request(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)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(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)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 (Chris Angelico) > 2. Re: Python Float Update (random832(a)fastmail.us) > 3. Re: Python Float Update (Jim Witschey) > 4. Re: Python Float Update (David Mertz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 1 Jun 2015 12:48:12 +1000 > From: Chris Angelico <rosuav(a)gmail.com> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Python Float Update > Message-ID: > <CAPTjJmr=LurRUoKH3KVVYpMFc= > W5h6etG5TscV5uU6zWhxVbgQ(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Mon, Jun 1, 2015 at 12:25 PM, u8y7541 The Awesome Person > <surya.subbarao1(a)gmail.com> wrote: > > > > I will be presenting a modification to the float class, which will > improve its speed and accuracy (reduce floating point errors). This is > applicable because Python uses a numerator and denominator rather than a > sign and mantissa to represent floats. > > > > First, I propose that a float's integer ratio should be accurate. For > example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it > returns(6004799503160661, 18014398509481984). > > > > I think you're misunderstanding the as_integer_ratio method. That > isn't how Python works internally; that's a service provided for > parsing out float internals into something more readable. What you > _actually_ are working with is IEEE 754 binary64. (Caveat: I have no > idea what Python-the-language stipulates, nor what other Python > implementations use, but that's what CPython uses, and you did your > initial experiments with CPython. None of this discussion applies *at > all* if a Python implementation doesn't use IEEE 754.) So internally, > 1/3 is stored as: > > 0 <-- sign bit (positive) > 01111111101 <-- exponent (1021) > 0101010101010101010101010101010101010101010101010101 <-- mantissa (52 > bits, repeating) > > The exponent is offset by 1023, so this means 1.010101.... divided by > 2?; the original repeating value is exactly equal to 4/3, so this is > correct, but as soon as it's squeezed into a finite-sized mantissa, it > gets rounded - in this case, rounded down. > > That's where your result comes from. It's been rounded such that it > fits inside IEEE 754, and then converted back to a fraction > afterwards. You're never going to get an exact result for anything > with a denominator that isn't a power of two. Fortunately, Python does > offer a solution: store your number as a pair of integers, rather than > as a packed floating point value, and all calculations truly will be > exact (at the cost of performance): > > >>> one_third = fractions.Fraction(1, 3) > >>> one_eighth = fractions.Fraction(1, 8) > >>> one_third + one_eighth > Fraction(11, 24) > > This is possibly more what you want to work with. > > ChrisA > > > ------------------------------ > > Message: 2 > Date: Sun, 31 May 2015 23:14:06 -0400 > From: random832(a)fastmail.us > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] Python Float Update > Message-ID: > <1433128446.31560.283106753.6D60F98F(a)webmail.messagingengine.com> > Content-Type: text/plain > > On Sun, May 31, 2015, at 22:25, u8y7541 The Awesome Person wrote: > > First, I propose that a float's integer ratio should be accurate. For > > example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it > > returns(6004799503160661, 18014398509481984). > > Even though he's mistaken about the core premise, I do think there's a > kernel of a good idea here - it would be nice to have a method (maybe > as_integer_ratio, maybe with some parameter added, maybe a different > method) to return with the smallest denominator that would result in > exactly the original float if divided out, rather than merely the > smallest power of two. > > > ------------------------------ > > Message: 3 > Date: Mon, 01 Jun 2015 03:21:36 +0000 > From: Jim Witschey <jim.witschey(a)gmail.com> > To: Chris Angelico <rosuav(a)gmail.com> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Python Float Update > Message-ID: > <CAF+a8-q6kbOwcWk3F47+9PXf2vKgM9ao1uh5=qBw10jqzTC= > kg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Teachable moments about the implementation of floating-point aside, > something in this neighborhood has been considered and rejected before, in > PEP 240. However, that was in 2001 - it was apparently created the same day > as PEP 237, which introduced transparent conversion of machine ints to > bignums in the int type. > > I think hiding hardware number implementations has been a success for > integers - it's a far superior API. It could be for rationals as well. > > Has something like this thread's original proposal - interpeting > decimal-number literals as fractional values and using fractions as the > result of integer arithmetic - been seriously discussed more recently than > PEP 240? If so, why haven't they been implemented? Perhaps enough has > changed that it's worth reconsidering. > > > On Sun, May 31, 2015 at 22:49 Chris Angelico <rosuav(a)gmail.com> wrote: > > > On Mon, Jun 1, 2015 at 12:25 PM, u8y7541 The Awesome Person > > <surya.subbarao1(a)gmail.com> wrote: > > > > > > I will be presenting a modification to the float class, which will > > improve its speed and accuracy (reduce floating point errors). This is > > applicable because Python uses a numerator and denominator rather than a > > sign and mantissa to represent floats. > > > > > > First, I propose that a float's integer ratio should be accurate. For > > example, (1 / 3).as_integer_ratio() should return (1, 3). Instead, it > > returns(6004799503160661, 18014398509481984). > > > > > > > I think you're misunderstanding the as_integer_ratio method. That > > isn't how Python works internally; that's a service provided for > > parsing out float internals into something more readable. What you > > _actually_ are working with is IEEE 754 binary64. (Caveat: I have no > > idea what Python-the-language stipulates, nor what other Python > > implementations use, but that's what CPython uses, and you did your > > initial experiments with CPython. None of this discussion applies *at > > all* if a Python implementation doesn't use IEEE 754.) So internally, > > 1/3 is stored as: > > > > 0 <-- sign bit (positive) > > 01111111101 <-- exponent (1021) > > 0101010101010101010101010101010101010101010101010101 <-- mantissa (52 > > bits, repeating) > > > > The exponent is offset by 1023, so this means 1.010101.... divided by > > 2?; the original repeating value is exactly equal to 4/3, so this is > > correct, but as soon as it's squeezed into a finite-sized mantissa, it > > gets rounded - in this case, rounded down. > > > > That's where your result comes from. It's been rounded such that it > > fits inside IEEE 754, and then converted back to a fraction > > afterwards. You're never going to get an exact result for anything > > with a denominator that isn't a power of two. Fortunately, Python does > > offer a solution: store your number as a pair of integers, rather than > > as a packed floating point value, and all calculations truly will be > > exact (at the cost of performance): > > > > >>> one_third = fractions.Fraction(1, 3) > > >>> one_eighth = fractions.Fraction(1, 8) > > >>> one_third + one_eighth > > Fraction(11, 24) > > > > This is possibly more what you want to work with. > > > > ChrisA > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas(a)python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ >

2 1

npm-style venv-aware launcher
by David Townshend 01 Jun '15

01 Jun '15

Pip and venv have done a lot to improve the accessibility and ease of installing python packages, but I believe there is still a lot of room for improvement. I only realised how cumbersome I find working with python packages when I recently spent a lot of time on a javascript project using npm. A bit of googling and I found several articles discussing pip, venv and npm, and all of them seemed to say the same thing, i.e. pip/venv could learn a lot from npm. My proposal revolves around two issues: 1. Setting up and working with virtual environments can be onerous. Creating one is easy enough, but using them means remembering to run `source activate` every time, which also means remembering which venv is used for which project. Not a major issue, but still and annoyance. 2. Managing lists of required packages is not nearly as easy as in npm since these is no equivalent to `npm install --save ...`. The best that pip offers is `pip freeze`. Howevere, using that is a) an extra step to remember and b) includes all implied dependencies which is not ideal. My proposal is to use a similar model to npm, where each project has a `venvrc` file which lets python-related tools know which environment to use. In order to showcase the sort of funcionality I'm proposing, I've created a basic example on github (https://github.com/aquavitae/pyle). This is currently py3.4 on linux only and very pre-alpha. Once I've added a few more features that I have in mind (e.g. multiple venvs) I'll add it to pypi and if there is sufficient interest I'd be happy to write up a PEP for getting it into the stdlib. Does this seem like the sort of tool that would be useful in the stdlib? Regards David

12 17