[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Steve Dower added the comment: Those are all good ideas, but using os.stat(d) instead of d.stat() is shorter, more reliable, more compatible, and already works. There's no middle ground where DirEntry can be faster, because it's already using that middle ground. All the discussion between

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Cezary Wagner added the comment: I think we can assume that NTFS is priority since that is the most used option. I can not discuss what with FAT32 or FAT since I am not the best in this domain (in NTFS I am not the best too now). Whatever I think that system must do allocation for open

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Steve Dower added the comment: > We're faced with the choice between either always calling the real lstat, or > just documenting that files with hard links will have stale information if > the file was updated using another link. That's an easy choice: we document it. The os module comes

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Eryk Sun added the comment: > What it also means is that the "file still in use by another app" > scenario will probably have to manually use os.stat(). We can't > detect it, and it's the same race condition as calling os.stat() > shortly before the update flushes anyway. FAT filesystems

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Steve Dower added the comment: Okay, so it sounds like there's a class of files where we can't rely on the FindFileData having the right values. But we get enough information to be able just suppress the caching behaviour for those, right? Basically, my criteria for fixing this in the

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Eryk Sun added the comment: > Does it make the most sense for us to make .flush() also do an > implicit .fsync() (when it's actually a file object)? Standard I/O in the Windows C runtime supports a "c" commit mode that causes fflush to call _commit() on the underlying fd [1]. Perhaps Python

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Cezary Wagner added the comment: I read some comments os.flush() or os.fsync() can be unrelated to problem. External application can be written in C# or whatever you want. Under Windows (not Linux) - modification dates will be stalled in such sequence. os.scandir() dir_entry.stat() # let it

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Cezary Wagner added the comment: Use case - detection of changes in open files is very important - log scanning - synchronization ... I think that first of all it is need good unit test to detect this problem (rare edge case - probably it is missed because hard to imagine that it can not

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Cezary Wagner added the comment: I do some test on linux all works - changes are detected and os.scandir() works but in Windows not - probably there is not unit test which check if os.scandir() is working on open files for writing. f.flush() no matter since file can be changed in external

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Steve Dower added the comment: Does it make the most sense for us to make .flush() also do an implicit .fsync() (when it's actually a file object)? -- ___ Python tracker ___

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Eryk Sun added the comment: In FSBO [1] section 6 "Time Stamps", note that the LastWriteTime value gets updated when an IRP_MJ_FLUSH_BUFFERS is processed. In the Windows API, this is a FlushFileBuffers [2] call. In the C runtime, it's a _commit [3] call, which is an os.fsync [4] call in

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Steve Dower added the comment: I'm going to have to spend more time to analyse this (later), but it seems like Windows deciding not to update the directory's data structures (containing the st_mtime retrieved by scandir) as long as the file is still open. I suspect the answer for your

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Cezary Wagner added the comment: One hint more. Start of new process os.scandir() give invalid modification date for file open for writing until external tool is not called (like explorer, touch, etc.). So (log open for writing and write is done between 1, 2): 1. Run program with

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

Cezary Wagner added the comment: Extra file for for tests with: DO_STAT = False See not changes but file was writing every second. If os.stat() run all between call os.scandir() all works. C:\root\Python38\python.exe

[issue41106] os.scandir() Windows bug dir_entry.stat() not works on file during writing.

(). Source code responsible for it is probably this -> I do not understand CPython code -> https://github.com/python/cpython/blob/master/Modules/posixmodule.c. Here is full description - many test was done. # os.scandir() Windows bug dir_entry.stat() not works on file during w

[issue35663] webbrowser.py firefox bug [python3, windows 10]

E. Paine added the comment: Your code works fine on Windows 10 2004 with Python 3.8.3 and Firefox 77.0.1 (Firefox not set to default browser). -- nosy: +epaine ___ Python tracker

[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode

STINNER Victor added the comment: Merged, thanks for the fix. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode

STINNER Victor added the comment: New changeset 8a3d2af997e3702eac4c5b012537be39ada36888 by Sanyam Khurana in branch 'master': bpo-26543: Fix IMAP4.noop when debug mode is enabled (GH-15206) https://github.com/python/cpython/commit/8a3d2af997e3702eac4c5b012537be39ada36888 -- nosy:

[issue22750] xmlapp.py display bug when validate XML by DTD

Change by Serhiy Storchaka : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue21547] '!s' formatting documentation bug

Serhiy Storchaka added the comment: Python 2.7 is no longer supported. -- nosy: +serhiy.storchaka resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue13171] Bug in file.read(), can access unknown data.

Change by Serhiy Storchaka : -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue40804] Bug report in python3.6.8 using argparse module

Terry J. Reedy added the comment: 3.6 has only gotten security fixed for 1.5 years. We need a test file that can be run as is in the master branch to see if there is a current bug. -- nosy: +terry.reedy ___ Python tracker <ht

[issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only)

Terry J. Reedy added the comment: hang.py uses the default multiprocessing start method, which was then 'fork'. It is now 'spawn' on macOS. And there have been many other changes. When I run the following from IDLE, it finishes immediately. import multiprocessing, sqlite3 def hang():

[issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only)

Change by Erlend Egeberg Aasland : -- nosy: +erlendaasland ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40804] Bug report in python3.6.8 using argparse module

Change by Florian Dahlitz : -- nosy: +DahlitzFlorian ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40804] Bug report in python3.6.8 using argparse module

