[Python-Dev] Re: os.scandir bug in Windows?

2020-10-17 Thread Tal Einat
Interesting! Indeed, please create an issue and post a link here. >From a quick look at the code, I can't see any obvious bugs here, the info seems to be coming directly from FindNextFileW. This will likely require some more digging. On Sun, Oct 18, 2020 at 7:37 AM Gregory P. Smith wrote: > Co

[Python-Dev] Re: os.scandir bug in Windows?

2020-10-17 Thread Gregory P. Smith
Could you please file this as an issue on bugs.python.org? Thanks! -Greg On Sat, Oct 17, 2020 at 7:25 PM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > > TLDR: In os.scandir directory entries, atime is always a copy of mtime > rather than the actual access time. > > Demo program: W

[Python-Dev] os.scandir bug in Windows?

2020-10-17 Thread Rob Cliffe via Python-Dev
TLDR: In os.scandir directory entries, atime is always a copy of mtime rather than the actual access time. Demo program: Windows 10, Python 3.8.3: # osscandirtest.py import time, os with open('Test', 'w') as f: f.write('Anything\n') # Write to a file time.sleep(10) with open('Test', 'r') as f

[Python-Dev] Re: Changing Python's string search algorithms

2020-10-17 Thread Tim Peters
[Tim] > ... > Alas, the higher preprocessing costs leave the current PR slower in "too > many" cases too, especially when the needle is short and found early > in the haystack. Then any preprocessing cost approaches a pure waste > of time. But that was this morning. Since then, Dennis changed the

[Python-Dev] Re: Modified parser does not seem to work. What am I doing wrong?

2020-10-17 Thread Stefano Borini
That's what I suspected looking at the parser debug in fact. Good to see that I was on the right track. Thanks! I'll play with it a bit more tonight. On Fri, 16 Oct 2020 at 23:43, Pablo Galindo Salgado wrote: > > Hi Stefano, > > One of the problems you have is that the rule for slices has a negat

[Python-Dev] Re: Changing Python's string search algorithms

2020-10-17 Thread Tim Peters
[Tim] >> Note that no "extra" storage is needed to exploit this. No character >> lookups, no extra expenses in time or space of any kind. Just "if we >> mismatch on the k'th try, we can jump ahead k positions". [Antoine Pitrou ] > Ok, so that means that on a N-character haystack, it'll always do

[Python-Dev] Re: Changing Python's string search algorithms

2020-10-17 Thread Antoine Pitrou
On Fri, 16 Oct 2020 20:24:22 -0500 Tim Peters wrote: > > Note that no "extra" storage is needed to exploit this. No character > lookups, no extra expenses in time or space of any kind. Just "if we > mismatch on the k'th try, we can jump ahead k positions". Ok, so that means that on a N-characte