🌐 Mailman 3 September 2021 - Python-list - python.org

How to include insertion order in dict equality
by Terry Reedy Sept. 4, 2021

Sept. 4, 2021

In https://bugs.python.org/issue45093, Michael Rans suggested adding a dict method that would include the insertion order in comparing dicts for equality. He wanted this for testing. The proposal is rejected because there are already multiple good methods. To make them more visible and searchable, I list them here. Steven D'Aprano: d1 == d2 and all(k1 == k2 for k1, k2 in zip(d1, d2)) Sethiy Storchaka: list(d1.items()) == list(d2.items()) # When using unittest, produces nicer report on failure. Raymond Hettinger: assert OrderedDict(d) == OrderedDict(e) -- Terry Jan Reedy

1 0

Re: on floating-point numbers
by Christian Gollwitzer Sept. 4, 2021

Sept. 4, 2021

Am 02.09.21 um 21:02 schrieb Julio Di Egidio: > On Thursday, 2 September 2021 at 20:43:36 UTC+2, Chris Angelico wrote: >> On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle <hrou...(a)jevedi.com> wrote: > >>> All I did was to take the first number, 7.23, and move it to the last >>> position in the list. (So we have a violation of the commutativity of >>> addition.) >>> >> It's not about the commutativity of any particular pair of operands - >> that's always guaranteed. > > Nope, that is rather *not* guaranteed, as I have quite explained up thread. > No, you haven't explained that. You linked to the famous Goldberg paper. Where in the paper does it say that operations on floats are not commutative? I'd be surprised because it is generally wrong. Unless you have special numbers like NaN or signed zeros etc., a+b=b+a and a*b=b*a holds also for floats. Christiah

2 1

Re: The sqlite3 timestamp conversion between unixepoch and localtime
by Bob Martin Sept. 3, 2021

Sept. 3, 2021