Rémi Lapeyre added the comment: Hi amansi26, thanks for reporting this issue. Without an example program that reproduces it, we won't be able to diagnose and fix it thought. Can you post one? -- nosy: +remi.lapeyre ___ Python tracker

[issue40804] Bug report in python3.6.8 using argparse module

New submission from amansi26 : I am using 3.6.8 version of python. I am seeing an error as AttributeError: 'Namespace' object has no attribute 'func' while using argparse . The code is working fine with python2.7 argparser. I see a similar bug [4] reported at python 3.3 and python3.4

[issue40651] class:`OrderedDict` Examples: LRU implementation has a bug.

Raymond Hettinger added the comment: New changeset d88f0aa8e24ea7562f2e04833f46d8526e846334 by Miss Islington (bot) in branch '3.8': bpo-40651: Improve LRU recipe in the OrderedDict documentation (GH-GH-20139) (GH-20167)

[issue40651] class:`OrderedDict` Examples: LRU implementation has a bug.

Raymond Hettinger added the comment: Thanks for PR :-) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8, Python 3.9 ___ Python tracker

[issue40651] class:`OrderedDict` Examples: LRU implementation has a bug.

Change by miss-islington : -- nosy: +miss-islington nosy_count: 3.0 -> 4.0 pull_requests: +19466 pull_request: https://github.com/python/cpython/pull/20167 ___ Python tracker

[issue40651] class:`OrderedDict` Examples: LRU implementation has a bug.

Raymond Hettinger added the comment: New changeset bb8635cc3bc3dd65996803849ee1a91cfbebae9c by qudongfang in branch 'master': bpo-40651: Improve LRU recipe in the OrderedDict documentation (GH-#20139) https://github.com/python/cpython/commit/bb8635cc3bc3dd65996803849ee1a91cfbebae9c

[issue39959] Bug on multiprocessing.shared_memory

Rauan Mukhamejanov added the comment: Not sure about "it can always be accessed and closed/unlinked by any process later on", as each process will be spawning its own resource_tracker, using a separate pipe. Thus, unregister calls from other processes will not have any effect. The

[issue40651] class:`OrderedDict` Examples: LRU implementation has a bug.

Change by Dongfang Qu : -- keywords: +patch pull_requests: +19445 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20139 ___ Python tracker ___

[issue40651] class:`OrderedDict` Examples: LRU implementation has a bug.

Dongfang Qu added the comment: Document of `collections`. https://docs.python.org/3/library/collections.html -- ___ Python tracker ___

[issue40651] class:`OrderedDict` Examples: LRU implementation has a bug.

New submission from Dongfang Qu : class:`OrderedDict` Examples: LRU implementation has a bug. Details: The calls to the `__setitem__` method should also count as usages. -- assignee: docs@python components: Documentation messages: 369083 nosy: Dongfang Qu, docs@python priority: normal

[issue39959] Bug on multiprocessing.shared_memory

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 5.0 -> 6.0 pull_requests: +19441 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20136 ___ Python tracker

[issue39959] Bug on multiprocessing.shared_memory

Floris added the comment: I confirm the same issue as Diogo. The provided workaround of unregistering the sharedmemory segment in the 'consuming' process, as suggested by Jeff, solves the issue where exiting the consuming process causes the tracker to incorrectly free the shared memory.

[issue40581] scipy's differential_evolution bug

with SciPi, > https://www.scipy.org/scipylib/bug-report.html > > -- > nosy: +christian.heimes > resolution: -> third party > stage: -> resolved > status: open -> closed > > __

[issue40581] scipy's differential_evolution bug

Christian Heimes added the comment: SciPy and Sage are 3rd party extensions to CPython and not maintained by us. Please report the issue with SciPi, https://www.scipy.org/scipylib/bug-report.html -- nosy: +christian.heimes resolution: -> third party stage: -> resolved status

[issue40581] scipy's differential_evolution bug

New submission from Mike : I have a random bug with scipy's optimize . I use it in the context of SageMath (Python 3.7.3). I checked 3 algorithms : shgo, dual_annealing and full_optimize. All don't work well (at all !). I optimise with a 3 parameters functions with given bounds

[issue40555] pegen (PEP 617): bug in error handling

Pablo Galindo Salgado added the comment: New changeset db9163ceef31ba00ccb23226917f9c8e9142a0b8 by Pablo Galindo in branch 'master': bpo-40555: Check for p->error_indicator in loop rules after the main loop is done (GH-19986)

[issue40555] pegen (PEP 617): bug in error handling

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue40555] pegen (PEP 617): bug in error handling

