Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On Wed, 1 Sep 2021 09:38:30 +1000, Chris Angelico declaimed the following: >Yeah, I have no idea where the "farmers" explanation came from. >Growing up, we had some friends in countrified areas, including a >sheep farmer who showed us a ton of stuff about how shearing worked, >how moronic sheep are, and how farming life actually operates. It's >not uncommon for such people to have two clocks: Government Time and >Sun Time. Like you say, no cow wears a watch! > Not only do the cattle not have timepieces -- but they probably expect to be milked /n/-hours after the prior milking. I think the DST was meant for industrialization -- factories wouldn't have to run expensive artificial lighting for part of the day-shift; there would be more natural light falling in through the south facing windows on the roof of the building. -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On Wed, 1 Sep 2021 11:19:03 +1200, dn via Python-list declaimed the following: >time-zones. (Yes, you did say "CA", but easily 'missed' - by author and >reader alike) Or possibly misread as the Peoples Republic of CALIFORNIA (even if there isn't a "New Brunswick" in the PRCa) Though https://roadsidethoughts.com/nb/lower-california-profile.htm doesn't help in deconfusion -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On Tue, 31 Aug 2021 16:53:14 -0500, 2qdxy4rzwzuui...@potatochowder.com declaimed the following: >On 2021-09-01 at 07:32:43 +1000, >Chris Angelico wrote: >> If we could abolish DST world-wide, life would be far easier. All the >> rest of it would be easy enough to handle. > >Agreed. > Unfortunately, most of the proposals in the US seem to be that /standard time/ would be abolished, and DST would rule year-round. Hence putting the center of the time zone one hour off from solar mean noon; which is what the time zones were originally based upon. -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Trouble propagating logging configuration
"Dieter Maurer" writes:
> Loris Bennett wrote at 2021-9-1 13:48 +0200:
>> ...
>>Yes, but to quote from
>>https://docs.python.org/3.6/howto/logging.html#logging-basic-tutorial:
>>
>> A good convention to use when naming loggers is to use a module-level
>> logger, in each module which uses logging, named as follows:
>>
>>logger = logging.getLogger(__name__)
>>
>> This means that logger names track the package/module hierarchy, and
>> it’s intuitively obvious where events are logged just from the logger
>> name.
>>
>>so in this case the source layout is relevant, isn't it?
>
> Relevant in this case is the package/module hierarchy.
>
> Often the package/module hierarchy follows the source layout
> **BUT** this is not necessarily the case.
>
> In particular, the "start" module of a script is called `__main__`
> indepently of its location.
> Furthermore, so called "namespace packages" consist of
> decentralized (i.e. located at different places in the file system)
> subpackages.
>
> Thus, in general, the connection between pachage/module hierarchy
> and the source layout is loose.
>
>
>>> Furthermore, the place of the configuration (and where in the
>>> code it is activated) is completely irrelevant for the "inheritance".
>>
>>OK, so one issue is that I was getting confused by the *order* in which
>>modules are being called. If I have two modules, 'foo' and 'bar', in
>>the same directory, configure the logging just in 'foo' and then call
>>
>>
>> foo.some_method()
>> bar.some_method()
>>
>>then both methods will be logged. If I do
>>
>> bar.some_method()
>> foo.some_method()
>>
>>then only the method in 'foo' will be logged.
>
> Usually, log configuration is considered a (global) application
> (not a (local) package/module) concern:
> The components (modules) decide what to log at what level
> and global configuration decides what to do with those messages.
>
> Thus, typically, you configure the complete logging in
> your main application module and then start to import modules
> and call their functions.
>
>> ...
>>If I have
>>
>> [loggers]
>> keys=root,main,log_test
>>
>>in my logging configuration and initialise the logging in run.py ...
>
> This logging configuration is obviously not complete (thus, I cannot
> check what happens in your case).
> You may have made errors at other places in your configuration
> which may explain your observations.
>
> At your place, I would look at the `logging` source code
> to find out where you can see (in an interactive Python session)
> which loggers have been created by your configuration and
> how they are configured. For the last part you use "vars(logger)".
Thanks Peter and Dieter for all the help. I have finally figured out
what my problem was. If in a module 'mylibs.mylib' I have
import logging
logger = logging.getLogger(__name__)
and in my main script have
import logger
import logger.config
import mylibs.mylib
logging.config.fileConfig("/home/loris/config")
logger = logging.getLogger(__name__)
then 'logger' in 'mylibs.mylib' is defined before
'logging.config.fileConfig' is called and the logger in the module is
not configured.
If change the order and write
import logger
import logger.config
logging.config.fileConfig("/home/loris/config")
logger = logging.getLogger(__name__)
import mylibs.mylib
then the 'logger' in 'mylibs.mylibs' does get configured properly.
I'm still thinking what implications this has if I want to load a
configuration file via a command-line option.
Cheers,
Loris
--
This signature is currently under construction.
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On 31/08/2021 22:13, Chris Angelico wrote: > But ultimately, it all just means that timezones are too hard for > humans to handle, and we MUST handle them using IANA's database. It is > the only way. Except for the places that don't follow the IANA scheme and/or dynamically change their time settings on a whim. To be complete you need the ability to manually override too. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: on the popularity of loops while and for
Barry writes: >> On 28 Aug 2021, at 22:42, Hope Rouselle wrote: >> >> I'd like get a statistic of how often each loop is used in practice. >> >> I was trying to take a look at the Python's standard libraries --- those >> included in a standard installation of Python 3.9.6, say --- to see >> which loops are more often used among while and for loops. Of course, >> since English use the preposition ``for'' a lot, that makes my life >> harder. Removing comments is easy, but removing strings is harder. So >> I don't know yet what I'll do. >> >> Have you guys ever measured something like that in a casual or serious >> way? I'd love to know. Thank you! > > I am interesting in why you think that choice of while vs. for is > about popularity? Perhaps you think my choice of "popular" had a special judgement about it. Let's define "popular" in the way that I used it. --8<---cut here---start->8--- Definition. We say x is more popular than y if x appears more times relative to y when considered in a sample. Example. For loops are more popular than while loops in a certain sample because they appeared 17 times compared to 5 times the while loop appeared. --8<---cut here---end--->8--- So it's just a numeric comparison. [...] -- https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On 31/08/2021 22:32, Chris Angelico wrote: > If we could abolish DST world-wide, life would be far easier. All the > rest of it would be easy enough to handle. We tried that in the UK for 2 years back in the '70s and very quickly reverted to DST when they realized that the number of fatalities among young children going to school doubled during those two years. Without DST the schools opened in the dark so all the kids had to travel to school in the dark and the number of traffic accidents while crossing roads jumped. In fact during WW2 they increased DST to 2 hours (that was for the farmers!) because it meant that farm labourers would start work at first light, effectively extending the working day. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
on floating-point numbers
Just sharing a case of floating-point numbers. Nothing needed to be
solved or to be figured out. Just bringing up conversation.
(*) An introduction to me
I don't understand floating-point numbers from the inside out, but I do
know how to work with base 2 and scientific notation. So the idea of
expressing a number as
mantissa * base^{power}
is not foreign to me. (If that helps you to perhaps instruct me on
what's going on here.)
(*) A presentation of the behavior
>>> import sys
>>> sys.version
'3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64 bit
(AMD64)]'
>>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>> sum(ls)
39.594
>>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>>> sum(ls)
39.61
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.)
Let me try to reduce the example. It's not so easy. Although I could
display the violation of commutativity by moving just a single number in
the list, I also see that 7.23 commutes with every other number in the
list.
(*) My request
I would like to just get some clarity. I guess I need to translate all
these numbers into base 2 and perform the addition myself to see the
situation coming up?
--
https://mail.python.org/mailman/listinfo/python-list
( AI retail store inventory control.)
Looking for Python package to develop positive inventory control for a chain of stores. Alex kaye -- https://mail.python.org/mailman/listinfo/python-list
Re: on writing a while loop for rolling two dice
dn writes: > On 29/08/2021 08.46, Hope Rouselle wrote: >> Here's my solution: >> >> --8<---cut here---start->8--- >> def how_many_times(): >> x, y = 0, 1 >> c = 0 >> while x != y: >> c = c + 1 >> x, y = roll() >> return c, (x, y) > >> >> Why am I unhappy? I'm wish I could confine x, y to the while loop. The >> introduction of ``x, y = 0, 1'' must feel like a trick to a novice. How >> would you write this? > >> r...@zedat.fu-berlin.de (Stefan Ram) writes: >>> """Rolls two dice until both yield the same value. >>> Returns the number of times the two dice were rolled >>> and the final value yielded.""" >>> roll_count = 0 >>> while True: >>> outcome = roll_two_dice() >>> roll_count += 1 >>> if outcome[ 0 ]== outcome[ 1 ]: break >>> return roll_count, outcome[ 0 ] >> >> You totally convinced me. Thanks. > > On the other hand... > whilst you expressed concern about the apparently disconnected 'set up' > necessary before the loop, this solution adds a "True/Forever" and a > "Break" construct, which some may deem not that much better (if at all) > > The idea of abrogating the while-condition but then adding another > (disconnected) condition to break, seems to hold equal potential for > confusion. or the type of dissatisfaction which motivated the original > question! Pretty well observed! Hats to you. > Looking at that from the inside-out, the loop's contents perform two > functions: the rolling and counting (per Statement of Requirements), but > also a loop-controlling element. Thus the reader's question: "what does > this loop do?" is conflated with "how many times does it do it?". Well put. > Let's go completely off-the-rails, why not use a never-ending range() to > fuel a for-loop 'counter', and within that loop perform the dice-roll(s) > and decide if it is time to 'break'. The range replaces the "True". The > for-loops index or 'counter' will deliver the desired result. > > Neat? No! > Readable? No! > An improvement over the while-True? Definitely not! > Yet, the mechanism is the same AND offers a built-in counter. Hmmm... Yeah. Here's a little context. I came across this by processing a list of exercises. (I'm teaching a course --- you know that by now, I guess.) So the first thing I observed was the equal volume of work dedicated to while loops and for loops --- so I decided to compared which appeared more often in a certain sample of well-written Python code. It turns out the for loop was much more frequent. Students have been reporting too much work in too little time, so I decided to reduce the number of exercises involving while loops. When I began to look at the exercises, to see which ones I'd exclude, I decided to exclude them all --- lol! --- except for one. The one that remained was this one about rolling dice until a satisfying result would appear. (All other ones were totally more naturally written with a for loop.) So if I were to also write this with a for-loop, it'd defeat the purpose of the course's moment. Besides, I don't think a for-loop would improve the readability here. But I thought your protest against the while-True was very well put: while-True is not too readable for a novice. Surely what's readable or more-natural /to someone/ is, well, subjective (yes, by definition). But perhaps we may agree that while rolling dice until a certain success, we want to roll them while something happens or doesn't happen. One of the two. So while-True is a bit of a jump. Therefore, in this case, the easier and more natural option is to say while-x-not-equal-y. But this approach seems to force me into initializing x, y with different values. > Returning to the concern: > > x, y = 0, 1 > c = 0 > > The first line is purely to ensure that the loop executes at least once, > ie the two assigned-values are not 'real'. Hence the disquiet! > > Initiating the counter is unavoidable (@Chris' suggestion notwithstanding). > > However, remember that Python (like decent DBs) has a concept (and an > idiom) of a value to be used when we don't (yet) know what the value > is/should be! Further that Python allows such a value to be used in > comparisons: > None != None > False None == None > True > > Leading to: > > c, x, y = 0, None, None > while ... > > > Which solution reverts to the original loop-contents. which seem more > obvious and thus more readable. (YMMV!) > > Simplicity over 'being clever'... I don't see it. You seem to have found what we seem to agree that it would be the more natural way to write the strategy. But I can't see it. It certainly isn't --8<---cut here---start->8--- def how_many_times_1(): c, x, y = 0, None, None while x != y: c = c + 1 x, y = roll() return c, x, y --8<---cut here---end--->8--- nor --8<---cut here---start->8--- def how_many_times_2(): c, x,
Re: Mutually exclusive options with argparse.
On Wednesday, September 1, 2021 at 11:20:21 PM UTC+8, Lee Congdon wrote:
> Does a mutually exclusive group, as described in "Mutual exclusion" at
> https://docs.python.org/3/library/argparse.html meet your needs?
Thanks for letting me know about this feature. I'll give it a try.
>
> On Wed, Sep 1, 2021 at 9:48 AM hongy...@gmail.com
> wrote:
> > See the following code snippets [1] for implementation of the exclusive
> > options with argparse:
> >
> > def query_builder(args):
> > if args.r and args.s:
> > sys.exit(Term.FAIL + 'Only one of -re and -sql should be set' +
> > Term.ENDC)
> > sum_status = sum(1 for x in [args.failure, args.code != -1] if x)
> > if sum_status > 1:
> > sys.exit(Term.FAIL + ('Only one of --failure and --code has to be
> > set') + Term.ENDC)
> >
> > [1]
> > https://github.com/hongyi-zhao/recent2/blob/5486afbd56a6b06bb149a3ea969fb33d9d8b288f/recent2.py#L391
> >
> >
> > It seems that the above method is awkward, but I'm out of idea to work out
> > more graceful solutions. Any comment/suggestion/enhancement will be highly
> > appreciated.
> >
> > Regards,
> > HY
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
>
>
> --
> +1-202-507-9867, Twitter @lcongdon
--
https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote: > import sys sys.version > '3.8.10 (tags/... > ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77] sum(ls) > 39.594 > ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23] sum(ls) > 39.61 Welcome to the exciting world of roundoff error: Python 3.5.3 (default, Jul 9 2020, 13:00:10) [GCC 6.3.0 20170516] on linux >>> 0.1 + 0.2 + 9.3 == 0.1 + 9.3 + 0.2 False >>> -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
Re: Mutually exclusive options with argparse.
On Thursday, September 2, 2021 at 10:16:09 AM UTC+8, hongy...@gmail.com wrote:
> On Wednesday, September 1, 2021 at 11:20:21 PM UTC+8, Lee Congdon wrote:
> > Does a mutually exclusive group, as described in "Mutual exclusion" at
> > https://docs.python.org/3/library/argparse.html meet your needs?
> Thanks for letting me know about this feature. I'll give it a try.
The exact document URL is located at here [1].
[1] https://docs.python.org/3/library/argparse.html#mutual-exclusion
> >
> > On Wed, Sep 1, 2021 at 9:48 AM hongy...@gmail.com
> > wrote:
> > > See the following code snippets [1] for implementation of the exclusive
> > > options with argparse:
> > >
> > > def query_builder(args):
> > > if args.r and args.s:
> > > sys.exit(Term.FAIL + 'Only one of -re and -sql should be set' +
> > > Term.ENDC)
> > > sum_status = sum(1 for x in [args.failure, args.code != -1] if x)
> > > if sum_status > 1:
> > > sys.exit(Term.FAIL + ('Only one of --failure and --code has to be
> > > set') + Term.ENDC)
> > >
> > > [1]
> > > https://github.com/hongyi-zhao/recent2/blob/5486afbd56a6b06bb149a3ea969fb33d9d8b288f/recent2.py#L391
> > >
> > >
> > > It seems that the above method is awkward, but I'm out of idea to work
> > > out
> > > more graceful solutions. Any comment/suggestion/enhancement will be
> > > highly
> > > appreciated.
> > >
> > > Regards,
> > > HY
> > > --
> > > https://mail.python.org/mailman/listinfo/python-list
> > >
> >
> >
> > --
> > +1-202-507-9867, Twitter @lcongdon
--
https://mail.python.org/mailman/listinfo/python-list
Re: on writing a while loop for rolling two dice
David Raymond writes: >> def how_many_times(): >> x, y = 0, 1 >> c = 0 >> while x != y: >> c = c + 1 >> x, y = roll() >> return c, (x, y) > > Since I haven't seen it used in answers yet, here's another option using our > new walrus operator > > def how_many_times(): > roll_count = 1 > while (rolls := roll())[0] != rolls[1]: > roll_count += 1 > return (roll_count, rolls) That's nice, although it doesn't seem more readable to a novice seeing a while for the first time, seeing a loop for the first time, than that while-True version. In fact, I think the while-True is the clearest so far. But it's always nice to spot a walrus in the wild! (If you're somewhere safe, that is.) -- https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On 31/08/2021 23:31, Chris Angelico wrote:
> Ah, good to know. I think that actually makes a lot of sense; in the
> US, they try to let everyone pretend that the rest of the world
> doesn't exist ("we always change at 2AM"), but in Europe, they try to
> synchronize for the convenience of commerce ("everyone changes at 1AM
> UTC").
There's another gotcha with DST changes. The EU and USA have different
dates on which they change to DST.
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.
That means on some years (when there are 5 weekends) there is a
week when one has changed and the other hasn't. That caused us
a lot of head scratching the first time we encountered it because
our service centres in the US and EU were getting inconsistent
time reporting and some updates showing as having happened in
the future!
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos
--
https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
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.61 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. Christian -- https://mail.python.org/mailman/listinfo/python-list
Re: on the popularity of loops while and for
Chris Angelico writes: > On Sun, Aug 29, 2021 at 7:40 AM Hope Rouselle wrote: >> >> I'd like get a statistic of how often each loop is used in practice. >> >> I was trying to take a look at the Python's standard libraries --- those >> included in a standard installation of Python 3.9.6, say --- to see >> which loops are more often used among while and for loops. Of course, >> since English use the preposition ``for'' a lot, that makes my life >> harder. Removing comments is easy, but removing strings is harder. So >> I don't know yet what I'll do. >> >> Have you guys ever measured something like that in a casual or serious >> way? I'd love to know. Thank you! > > For analysis like this, I recommend using the Abstract Syntax Tree: > > https://docs.python.org/3/library/ast.html > > You can take a Python source file, parse it to the AST, and then walk > that tree to see what it's using. That will avoid any false positives > from the word "for" coming up in the wrong places. Wonderful. Someone here actually posted a nice ``routine'' that does the job marvelously well. I had the impression the poster posted only to solve my request --- impressive and appreciated. -- https://mail.python.org/mailman/listinfo/python-list
Re: urgent
On 31/08/2021 18.02, Barry wrote: The big problem with >>> is that it means a third level quote in email clients. So when people cut-n-paste REPL output it’s formatted badly by email clients. A prompt that avoided that issue would be nice. A little bit of piping fixes that: username@hostname$ cat text username@hostname$ python3 Python 3.5.2 (default, Jan 26 2021, 13:30:48) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys # in the original, this line will be messed up >>> sys.exit(0) # this one, too username@hostname$ sed 's/^>>> /REPL> /' < text username@hostname$ python3 Python 3.5.2 (default, Jan 26 2021, 13:30:48) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. REPL> import sys # in the original, this line will be messed up REPL> sys.exit(0) # this one, too username@hostname$ -- Michael F. Stemper What happens if you play John Cage's "4'33" at a slower tempo? -- https://mail.python.org/mailman/listinfo/python-list
Re: on the popularity of loops while and for
Terry Reedy writes: > On 8/28/2021 9:31 AM, Hope Rouselle wrote: >> I'd like get a statistic of how often each loop is used in practice. > > My guess is that for loops are at least twice as common as while loops. Scanning just the Python 3.9.6's Lib/ directory --- using the ast module and the program someone kindly posted here ---, I found for loop appearing 598% more times than while loops. The ratio was something like that 6.98..., excluding files that due to encoding errors (or whatever) could not be parsed. (I reported these numbers elsewhere in this thread.) >> I was trying to take a look at the Python's standard libraries --- those >> included in a standard installation of Python 3.9.6, say --- to see >> which loops are more often used among while and for loops. Of course, >> since English use the preposition ``for'' a lot, that makes my life >> harder. Removing comments is easy, but removing strings is harder. So >> I don't know yet what I'll do. > > Try something like > > fors = 0 > for file in files: > for line in file: > if re.match(r"/s*for .* in ", line): > fors += 1 > > This excludes comprehensions, which have replaced some for loops. That's nice too. Thanks for the alternative. -- https://mail.python.org/mailman/listinfo/python-list
Re: on writing a while loop for rolling two dice
Chris Angelico writes: > On Mon, Aug 30, 2021 at 11:13 PM David Raymond > wrote: >> >> > def how_many_times(): >> > x, y = 0, 1 >> > c = 0 >> > while x != y: >> > c = c + 1 >> > x, y = roll() >> > return c, (x, y) >> >> Since I haven't seen it used in answers yet, here's another option using our >> new walrus operator >> >> def how_many_times(): >> roll_count = 1 >> while (rolls := roll())[0] != rolls[1]: >> roll_count += 1 >> return (roll_count, rolls) >> > > Since we're creating solutions that use features in completely > unnecessary ways, here's a version that uses collections.Counter: > > def how_many_times(): > return next((count, rolls) for count, rolls in > enumerate(iter(roll, None)) if len(Counter(rolls)) == 1) > > Do I get bonus points for it being a one-liner that doesn't fit in > eighty characters? Lol. You do not. In fact, this should be syntax error :-D --- as I guess it would be if it were a lambda expression? -- https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On Fri, Sep 3, 2021 at 4:18 AM Dennis Lee Bieber wrote: > > On Tue, 31 Aug 2021 16:53:14 -0500, 2qdxy4rzwzuui...@potatochowder.com > declaimed the following: > > >On 2021-09-01 at 07:32:43 +1000, > >Chris Angelico wrote: > >> If we could abolish DST world-wide, life would be far easier. All the > >> rest of it would be easy enough to handle. > > > >Agreed. > > > > Unfortunately, most of the proposals in the US seem to be that > /standard time/ would be abolished, and DST would rule year-round. Hence > putting the center of the time zone one hour off from solar mean noon; > which is what the time zones were originally based upon. > I'd be fine with that, honestly. It's a bit 'off', but it isn't THAT big a deal. If some city in the US decides that it wants its timezone to be a few hours AHEAD of UTC, more power to them, just as long as it's consistent year-round. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
Am 02.09.21 um 15:51 schrieb Hope Rouselle:
Just sharing a case of floating-point numbers. Nothing needed to be
solved or to be figured out. Just bringing up conversation.
(*) An introduction to me
I don't understand floating-point numbers from the inside out, but I do
know how to work with base 2 and scientific notation. So the idea of
expressing a number as
mantissa * base^{power}
is not foreign to me. (If that helps you to perhaps instruct me on
what's going on here.)
(*) A presentation of the behavior
import sys
sys.version
'3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64 bit
(AMD64)]'
ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
sum(ls)
39.594
ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
sum(ls)
39.61
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.)
I believe it is not commutativity, but associativity, that is violated.
Even for floating point, a+b=b+a except for maybe some extreme cases
like denormliazed numbers etc.
But in general (a+b)+c != a+ (b+c)
Consider decimal floating point with 2 digits.
a=1
b=c=0.04
Then you get LHS;
(1 + 0.04) + 0.04 = 1 + 0.04 = 1
RHS:
1 + (0.04 + 0.04) = 1 + 0.08 = 1.1
Your sum is evaluated like (((a + b) + c) + ) and hence, if you
permute the numbers, it can be unequal. If you need better accuracy,
there is the Kahan summation algorithm and other alternatives:
https://en.wikipedia.org/wiki/Kahan_summation_algorithm
Christian
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On Fri, Sep 3, 2021 at 4:22 AM Alan Gauld via Python-list wrote: > > On 31/08/2021 22:13, Chris Angelico wrote: > > > But ultimately, it all just means that timezones are too hard for > > humans to handle, and we MUST handle them using IANA's database. It is > > the only way. > > Except for the places that don't follow the IANA scheme and/or > dynamically change their time settings on a whim. To be complete > you need the ability to manually override too. > What places are those? IANA maintains the database by noticing changes and announcements, and updating the database. I don't think governments need to "opt in" or anything. Stuff happens because people do stuff, and people do stuff because they want to be able to depend on timezone conversions. There ARE times when a government makes a change too quickly to get updates out to everyone, especially those who depend on an OS-provided copy of tzdata, so I agree with the "on a whim" part. Though, fortunately, that's rare. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
Hope Rouselle writes:
> Just sharing a case of floating-point numbers. Nothing needed to be
> solved or to be figured out. Just bringing up conversation.
>
> (*) An introduction to me
>
> I don't understand floating-point numbers from the inside out, but I do
> know how to work with base 2 and scientific notation. So the idea of
> expressing a number as
>
> mantissa * base^{power}
>
> is not foreign to me. (If that helps you to perhaps instruct me on
> what's going on here.)
>
> (*) A presentation of the behavior
>
import sys
sys.version
> '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
> bit (AMD64)]'
>
ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
sum(ls)
> 39.594
>
ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
sum(ls)
> 39.61
>
> 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.)
Suppose these numbers are prices in dollar, never going beyond cents.
Would it be safe to multiply each one of them by 100 and therefore work
with cents only? For instance
--8<---cut here---start->8---
>>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>> sum(map(lambda x: int(x*100), ls)) / 100
39.6
>>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>>> sum(map(lambda x: int(x*100), ls)) / 100
39.6
--8<---cut here---end--->8---
Or multiplication by 100 isn't quite ``safe'' to do with floating-point
numbers either? (It worked in this case.)
I suppose that if I multiply it by a power of two, that would be an
operation that I can be sure will not bring about any precision loss
with floating-point numbers. Do you agree?
--
https://mail.python.org/mailman/listinfo/python-list
Re: on writing a while loop for rolling two dice
On Fri, Sep 3, 2021 at 4:33 AM Hope Rouselle wrote: > Yeah. Here's a little context. I came across this by processing a list > of exercises. (I'm teaching a course --- you know that by now, I > guess.) So the first thing I observed was the equal volume of work > dedicated to while loops and for loops --- so I decided to compared > which appeared more often in a certain sample of well-written Python > code. It turns out the for loop was much more frequent. Students have > been reporting too much work in too little time, so I decided to reduce > the number of exercises involving while loops. When I began to look at > the exercises, to see which ones I'd exclude, I decided to exclude them > all --- lol! --- except for one. The one that remained was this one > about rolling dice until a satisfying result would appear. (All other > ones were totally more naturally written with a for loop.) > > So if I were to also write this with a for-loop, it'd defeat the purpose > of the course's moment. Besides, I don't think a for-loop would improve > the readability here. It's on the cusp. When you ask someone to express the concept of "do this until this happens", obviously that's a while loop; but as soon as you introduce the iteration counter, it becomes less obvious, since "iterate over counting numbers until this happens" is a quite viable way to express this. However, if the students don't know itertools.count(), they'll most likely put in an arbitrary limit (like "for c in range(1)"), which you can call them out for. > But I thought your protest against the while-True was very well put: > while-True is not too readable for a novice. Surely what's readable or > more-natural /to someone/ is, well, subjective (yes, by definition). > But perhaps we may agree that while rolling dice until a certain > success, we want to roll them while something happens or doesn't happen. > One of the two. So while-True is a bit of a jump. Therefore, in this > case, the easier and more natural option is to say while-x-not-equal-y. That may be the case, but in Python, I almost never write "while True". Consider the two while loops in this function: https://github.com/Rosuav/shed/blob/master/autohost_manager.py#L92 Thanks to Python's flexibility and efficient compilation, these loops are as descriptive as those with actual conditions, while still behaving exactly like "while True". (The inner loop, "more pages", looks superficially like it should be a for loop - "for page in pages:" - but the data is coming from successive API calls, so it can't know.) > I don't see it. You seem to have found what we seem to agree that it > would be the more natural way to write the strategy. But I can't see > it. It certainly isn't > > --8<---cut here---start->8--- > def how_many_times_1(): > c, x, y = 0, None, None > while x != y: > c = c + 1 > x, y = roll() > return c, x, y > --8<---cut here---end--->8--- > > nor > > --8<---cut here---start->8--- > def how_many_times_2(): > c, x, y = 0, None, None > while x == y: > c = c + 1 > x, y = dados() > return c, x, y > --8<---cut here---end--->8--- > > What do you have in mind? I couldn't see it. You're overlaying two loops here. One is iterating "c" up from zero, the other is calling a function and testing its results. It's up to you which of these should be considered the more important, and which is a bit of extra work added onto it. With the counter as primary, you get something like this: for c in itertools.count(): x, y = roll() if x == y: return c, x, y With the roll comparison as primary, you get this: c, x, y = 0, 0, 1 while x != y: x, y = roll() c += 1 return c, x, y Reworking the second into a do-while style (Python doesn't have that, so we have to write it manually): c = 0 while "x and y differ": x, y = roll() c += 1 if x == y: break return c, x, y And at this point, it's looking pretty much identical to the for loop version. Ultimately, they're all the same and you can pick and choose elements from each of them. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: Dogelog Runtime, Prolog to the Moon (2021)
More best kept secrets of Prolog: Pattern Matching Everybody loves pattern matching. Languages like Python, release 3.10, even provide it now. There is now a match/case statement in Python. But Prolog users will scratch their head. Will my if-then-else be as fast as a imperative switch jump table lookup? Dogelog runtime has stepped up its game concerning pattern matching. It now provides ECLiPSe Prolog disjunction and if-then-else indexing. Take this example: ?- [user]. foo(X,Y) :- X=baz, Y=2; X=bar -> Y=1. SWI-Prolog leaves a choice point, so no clause indexing used: /* SWI-Prolog 8.3.26 */ ?- foo(baz,Z). Z = 2 ; %%% Spurious Choice Point false. Dogelog doesn't leave a choice point, since it can index the disjunction and if-then-else: /* Dogelog Runtime 0.9.3 */ ?- foo(baz,Z). Z = 2. %%% No Choice Point See also: Preview: Dogelog disjunction and if-then-else indexing. (Jekejeke) https://twitter.com/dogelogch/status/1433446729974796293 Preview: Dogelog disjunction and if-then-else indexing. (Jekejeke) https://www.facebook.com/groups/dogelog -- https://mail.python.org/mailman/listinfo/python-list
Add a method to list the current named logging levels
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle wrote:
>
> Just sharing a case of floating-point numbers. Nothing needed to be
> solved or to be figured out. Just bringing up conversation.
>
> (*) An introduction to me
>
> I don't understand floating-point numbers from the inside out, but I do
> know how to work with base 2 and scientific notation. So the idea of
> expressing a number as
>
> mantissa * base^{power}
>
> is not foreign to me. (If that helps you to perhaps instruct me on
> what's going on here.)
>
> (*) A presentation of the behavior
>
> >>> import sys
> >>> sys.version
> '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64 bit
> (AMD64)]'
>
> >>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
> >>> sum(ls)
> 39.594
>
> >>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
> >>> sum(ls)
> 39.61
>
> 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. What you're seeing here is the results of
intermediate rounding. Try this:
>>> def sum(stuff):
... total = 0
... for thing in stuff:
... total += thing
... print(thing, "-->", total)
... return total
...
>>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>> sum(ls)
7.23 --> 7.23
8.41 --> 15.64
6.15 --> 21.79
2.31 --> 24.098
7.73 --> 31.83
7.77 --> 39.594
39.594
>>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>>> sum(ls)
8.41 --> 8.41
6.15 --> 14.56
2.31 --> 16.87
7.73 --> 24.6
7.77 --> 32.375
7.23 --> 39.61
39.61
>>>
Nearly all floating-point confusion stems from an assumption that the
input values are exact. They usually aren't. Consider:
>>> from fractions import Fraction
>>> for n in ls: print(n, Fraction(*n.as_integer_ratio()))
...
8.41 2367204554136617/281474976710656
6.15 3462142213541069/562949953421312
2.31 5201657569612923/2251799813685248
7.73 2175801569973371/281474976710656
7.77 2187060569041797/281474976710656
7.23 2035064081618043/281474976710656
Those are the ACTUAL values you're adding. Do the same exercise with
the partial sums, and see where the rounding happens. It's probably
happening several times, in fact.
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.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: on writing a while loop for rolling two dice
On Fri, Sep 3, 2021 at 4:51 AM Hope Rouselle wrote: > > Chris Angelico writes: > > > On Mon, Aug 30, 2021 at 11:13 PM David Raymond > > wrote: > >> > >> > def how_many_times(): > >> > x, y = 0, 1 > >> > c = 0 > >> > while x != y: > >> > c = c + 1 > >> > x, y = roll() > >> > return c, (x, y) > >> > >> Since I haven't seen it used in answers yet, here's another option using > >> our new walrus operator > >> > >> def how_many_times(): > >> roll_count = 1 > >> while (rolls := roll())[0] != rolls[1]: > >> roll_count += 1 > >> return (roll_count, rolls) > >> > > > > Since we're creating solutions that use features in completely > > unnecessary ways, here's a version that uses collections.Counter: > > > > def how_many_times(): > > return next((count, rolls) for count, rolls in > > enumerate(iter(roll, None)) if len(Counter(rolls)) == 1) > > > > Do I get bonus points for it being a one-liner that doesn't fit in > > eighty characters? > > Lol. You do not. In fact, this should be syntax error :-D --- as I > guess it would be if it were a lambda expression? It got split across lines when I posted it, but if I did this in a program, I'd make it a single long line. That said, though - Python doesn't mind if you mess up the indentation inside a parenthesized expression. Even broken like this, it WILL work. It just looks even uglier than it does with proper indentation :) BTW, this sort of thing is great as an anti-plagiarism check. If a student ever turns in an abomination like this, you can be extremely confident that it was copied from some programming site/list. Especially since I've used the two-arg version of iter() in there - that's quite a rarity. Hm. My mind is straying to evil things. The two-arg iter can do SO much more than I'm using it for here. By carefully designing the second argument, we could make something that is equal to anything whose two elements are equal, which would then terminate the loop. This... could be a lot worse than it seems. I'll leave it as an exercise for the reader to figure out how to capture the matching elements for return. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On 2021-09-02 08:40, Alan Gauld via Python-list wrote:
On 31/08/2021 23:31, Chris Angelico wrote:
Ah, good to know. I think that actually makes a lot of sense; in the
US, they try to let everyone pretend that the rest of the world
doesn't exist ("we always change at 2AM"), but in Europe, they try to
synchronize for the convenience of commerce ("everyone changes at 1AM
UTC").
There's another gotcha with DST changes. The EU and USA have different
dates on which they change to DST.
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.
That means on some years (when there are 5 weekends) there is a
week when one has changed and the other hasn't. That caused us
a lot of head scratching the first time we encountered it because
our service centres in the US and EU were getting inconsistent
time reporting and some updates showing as having happened in
the future!
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!
--
https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle wrote:
>
> Hope Rouselle writes:
>
> > Just sharing a case of floating-point numbers. Nothing needed to be
> > solved or to be figured out. Just bringing up conversation.
> >
> > (*) An introduction to me
> >
> > I don't understand floating-point numbers from the inside out, but I do
> > know how to work with base 2 and scientific notation. So the idea of
> > expressing a number as
> >
> > mantissa * base^{power}
> >
> > is not foreign to me. (If that helps you to perhaps instruct me on
> > what's going on here.)
> >
> > (*) A presentation of the behavior
> >
> import sys
> sys.version
> > '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
> > bit (AMD64)]'
> >
> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
> sum(ls)
> > 39.594
> >
> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
> sum(ls)
> > 39.61
> >
> > 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.)
>
> Suppose these numbers are prices in dollar, never going beyond cents.
> Would it be safe to multiply each one of them by 100 and therefore work
> with cents only? For instance
Yes and no. It absolutely *is* safe to always work with cents, but to
do that, you have to be consistent: ALWAYS work with cents, never with
floating point dollars.
(Or whatever other unit you choose to use. Most currencies have a
smallest-normally-used-unit, with other currency units (where present)
being whole number multiples of that minimal unit. Only in forex do
you need to concern yourself with fractional cents or fractional yen.)
But multiplying a set of floats by 100 won't necessarily solve your
problem; you may have already fallen victim to the flaw of assuming
that the numbers are represented accurately.
> --8<---cut here---start->8---
> >>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
> >>> sum(map(lambda x: int(x*100), ls)) / 100
> 39.6
>
> >>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
> >>> sum(map(lambda x: int(x*100), ls)) / 100
> 39.6
> --8<---cut here---end--->8---
>
> Or multiplication by 100 isn't quite ``safe'' to do with floating-point
> numbers either? (It worked in this case.)
You're multiplying and then truncating, which risks a round-down
error. Try adding a half onto them first:
int(x * 100 + 0.5)
But that's still not a perfect guarantee. Far safer would be to
consider monetary values to be a different type of value, not just a
raw number. For instance, the value $7.23 could be stored internally
as the integer 723, but you also know that it's a value in USD, not a
simple scalar. It makes perfect sense to add USD+USD, it makes perfect
sense to multiply USD*scalar, but it doesn't make sense to multiply
USD*USD.
> I suppose that if I multiply it by a power of two, that would be an
> operation that I can be sure will not bring about any precision loss
> with floating-point numbers. Do you agree?
Assuming you're nowhere near 2**53, yes, that would be safe. But so
would multiplying by a power of five. The problem isn't precision loss
from the multiplication - the problem is that your input numbers
aren't what you think they are. That number 7.23, for instance, is
really
>>> 7.23.as_integer_ratio()
(2035064081618043, 281474976710656)
... the rational number 2035064081618043 / 281474976710656, which is
very close to 7.23, but not exactly so. (The numerator would have to
be ...8042.88 to be exactly correct.) There is nothing you can do at
this point to regain the precision, although a bit of multiplication
and rounding can cheat it and make it appear as if you did.
Floating point is a very useful approximation to real numbers, but
real numbers aren't the best way to represent financial data. Integers
are.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On 02/09/2021 19:28, Chris Angelico wrote: >> Except for the places that don't follow the IANA scheme and/or >> dynamically change their time settings on a whim. To be complete >> you need the ability to manually override too. >> > > What places are those? Mainly small non-tech oriented places such as small pacific islands or principalities with local governance - such as by a group of tribal elders. I mentioned earlier the example of Andorra announcing on the Friday night before a DST change that they were deferring it for a week to preserve the skiing conditions. But we came across several similar situations in dealing with multi-national service centres. > IANA maintains the database by noticing changes > and announcements, and updating the database. But don;t those have to be electronic in nature? How, for example would it pick up the radio news announcement mentioned above? > governments need to "opt in" or anything. Stuff happens because people > do stuff, and people do stuff because they want to be able to depend > on timezone conversions. Umm, they do DST because it makes their lives easier - more daylight, extra work time. etc. The needs of, or impact on, computers in these kinds of small localities and communities are way down the pecking order. > There ARE times when a government makes a change too quickly to get > updates out to everyone, especially those who depend on an OS-provided > copy of tzdata, so I agree with the "on a whim" part. Though, > fortunately, that's rare. I agree it is very rare and if you only operate in mainstream localities you probably never see it as an issue, it's only when you need to support "off grid" locations that manual control becomes important. Also the problems we had were about 15 years ago, things may be better ordered nowadays. (I've been retired for 7 years so can't speak of more recent events) -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On Fri, Sep 3, 2021 at 4:26 AM Alan Gauld via Python-list wrote: > > On 31/08/2021 22:32, Chris Angelico wrote: > > > If we could abolish DST world-wide, life would be far easier. All the > > rest of it would be easy enough to handle. > We tried that in the UK for 2 years back in the '70s and very > quickly reverted to DST when they realized that the number > of fatalities among young children going to school doubled > during those two years. > > Without DST the schools opened in the dark so all the kids > had to travel to school in the dark and the number of > traffic accidents while crossing roads jumped. How do they manage in winter? Can that be solved with better street lighting? That was fifty years ago now, and the negative consequences of DST are far stronger now. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On Fri, Sep 3, 2021 at 4:40 AM Alan Gauld via Python-list
wrote:
>
> On 31/08/2021 23:31, Chris Angelico wrote:
>
> > Ah, good to know. I think that actually makes a lot of sense; in the
> > US, they try to let everyone pretend that the rest of the world
> > doesn't exist ("we always change at 2AM"), but in Europe, they try to
> > synchronize for the convenience of commerce ("everyone changes at 1AM
> > UTC").
>
> There's another gotcha with DST changes. The EU and USA have different
> dates on which they change to DST.
>
> 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.
>
> That means on some years (when there are 5 weekends) there is a
> week when one has changed and the other hasn't. That caused us
> a lot of head scratching the first time we encountered it because
> our service centres in the US and EU were getting inconsistent
> time reporting and some updates showing as having happened in
> the future!
>
I live in Australia. You folks all change in *the wrong direction*.
Twice a year, there's a roughly two-month period that I call "DST
season", when different countries (or groups of countries) switch DST.
It is a nightmare to schedule anything during that time.
The ONLY way is to let the computer handle it. Don't try to predict
ANYTHING about DST manually.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
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... -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle declaimed the following: ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77] sum(ls) >39.594 > ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23] sum(ls) >39.61 > >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.) > https://www.amazon.com/Real-Computing-Made-Engineering-Calculations-dp-B01K0Q03AA/dp/B01K0Q03AA/ref=mt_other?_encoding=UTF8&me=&qid= -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
On 2021-09-02, Hope Rouselle wrote: > Suppose these numbers are prices in dollar, never going beyond cents. > Would it be safe to multiply each one of them by 100 and therefore work > with cents only? The _practical_ answer is that no, it's not safe to use floating point when doing normal bookeeping type stuff with money. At least not if you want everything to balance correctly at the end of the day (week, month, quarter, year or etc.). Use integer cents, or mills or whatever. If you have to use floating point to calculate a payment or credit/debit amount, always round or truncate the result back to an integer value in your chosen units before actually using that amount for anything. In theory, decimal floating point should be usable, but I've never personally worked with it. Back in the day (1980's) microcomputers didn't have floating point hardware, and many compilers allowed you to choose between base-2 floating point and base-10 (BCD) floating point. The idea was that if you were doing financial stuff, you could use BCD floating point. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
On Thu, 02 Sep 2021 12:08:21 -0300, Hope Rouselle declaimed the following: >Suppose these numbers are prices in dollar, never going beyond cents. >Would it be safe to multiply each one of them by 100 and therefore work >with cents only? For instance > A lot of software with a "monetary" data type uses scaled INTEGERS for that... M$ Excel uses four decimal places, internally scaled. The Ada language has both FIXED and FLOAT data types; for FIXED one specifies the delta between adjacent values that must be met (the compiler is free to use something with more resolution internally). Money should never be treated as a floating value. >I suppose that if I multiply it by a power of two, that would be an >operation that I can be sure will not bring about any precision loss >with floating-point numbers. Do you agree? Are we talking IEEE floats? Or some of the ancient formats used for computers that may not have had hardware floating point units, or predate the IEEE standard. Normalized with suppressed leading bit? (If normalization always puts the most significant bit at the binary point... Why store that bit?, shift it out and gain another bit at the small end) Xerox Sigma floats used an exponent based on radix 16. A normalized mantissa could have up to three leading 0 bits. Motorola Fast Floating Point (software float implementation used on base Amiga systems -- the exponent was in the low byte) -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico 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). -- Wulfraed Dennis Lee Bieber AF6VN wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Request for argmax(list) and argmin(list)
How about this?: python3 -c 'list_ = [1, 3, 5, 4, 2]; am = max((value, index) for index, value in enumerate(list_)); print(am)' On Wed, Sep 1, 2021 at 6:51 AM ABCCDE921 wrote: > Because that does 2 passes over the entire array when you only need one > and there is no option to specify if you want the leftmost or rightmost > element > > > On Wednesday, September 1, 2021 at 12:02:29 PM UTC+5:30, Paul Bryan wrote: > > Why not: > > > > >>> l = [1, 3, 5, 9, 2, 7] > > >>> l.index(max(l)) > > 3 > > >>> l.index(min(l)) > > 0 > > On Tue, 2021-08-31 at 21:25 -0700, ABCCDE921 wrote: > > > I dont want to import numpy > > > > > > argmax(list) > > > returns index of (left most) max element > > > > > > argmin(list) > > > returns index of (left most) min element > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Select columns based on dates - Pandas
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: on writing a while loop for rolling two dice
def how_many_times(): x, y = 0, 1 c = 0 while x != y: c = c + 1 x, y = roll() return c, (x, y) Since I haven't seen it used in answers yet, here's another option using our new walrus operator def how_many_times(): roll_count = 1 while (rolls := roll())[0] != rolls[1]: roll_count += 1 return (roll_count, rolls) I would go even further, saying there is no need to «roll dices»: def how_many_times(): nb_times = random.choice([n for n in range(50) for _ in range(round(1*(1/6)*(5/6)**(n-1)))]) return nb_times, (random.randint(1, 6),) * 2 If i had more time on my hands, i would do something with bissect to get nb_times with more precision, as i have (mis)calculated that the probability of having nb_times = N is N = (1/6) * (5/6) ** (N-1) Something like this may work: nb_times = [random.random() < (1/6) * (5/6) ** (N-1) for N in range(1, 50)].index(True)+1 -- https://mail.python.org/mailman/listinfo/python-list
Re: Add a method to list the current named logging levels
Edward Spencer wrote at 2021-9-2 10:02 -0700: >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? Usually, you use 5 well known log levels: "DEBUG", "INFO", "WARNING", "ERROR" and "CRITICAL". No need to provide a special function listing those levels. -- Dieter -- https://mail.python.org/mailman/listinfo/python-list
Scraping of Google Map to get the address of locations for given geocodes.
Dear all, I have the following question regarding how to scrape Google Map to get address based on a given list of geocodes. Given a list of geocodes (latitude; longitude) of locations, I would like to scrape municipalities of all the spots in the list. How can I do that? For example, I have lat lon 1) -34.5722317 -58.4314464 2) -34.553906 -58.4520949 3) -34.5661444 -58.4964289 4) -34.5648053 -58.4431567 5) -34.5664089 -58.4323004 6) -34.5664089 -58.4323004 And I want to get the name of municipality (city/town), or alternatively the address, of each location. I would appreciate it, if anyone can advise me how to do that. Thanks Best regards Michio -- https://mail.python.org/mailman/listinfo/python-list
Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.
On Fri, Sep 3, 2021 at 8:01 AM Alan Gauld via Python-list wrote: > > On 02/09/2021 19:28, Chris Angelico wrote: > > >> Except for the places that don't follow the IANA scheme and/or > >> dynamically change their time settings on a whim. To be complete > >> you need the ability to manually override too. > >> > > > > What places are those? > > Mainly small non-tech oriented places such as small pacific islands > or principalities with local governance - such as by a group of > tribal elders. I mentioned earlier the example of Andorra announcing > on the Friday night before a DST change that they were deferring > it for a week to preserve the skiing conditions. But we came across > several similar situations in dealing with multi-national service centres. > > > IANA maintains the database by noticing changes > > and announcements, and updating the database. > > But don;t those have to be electronic in nature? How, for example > would it pick up the radio news announcement mentioned above? Can't find the specific example of Andorra, but there have been plenty of times when someone's reported a time change to the IANA list and it's resulted in the zonedata being updated. "It" picks up changes by people reporting them, because IANA is, ultimately, a group of people. > > governments need to "opt in" or anything. Stuff happens because people > > do stuff, and people do stuff because they want to be able to depend > > on timezone conversions. > > Umm, they do DST because it makes their lives easier - more daylight, > extra work time. etc. The needs of, or impact on, computers in these > kinds of small localities and communities are way down the pecking order. Yes, and what happens when those changes make other people's lives harder because tzdata is out of date? People change tzdata to be up-to-date. It's not the local government that maintains tzdata. > > There ARE times when a government makes a change too quickly to get > > updates out to everyone, especially those who depend on an OS-provided > > copy of tzdata, so I agree with the "on a whim" part. Though, > > fortunately, that's rare. > > I agree it is very rare and if you only operate in mainstream > localities you probably never see it as an issue, it's only > when you need to support "off grid" locations that manual > control becomes important. Also the problems we had were about > 15 years ago, things may be better ordered nowadays. (I've been > retired for 7 years so can't speak of more recent events) Oh, fifteen years ago. That explains why searching the tz-announce list didn't help - the archive doesn't go back past 2012. The actual tzdata files can be found going all the way back [1] but you'd have to dig through to find the announcement in question. In any case, I'm sure you'll find an update there; if not immediately, then after the event, because tzdata cares a LOT about historical times. For instance, this recent announcement [2] had one change to upcoming times, but a number of corrections to past times. So a manual override is ONLY necessary when (a) tzdata hasn't caught up yet, or (b) tzdata has been updated, but you're using an old version (maybe your OS hasn't caught up yet, and you can't get it from PyPI). ChrisA [1] https://data.iana.org/time-zones/releases/ [2] https://mm.icann.org/pipermail/tz-announce/2020-December/63.html -- https://mail.python.org/mailman/listinfo/python-list
Re: on floating-point numbers
On Fri, Sep 3, 2021 at 8:15 AM Dennis Lee Bieber wrote: > > On Fri, 3 Sep 2021 04:43:02 +1000, Chris Angelico > 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. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Scraping of Google Map to get the address of locations for given geocodes.
On 2021-09-02 at 20:12:19 -0300, Michio Suginoo wrote: > I have the following question regarding how to scrape Google Map to get > address based on a given list of geocodes. > Given a list of geocodes (latitude; longitude) of locations, I would like > to scrape municipalities of all the spots in the list. How can I do that? > > For example, I have > > lat lon > > 1) -34.5722317 -58.4314464 > > 2) -34.553906 -58.4520949 > > 3) -34.5661444 -58.4964289 > > 4) -34.5648053 -58.4431567 > > 5) -34.5664089 -58.4323004 > > 6) -34.5664089 -58.4323004 > > > > And I want to get the name of municipality (city/town), or alternatively > the address, of each location. > > > I would appreciate it, if anyone can advise me how to do that. Is scraping Google Map a hard requirement? Both geopy¹ and geocoder² can translate those coordinates into street addresses directly, and their documentation even explains how to bypass the libraries and go straight to the service providers. ¹ https://geopy.readthedocs.io/en/latest/ ² https://geocoder.readthedocs.io/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Package documentation error
Hi Python Team, I think the statement "The __init__.py files are required to make Python treat directories containing the file as packages" is wrong in the documentation[1] because it is valid only for Python 2.x version not Python 3.x version. Even though it is good practice to have this file, it is not mandatory to have in Python 3x. to treat directories as packages. So I think we should correct it. [1] https://docs.python.org/3/tutorial/modules.html?highlight=packages#packages Thanks, Krishna On Fri, Sep 3, 2021 at 10:13 AM Krishna wrote: > Hi Python Team, > I think the statement "The __init__.py files are required to make Python > treat directories containing the file as packages" is wrong in the > documentation[1] because it is valid only for Python 2.x version not Python > 3.x version. > > Even though it is good practice to have this file, it is not mandatory to > have in Python 3x. to treat directories as packages. So I think we should > correct it. > > [1] > https://docs.python.org/3/tutorial/modules.html?highlight=packages#packages > > Thanks, > Krishna > -- https://mail.python.org/mailman/listinfo/python-list
Connecting python to DB2 database
Having a problem with the DB2 connector test.py import ibm_db_dbi connectstring = 'DATABASE=xxx;HOSTNAME=localhost;PORT=5;PROTOCOL=TCPIP;UID=xxx;PWD=xxx;' conn = ibm_db_dbi.connect(connectstring,'','') curr = conn.cursor print(curr) cSQL = "SELECT * FROM TEST" curr.execute(cSQL) rows = curr.fetchall() print(len(rows)) $python test.py Traceback (most recent call last): File "temp.py", line 9, in curr.execute(cSQL) AttributeError: 'function' object has no attribute 'execute' The ibm_db_dbi library supposedly adheres to PEP 249 (DB-API Spec 2.0), but it ain't happening here. Googling got me nowhere. Any ideas? python 3.8.2 on Windows 10 pip install ibm_db -- https://mail.python.org/mailman/listinfo/python-list
Re: Connecting python to DB2 database
On Fri, Sep 3, 2021 at 3:42 PM DFS wrote: > > Having a problem with the DB2 connector > > test.py > > import ibm_db_dbi > connectstring = > 'DATABASE=xxx;HOSTNAME=localhost;PORT=5;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: 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 -- https://mail.python.org/mailman/listinfo/python-list