On 2 Sep 2021 at 20:25:27, Alan Gauld <alan.gauld(a)yahoo.co.uk> wrote: > On 02/09/2021 20:11, MRAB wrote: > >>> In one of them (I can't recall which is which) they change on the 4th >>> weekend of October/March in the other they change on the last weekend. >>> >>> >> In the EU (and UK) it's the last Sunday in March/October. >> >> In the US it's second Sunday in March and the first Sunday in November. >> >> I know which one I find easier to remember! > > Interesting. I remember it as closer than that. The bugs we found were > due to differences in the DST settings of the BIOS in the PCs. (They > were deliberately all sourced from DELL but the EU PCs had a slightly > different BIOS). > > The differences you cite should have thrown up issues every year. > I must see if I can find my old log books... > ISTR that the USA changes were the same as the EU until a few years ago. I remember thinking at the time it changed "why would they do that?"

3 2

Re: on floating-point numbers
by jak Sept. 3, 2021

Sept. 3, 2021

Il 03/09/2021 14:45, Chris Angelico ha scritto: > I believe the definition of "accurate" here is that, if you take all > of the real numbers represented by those floats, add them all together > with mathematical accuracy, and then take the nearest representable > float, that will be the exact value that fsum will return. In other > words, its accuracy is exactly as good as the final result can be. yup, I agree and this is the because of the link.

1 0

CPython / Decimal and bit length of value.
by Nacnud Nac Sept. 3, 2021

Sept. 3, 2021

Hi, Is there a quick way to get the number of bits required to store the value in a Decimal class? What obvious thing am I missing? I'm working with really large integers, say, in the order of 5_000_000 of ASCII base 10 digits. It seems the function mpd_sizeinbase would be a nice thing to be able to call..... It'd be nice to just be able to tell the "size of data", or something like that, that was stored in the *data? I note there is len "field" in the structure mpd_t Sorry for the dumb question.... Thanks,Duncan

1 0

Add a method to list the current named logging levels
by Edward Spencer Sept. 3, 2021

Sept. 3, 2021

Sometimes I like to pass the logging level up to the command line params so my user can specific what level of logging they want. However there is no easy method for pulling the named logging level names. Looking into the code, it would actually be incredibly easy to implement; in `logging.__init__.py`; def listLevelNames(): return _nameToLevel.keys() You could obviously add some other features, like listing only the defaults, sorted by numerical level or alphabetically, etc. But really this basic implementation would be enough to expose the internal variables which shouldn't be accessed because they change (and in fact, between python 2 and 3, they did). Any thoughts? Thanks, Ed Spencer

3 2

Select columns based on dates - Pandas
by Richard Medina Sept. 3, 2021

Sept. 3, 2021

Hello, forum, I have a data frame with covid-19 cases per month from 2019 - 2021 like a header like this: Country, 01/01/2019, 2/01/2019, 01/02/2019, 3/01/2019, ... 01/01/2021, 2/01/2021, 01/02/2021, 3/01/2021 I want to filter my data frame for columns of a specific month range of march to September of 2019, 2020, and 2021 only (three data frames). Any ideas? Thank you

2 1

Re: Connecting python to DB2 database
by DFS Sept. 3, 2021

Sept. 3, 2021

On 9/3/2021 1:47 AM, Chris Angelico wrote: > On Fri, Sep 3, 2021 at 3:42 PM DFS <nospam(a)dfs.com> wrote: >> >> Having a problem with the DB2 connector >> >> test.py >> ---------------------------------------------------------------- >> import ibm_db_dbi >> connectstring = >> 'DATABASE=xxx;HOSTNAME=localhost;PORT=50000;PROTOCOL=TCPIP;UID=xxx;PWD=xxx;' >> conn = ibm_db_dbi.connect(connectstring,'','') >> >> curr = conn.cursor >> print(curr) > > According to PEP 249, what you want is conn.cursor() not conn.cursor. > > I'm a bit surprised as to the repr of that function though, which > seems to be this line from your output: > > <ibm_db_dbi.Connection object at 0x000002154D2FED30> > > I'd have expected it to say something like "method cursor of > Connection object", which would have been an immediate clue as to what > needs to be done. Not sure why the repr is so confusing, and that > might be something to report upstream. > > ChrisA Thanks. I must've done it right, using conn.cursor(), 500x. Bleary-eyed from staring at code too long I guess. Now can you get DB2 to accept ; as a SQL statement terminator like the rest of the world? They call it "An unexpected token"...

3 2

Re: on floating-point numbers
by Peter Pearson Sept. 3, 2021

Sept. 3, 2021

On Thu, 2 Sep 2021 07:54:27 -0700 (PDT), Julio Di Egidio wrote: > On Thursday, 2 September 2021 at 16:51:24 UTC+2, Christian Gollwitzer wrote: >> Am 02.09.21 um 16:49 schrieb Julio Di Egidio: >> > On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote: >> >> On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote: >> > >> >>> 39.60000000000001 >> >> >> >> Welcome to the exciting world of roundoff error: >> > >> > Welcome to the exiting world of Usenet. >> > >> > *Plonk* >> >> Pretty harsh, isn't it? He gave a concise example of the same inaccuracy >> right afterwards. > > And I thought you were not seeing my posts... > > Given that I have already given a full explanation, you guys, that you > realise it or not, are simply adding noise for the usual pub-level > discussion I must most charitably guess. > > Anyway, just my opinion. (EOD.) Although we are in the world of Usenet, comp.lang.python is by no means typical of Usenet. This is a positive, helpful, welcoming community in which "Plonk", "EOD", and "RTFM" (appearing in another post) are seldom seen, and in which I have never before seen the suggestion that everybody else should be silent so that the silver voice of the chosen one can be heard. -- To email me, substitute nowhere->runbox, invalid->com.

1 0

Re: on floating-point numbers
by jak Sept. 3, 2021

Sept. 3, 2021

Il 03/09/2021 09:07, Julio Di Egidio ha scritto: > On Friday, 3 September 2021 at 01:22:28 UTC+2, Chris Angelico wrote: >> On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber <wlf...(a)ix.netcom.com> wrote: >>> On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico <ros...(a)gmail.com> >>> declaimed the following: >>> >>>> The naive summation algorithm used by sum() is compatible with a >>>> variety of different data types - even lists, although it's documented >>>> as being intended for numbers - but if you know for sure that you're >>>> working with floats, there's a more accurate algorithm available to >>>> you. >>>> >>>>>>> math.fsum([7.23, 8.41, 6.15, 2.31, 7.73, 7.77]) >>>> 39.6 >>>>>>> math.fsum([8.41, 6.15, 2.31, 7.73, 7.77, 7.23]) >>>> 39.6 >>>> >>>> It seeks to minimize loss to repeated rounding and is, I believe, >>>> independent of data order. >>> >>> Most likely it sorts the data so the smallest values get summed first, >>> and works its way up to the larger values. That way it minimizes the losses >>> that occur when denormalizing a value (to set the exponent equal to that of >>> the next larger value). >>> >> I'm not sure, but that sounds familiar. It doesn't really matter >> though - the docs just say that it is an "accurate floating point >> sum", so the precise algorithm is an implementation detail. > > The docs are quite misleading there, it is not accurate without further qualifications. > > <https://docs.python.org/3.8/library/math.html#math.fsum> > <https://code.activestate.com/recipes/393090/> > > That said, fucking pathetic, when Dunning-Kruger is a compliment... > > *Plonk* > > Julio > https://en.wikipedia.org/wiki/IEEE_754

3 2