Lysandros Nikolaou added the comment: That's because we're not checking for errors after a loop is done. Pushing a fix. -- ___ Python tracker ___

[issue40555] pegen (PEP 617): bug in error handling

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +19302 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19986 ___ Python tracker

[issue40555] pegen (PEP 617): bug in error handling

New submission from STINNER Victor : autopep8 test suite does crash on Python 3.9.0a6. The bug can be reproduced with: Python 3.9.0a6+ (heads/master:b7a78ca74a, May 8 2020, 01:46:01) [GCC 10.0.1 20200430 (Red Hat 10.0.1-0.14)] on linux Type "help", "copyright", &

[issue40555] pegen (PEP 617): bug in error handling

STINNER Victor added the comment: Workaround: use python3.9 -X oldparser. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Karthikeyan Singaravelan added the comment: Thanks Avram for the report. I have reopened issue25597. Closing this as the regression change has been reverted for 3.9. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Chris Withers added the comment: New changeset 521c8d6806adf0305c158d280ec00cca48e8ab22 by Karthikeyan Singaravelan in branch 'master': bpo-39966: Revert "bpo-25597: Ensure wraps' return value is used for magic methods in MagicMock" (GH-19734)

Re: Bug in the urljoin library

Moro, Andrea via Python-list wrote: > Hello there, > > I believe there is a bug in the urljoin library. I believe this is a case of garbage-in garbage-out ;) Try p = urlparse(url) if not p.scheme: url = urlunparse(p._replace(scheme="http")) > > See bel

Bug in the urljoin library

Hello there, I believe there is a bug in the urljoin library. See below: p = urlparse(url) if p.scheme == '': url = urljoin('http://', url) Input: domain.tld/somepath Output http:///domain.tld/somepath p = urlparse(url) if p.scheme == '': url = urljoin('http:', url) Input: domain.tld

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Karthikeyan Singaravelan added the comment: I opened a PR to revert the change. issue25597 was open for sometime and the implications as reported here seem to be greater than the original report to just call the magicmethod. So we can revert the change to ensure there are no regressions in

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Change by Karthikeyan Singaravelan : -- pull_requests: +19055 pull_request: https://github.com/python/cpython/pull/19734 ___ Python tracker ___

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Avram added the comment: Checking for presence and then falling through to the <=3.8 behavior as in the patch, seems reasonable. The default magic method behavior presumably comes out of research, trial, and error. If the docs need to be clearer, I think that's different that scrapping the

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Chris Withers added the comment: I'd go with your instincts on what to do next, I'd have a slight preference to keeping behaviour the same as it was in 3.8 if the changes for 3.9 cause more problems. That leaves us no worse off than we were before, and with the opportunity to improve from

[issue21615] Curses bug report for Python 2.7 and Python 3.2

Zachary Ware added the comment: Hi Richard, sorry it too so long for anyone to respond to this issue! It's been long enough that I'm going to assume that this has long since been fixed or worked around. However, if you can still reproduce this with a modern version of Python (3.6-3.8), do

[issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode

Change by Sadhana Srinivasan : -- nosy: +rotuna nosy_count: 9.0 -> 10.0 pull_requests: +19013 pull_request: https://github.com/python/cpython/pull/19693 ___ Python tracker ___

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Karthikeyan Singaravelan added the comment: The patch assumed using the magic method attribute as the way to evaluate an object in a context which I got to know is wrong since evaluations in context like boolean are not only dependent on one magic method but has a precedence over several

[issue39959] Bug on multiprocessing.shared_memory

Diogo Flores added the comment: Any update on this issue? -- title: (Possible) bug on multiprocessing.shared_memory -> Bug on multiprocessing.shared_memory ___ Python tracker <https://bugs.python.org/issu

[issue40303] argparse parse_args args parameter bug or intended

Gharg added the comment: Hi Rémi and Paul, thanks for your quick response. It is as i expected and i will use 'store_true'/'store_false' to resolve my problem. I see this issue as resolved and close it. -- resolution: -> not a bug stage: -> resolved status: open -&g

[issue40303] argparse parse_args args parameter bug or intended

nely empty string. As can be seen in several previous bug/issues, 'bool' is allowed as a type function, but since the only string that returns False is the empty one, it isn't very useful. And we've resisted attempts give it some special treatment. Users can write their own 'type' function th

[issue40303] argparse parse_args args parameter bug or intended

Rémi Lapeyre added the comment: Hi Gharg, this is expected, both because your program would not actually receive `--boolean=''` but `--boolean=`: ➜ ~ cat test.py import sys print(sys.argv) ➜ ~ python test.py --boolean='' ['test.py', '--boolean='] and the way the type argument works. You

[issue40303] argparse parse_args args parameter bug or intended

Change by Karthikeyan Singaravelan : -- nosy: +paul.j3, rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40303] argparse parse_args args parameter bug or intended

an="" parsed_args.boolean will evaluate to False. -- messages: 366608 nosy: Gharg priority: normal severity: normal status: open title: argparse parse_args args parameter bug or intended type: behavior versions: Python 3.7 ___ P

[issue40263] Follow on bug from https://bugs.python.org/issue26903 (ValueError exception on _winapi.WaitForMultipleObjects)

Change by Ray Donnelly : -- keywords: +patch Added file: https://bugs.python.org/file49057/-Fix-off-by-one-error-in-_winapi_WaitForMultipleObjec.patch ___ Python tracker

[issue40263] Follow on bug from https://bugs.python.org/issue26903 (ValueError exception on _winapi.WaitForMultipleObjects)

Change by Ray Donnelly : Removed file: https://bugs.python.org/file49056/-bpo-26903-Limit-ProcessPoolExecutor-to-61-workers-on-Windows.patch.ref ___ Python tracker ___

[issue40263] Follow on bug from https://bugs.python.org/issue26903 (ValueError exception on _winapi.WaitForMultipleObjects)

Ray Donnelly added the comment: See my proposed patch. I am happy to make a PR on github for this too if people agree it's the right fix. -- Added file: https://bugs.python.org/file49056/-bpo-26903-Limit-ProcessPoolExecutor-to-61-workers-on-Windows.patch.ref

[issue40263] Follow on bug from https://bugs.python.org/issue26903 (ValueError exception on _winapi.WaitForMultipleObjects)

New submission from Ray Donnelly : See attached reproducer -- components: Interpreter Core, Windows files: ppe.py messages: 366258 nosy: Ray Donnelly, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Follow on bug from https

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Change by Karthikeyan Singaravelan : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

R. David Murray added the comment: My guess is that it isn't so much that __bool__ is special, as that the evaluation of values in a boolean context is special. What you have to do to make a mock behave "correctly" in the face that I'm not sure (I haven't investigated). And I might be

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Avram added the comment: Honestly, I'm not sure if any of the other magic methods behave this way. It would take a little research or someone more familiar with it. Here's more info about how __bool__ behaves. https://docs.python.org/3/reference/datamodel.html#object.__bool__ --

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Karthikeyan Singaravelan added the comment: Thanks for the example I didn't know hasattr can return False to return a value when the magicmethod was accessed. I will wait for others opinion on this then. -- ___ Python tracker

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Avram added the comment: That is not necessarily the same thing, hence why there was a bug. >>> hasattr(object, '__bool__') False >>> bool(object) True I think you may be right that magic methods shouldn't magically appear for wrapped objects, except those that do magi

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Karthikeyan Singaravelan added the comment: > What may make more sense for some magic methods is to call the underlying > object and use the return value or raise any exception that occurs. Sorry, isn't that what the previous issue did? It tries to return the wrapped object attribute and

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Avram added the comment: Ah, I see, yes, the documentation is a bit inconsistent. What may make more sense for some magic methods is to call the underlying object and use the return value or raise any exception that occurs. For example: __bool__ return value is bool(mock._mock_wraps) __int__

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Karthikeyan Singaravelan added the comment: It's supposed to raise an AttributeError if the attribute is not present. The previous case was that magicmethods were not wrapped returning configured values. So this conflicts with the documentation returning a default value when not present

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Avram added the comment: They are documented. That said, the subsection section could use a header. https://docs.python.org/3/library/unittest.mock.html#magic-mock Patch looks good! Can't think of any other test scenarios right now. -- ___ Python

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

Karthikeyan Singaravelan added the comment: On thinking more about this the wraps argument provides a way to wrap the calls for the mock to a given object. So when an attribute not present in the wrapped object is being accessed then it should act like the attribute is not present. Falling

[issue40063] Bug in 3rd party sybase database connector (Fatal python error:PyEval_RestoreThread NULL tstate)

STINNER Victor added the comment: I close the issue. It's a bug in a third-party project, not in Python itself. If you can reproduce the bug with a simple script which only uses the stdlib, please reopen the issue. -- resolution: -> third party stage: -> resolved status

[issue40070] GCC crashed on AMD64 RHEL7 LTO + PGO 3.7 (compiler bug)

fault } ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://bugzilla.redhat.com/bugzilla> for instructions. gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none

Re: Intermittent bug with asyncio and MS Edge

ot suffer from >>> dropping files, so I now think this is a sidetrack. I will fix my program >>> when this is all over, but for now I don't want to touch it. >> Yes your protocol violation is why you see [RST, ACK]. >> I'm confused you know that the code has a critical bu

Re: Intermittent bug with asyncio and MS Edge

might see the same problem crop up in other situations. Definitely worth the time to investigate this one, since you now know the ACTUAL reason and can solve the ACTUAL bug. > It has been an interesting ride, and I have learned a lot. I will now > look into fixing my program. The easy fix is

Re: Intermittent bug with asyncio and MS Edge

a critical bug in it and you have not fixed it? Just send "Connection: close" and I'd assume all will work. Well, the reason is simply that I wanted to understand why my code that worked all the way from 3.4 through 3.7 stopped working in 3.8. I realise that my code is faulty, b

Re: Intermittent bug with asyncio and MS Edge

nly one version of my program. I am simply running it with either > 'py -3.7 ' or 'py -3.8'. And I am ignoring Chrome at this stage, as it is > only that Edge shows the problem. > > First point - Python3.7 also shows a lot of [RST, ACK] lines. My guess is > that this is caused b

Re: Intermittent bug with asyncio and MS Edge

On 2020-03-24 1:54 PM, Frank Millman wrote: On 2020-03-23 1:56 PM, Frank Millman wrote: I have one frustration with Wireshark. I will mention it in case anyone has a solution. I can see that Edge opens multiple connections. I am trying to track the activity on each connection separately. I

Re: Intermittent bug with asyncio and MS Edge

On 2020-03-23 1:56 PM, Frank Millman wrote: On 2020-03-23 12:57 PM, Chris Angelico wrote: On Mon, Mar 23, 2020 at 8:03 PM Frank Millman wrote: On 2020-03-22 12:11 PM, Chris Angelico wrote: On Sun, Mar 22, 2020 at 8:30 PM Frank Millman wrote: On 2020-03-22 10:45 AM, Chris Angelico wrote:

Re: Intermittent bug with asyncio and MS Edge

On Mon, Mar 23, 2020 at 10:58 PM Frank Millman wrote: > > On 2020-03-23 12:57 PM, Chris Angelico wrote: > > On Mon, Mar 23, 2020 at 8:03 PM Frank Millman wrote: > >> > >> On 2020-03-22 12:11 PM, Chris Angelico wrote: > >>> On Sun, Mar 22, 2020 at 8:30 PM Frank Millman wrote: > > On

Re: Intermittent bug with asyncio and MS Edge

server will allow another transaction, GET, POST etc. Note: You need to know if the client is using HTTP/1.0 or HTTP/1.1 protocol the rules are different in each version. > > In my program, when I send a file in response to a GET, I send a header with > 'Keep-alive', then I send the

Re: Intermittent bug with asyncio and MS Edge

On 2020-03-23 12:57 PM, Chris Angelico wrote: On Mon, Mar 23, 2020 at 8:03 PM Frank Millman wrote: On 2020-03-22 12:11 PM, Chris Angelico wrote: On Sun, Mar 22, 2020 at 8:30 PM Frank Millman wrote: On 2020-03-22 10:45 AM, Chris Angelico wrote: If you can recreate the problem with a

Re: Intermittent bug with asyncio and MS Edge

ld just close its end of the socket and that'd be that. > In my program, when I send a file in response to a GET, I send a header > with 'Keep-alive', then I send the file, then I close the connection. > This now seems wrong. It could even be the cause of my bug, but then why > has it only app

Re: Intermittent bug with asyncio and MS Edge

. This now seems wrong. It could even be the cause of my bug, but then why has it only appeared now? Both Edge and Chrome send 'Keep-alive' headers. If I am thinking along the right lines, then the exchange should go like this - Client sends request, with 'Keep-alive' header. Server sends

Re: Intermittent bug with asyncio and MS Edge

> On 22 Mar 2020, at 09:41, Frank Millman wrote: > > On 2020-03-22 11:00 AM, Barry Scott wrote: >>> On 22 Mar 2020, at 07:56, Frank Millman wrote: >>> >>> On 2020-03-21 8:04 PM, Barry Scott wrote: I'd look at the network traffic with wireshark to see if there is anything

Re: Intermittent bug with asyncio and MS Edge

> On 22 Mar 2020, at 11:59, Frank Millman wrote: > > On 2020-03-22 1:01 PM, Chris Angelico wrote: >> On Sun, Mar 22, 2020 at 12:45 AM Frank Millman wrote: >>> >>> Hi all >>> >>> I have a strange intermittent bug. >>> >>>

Re: Intermittent bug with asyncio and MS Edge

On 2020-03-22 1:01 PM, Chris Angelico wrote: On Sun, Mar 22, 2020 at 12:45 AM Frank Millman wrote: Hi all I have a strange intermittent bug. The role-players - asyncio on Python 3.8 running on Windows 10 Microsoft Edge running as a browser on the same machine The bug does

Re: Intermittent bug with asyncio and MS Edge

of waiting for another HTTP request). Kouli On Sun, Mar 22, 2020 at 12:04 PM Chris Angelico wrote: > On Sun, Mar 22, 2020 at 12:45 AM Frank Millman wrote: > > > > Hi all > > > > I have a strange intermittent bug. > > > > The role-players - >

Re: Intermittent bug with asyncio and MS Edge

On Sun, Mar 22, 2020 at 12:45 AM Frank Millman wrote: > > Hi all > > I have a strange intermittent bug. > > The role-players - > asyncio on Python 3.8 running on Windows 10 > Microsoft Edge running as a browser on the same machine > > The bug does not oc

Re: Intermittent bug with asyncio and MS Edge

> What is the async wait to wait for the transmit buffers to drain? > > > > Not sure what you are asking. I am just doing what it says in the docs - > I think his question is "what would asyncio be sleeping for, since you already made it wait till it was drained". And my guess is that there's a bug somewhere; the question is where. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: Intermittent bug with asyncio and MS Edge

On Sun, Mar 22, 2020 at 8:30 PM Frank Millman wrote: > > On 2020-03-22 10:45 AM, Chris Angelico wrote: > > On Sun, Mar 22, 2020 at 6:58 PM Frank Millman wrote: > >>> I'd look at the network traffic with wireshark to see if there is > >>> anything different between edge and the other browsers. >

Re: Intermittent bug with asyncio and MS Edge

On 2020-03-22 11:00 AM, Barry Scott wrote: On 22 Mar 2020, at 07:56, Frank Millman wrote: On 2020-03-21 8:04 PM, Barry Scott wrote: I'd look at the network traffic with wireshark to see if there is anything different between edge and the other browsers. You are leading me into deep

Re: Intermittent bug with asyncio and MS Edge

On 2020-03-22 10:45 AM, Chris Angelico wrote: On Sun, Mar 22, 2020 at 6:58 PM Frank Millman wrote: I'd look at the network traffic with wireshark to see if there is anything different between edge and the other browsers. You are leading me into deep waters here :-) I have never used

Re: Intermittent bug with asyncio and MS Edge

> On 22 Mar 2020, at 07:56, Frank Millman wrote: > > On 2020-03-21 8:04 PM, Barry Scott wrote: >>> On 21 Mar 2020, at 13:43, Frank Millman wrote: >>> >>> Hi all >>> >>> I have a strange intermittent bug. >>> >>&g

<    3   4   5   6   7   8   9   10   11   12   >