[issue17110] sys.argv docs should explaining how to handle encoding issues

miss-islington added the comment: New changeset 5b80cb5584a72044424f2d82d0ae79c720f24c47 by Miss Islington (bot) in branch '3.7': bpo-17110: doc: add note how to get bytes from sys.argv (GH-12602) https://github.com/python/cpython/commit/5b80cb5584a72044424f2d82d0ae79c720f24c47 --

[issue17110] sys.argv docs should explaining how to handle encoding issues

Change by miss-islington : -- pull_requests: +12559 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17110] sys.argv docs should explaining how to handle encoding issues

Inada Naoki added the comment: New changeset 38f4e468d4b1e135c67337c18ae142193ba8 by Inada Naoki in branch 'master': bpo-17110: doc: add note how to get bytes from sys.argv (GH-12602) https://github.com/python/cpython/commit/38f4e468d4b1e135c67337c18ae142193ba8 -- nosy:

[issue36438] Python 3.5.7 import error on Cross compile

Terry J. Reedy added the comment: Python 3.5 and 3.6 only get security fixes. Please test on 3.7 or even better 3.8. Your questions should be directed to python-list. -- nosy: +terry.reedy ___ Python tracker

[issue36426] exec() issue when used inside function

Terry J. Reedy added the comment: This is not a bug; the behavior is covered in the docs. I am surprised that this works in 2.7, as it has the same warning as 3.7: " locals() Update and return a dictionary representing the current local symbol table. Free variables are returned by

[issue35224] PEP 572: Assignment Expressions

Vedran Čačić added the comment: Carol, if you're willing to go into the lion's den that is Python-ideas with this, you have my eternal gratitude. :-) Steven, sorry, there really is no rush. I really don't think I ever said there is. However, I think it would be much easier to change the

[issue36411] Python 3 f.tell() gets out of sync with file pointer in binary append+read mode

Terry J. Reedy added the comment: 'Python 3.9' does not exist yet. This choice is for patches that should only be applied to 3.9 when available (like future deprecations or removals). -- nosy: +terry.reedy versions: -Python 3.9 ___ Python

[issue36467] IDLE to help with invisible characters

Terry J. Reedy added the comment: With respect to Shell, this is a request that IDLE move further away from strictly imitating Python running in a dumb terminal and better help users with intelligent action and information. I want both to improve editing and make entry of a statement in

[issue36482] let struct's internal cache use FIFO policy

Ma Lin added the comment: FYI, re module's cache is using FIFO policy: https://github.com/python/cpython/blob/v3.8.0a3/Lib/re.py#L288-L293 -- ___ Python tracker ___

[issue36482] let struct's internal cache use FIFO policy

Change by Ma Lin : -- keywords: +patch pull_requests: +12558 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue36482] let struct's internal cache use FIFO policy

New submission from Ma Lin : Currently, when the cache is full, the entire cache is cleared. This patch let it use FIFO policy. Inada Naoki, Raymond Hettinger, could you review this patch? Thanks. No hurry, just do it when you have time. -- components: Library (Lib) messages: 339168

[issue36481] telnetlib process_rawq() callback

Change by Roundup Robot : -- keywords: +patch pull_requests: +12557 stage: -> patch review ___ Python tracker ___ ___

[issue36478] backport of pickle fixes to Python 3.5.7 uses C99 for loops

Change by Karthikeyan Singaravelan : -- nosy: +larry, vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue34160] ElementTree not preserving attribute order

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34160] ElementTree not preserving attribute order

STINNER Victor added the comment: I set the priority to release blocker to make sure that the issue got enough attention. Raymond started a thread on python-dev, so I reset the priority: https://mail.python.org/pipermail/python-dev/2019-March/156709.html Moreover, the change is now

[issue36481] telnetlib process_rawq() callback

New submission from Gökhan Öztürk : telnetlib.Telnet class requires a callback so that the raw data that comes from socket can be processed first. This will be useful for the compressed incoming data. Most of the MUD servers have MCCP V2 (byte: 86) protocol that send compressed data. But as

[issue36480] .strip() unexpected output on Windows

Eric V. Smith added the comment: Please provide the exact code to duplicate the problem. I suspect this is a problem with your code, not with str.strip and not with Windows. -- nosy: +eric.smith status: open -> pending ___ Python tracker

[issue36480] .strip() unexpected output on Windows

New submission from 78 <78alphadevi...@gmail.com>: Using .strip() on windows leads to the first and last character of a word being deleted. Magenta.zip becomes agenta.zi -- components: Windows messages: 339164 nosy: 78Alpha, paul.moore, steve.dower, tim.golden, zach.ware priority:

[issue36085] Enable better DLL resolution

Steve Dower added the comment: Leaving this in commit review for a couple of days, then I'll close. -- stage: patch review -> commit review ___ Python tracker ___

[issue36085] Enable better DLL resolution

Steve Dower added the comment: New changeset 2438cdf0e932a341c7613bf4323d06b91ae9f1f1 by Steve Dower in branch 'master': bpo-36085: Enable better DLL resolution on Windows (GH-12302) https://github.com/python/cpython/commit/2438cdf0e932a341c7613bf4323d06b91ae9f1f1 --

[issue35224] PEP 572: Assignment Expressions

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35947] Update libffi_msvc to current version of libffi

Steve Dower added the comment: New changeset 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 by Steve Dower (Paul Monson) in branch 'master': bpo-35947: Update Windows to the current version of libffi (GH-11797) https://github.com/python/cpython/commit/32119e10b792ad7ee4e5f951a2d89ddbaf111cc5

[issue35224] PEP 572: Assignment Expressions

STINNER Victor added the comment: The bug tracker is not the appropriate place to discuss a PEP. This issue is about the implementation of the PEP. -- ___ Python tracker ___

[issue35224] PEP 572: Assignment Expressions

Steven D'Aprano added the comment: You are one person, who has used this feature for what, a month elapsed time? 300 person-hours actual experience with it? Allowing top-level unparenthisized walrus expressions will affect hundreds of thousands of people, for collectively millions of hours

[issue36085] Enable better DLL resolution

Steve Dower added the comment: So symlinking didn't work (Python is too clever for that these days ;) ), but straight copying the exe and required DLLs is fine. It puts python.exe, python38.dll and vcruntime140.dll (properly discovered of course) into a temp directory, puts _sqlite3.pyd

[issue33356] Windows 10 buildbot: test__xxsubinterpreters.test_already_running() fails randomly

Eric Snow added the comment: I'll take a look when I get a chance. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure can terminate the calling thread

Eric Snow added the comment: > Currently PyEval_RestoreThread and its callers (mainly PyGILState_Ensure) > can terminate the thread if the interpreter is finalizing: s/interpreter/runtime/ Most likely (guaranteed?) it will be in the main interpreter, but it is actually not triggered by

[issue36479] Exit threads when interpreter is finalizing rather than runtime.

New submission from Eric Snow : Currently when a thread acquires the GIL, it subsequently exits if the runtime is finalizing. This helps with some cases like with stopping daemon threads. This behavior should instead be triggered by the thread's interpreter finalizing rather than the

[issue36478] backport of pickle fixes to Python 3.5.7 uses C99 for loops

Change by Anthony Sottile : -- keywords: +patch pull_requests: +12556 stage: -> patch review ___ Python tracker ___ ___

[issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure can terminate the calling thread

Eric Snow added the comment: > > if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) > > _Py_IsFinalizing() check is redundant :-) Not really: * _Py_IsFinalizing() checks if the runtime is finalizing * _Py_CURRENTLY_FINALIZING checks if the current thread is the one running

[issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure can terminate the calling thread

Eric Snow added the comment: Related: * #36475: "PyEval_AcquireLock() and PyEval_AcquireThread() do not handle runtime finalization properly." * #36476: "Runtime finalization assumes all other threads have exited." -- ___ Python tracker

[issue36478] backport of pickle fixes to Python 3.5.7 uses C99 for loops

New submission from Anthony Sottile : While building python 3.5.7 for https://github.com/deadsnakes ../Modules/_pickle.c: In function 'PyMemoTable_Copy': ../Modules/_pickle.c:677:5: error: 'for' loop initial declarations are only allowed in C99 mode for (size_t i = 0; i <

[issue36157] Document PyInterpreterState_Main().

Eric Snow added the comment: As I noted on the PR, this might be a good chance to make sure the C-API docs are clear about what the "main" interpreter is. -- ___ Python tracker

[issue36097] Use only public C-API in _xxsubinterpreters module.

Change by Eric Snow : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue36225] Lingering subinterpreters should be implicitly cleared on shutdown

Eric Snow added the comment: test__xxsubinterpreters is a great place for tests that exercise use of subinterpreters, including most lifecycle operations. There are also one or two subinterpreter-related tests in test_embed. However, for this issue the interplay with runtime finalization

[issue36225] Lingering subinterpreters should be implicitly cleared on shutdown

Eric Snow added the comment: Interestingly, I noticed this independently today. :) Here's what I wrote in #36477 (which I've closed as a duplicate): When using subinterpreters, any that exist when Py_FinalizeEx() is called do not appear to get cleaned up during runtime finalization. Maybe

[issue36477] Subinterpreters are not finalized during runtime finalization.

Change by Eric Snow : -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Lingering subinterpreters should be implicitly cleared on shutdown ___ Python tracker

[issue31182] Suggested Enhancements to zipfile & tarfile command line interfaces

Brett Cannon added the comment: I'm going to agree w/ Serhiy and say thanks to Steve for the idea but for maintainability purposes we should keep the CLI of both modules simple and only for critical operations. -- nosy: +brett.cannon ___ Python

[issue31182] Suggested Enhancements to zipfile & tarfile command line interfaces

Change by Brett Cannon : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: @Remy, aside from the recommendations I've made, I'm not sure what else we can do to help. Before we close the issue, I'd really like to ensure that one of those threads is holding the GIL still. It would definitely be a problem if a thread exited while still

[issue36476] Runtime finalization assumes all other threads have exited.

Eric Snow added the comment: FYI, I've opened issue36477 to deal with the subinterpreters case. -- ___ Python tracker ___ ___

[issue36477] Subinterpreters are not finalized during runtime finalization.

New submission from Eric Snow : When using subinterpreters, any that exist when Py_FinalizeEx() is called do not appear to get cleaned up during runtime finalization. Maybe I've been looking at the code too much and I'm missing something. :) This really isn't a problem except for embedders

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: I've also opened issues #36476 and #36477. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue36476] Runtime finalization assumes all other threads have exited.

New submission from Eric Snow : Among the first 3 things that happen in Py_FinalizeEx() are, in order: 1. wait for all non-daemon threads (of the main interpreter) to finish 2. call registered atexit funcs 3. mark the runtime as finalizing At that point the only remaining Python threads are:

[issue36468] Treeview: wrong color change

Ned Deily added the comment: Thanks for the report. The difference in behavior appears to be due to a change in Tk. Using the python.org 3.7.2 or .3 installers which use Tk 8.6.8, the colors are displayed. But if I use a Python linked with Tk 8.6.9, the bars are not colored. You can run

[issue36475] PyEval_AcquireLock() and PyEval_AcquireThread() do not handle runtime finalization properly.

Change by Eric Snow : -- components: +Interpreter Core ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36466] Adding a way to strip annotations from compiled bytecode

Change by Ivan Levkivskyi : -- nosy: +gvanrossum, levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: Looking at the stack traces for all your threads (super helpful, BTW), I saw 4 groups: * (1) main thread (blocked on GIL during runtime finalization) + Thread 1 * (12) blocked on GIL in call to PyEval_RestoreThread() (socket, select, time.sleep(),

[issue36470] dataclasses.replace raises an exception if InitVar with default argument is not provided.

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: I've opened issue36475 for the two C-API functions that do not cause daemon threads to exit. -- ___ Python tracker ___

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Remy Noel added the comment: Oh, also, i do not use any C extension (apart from the one i mentionned), so i do not acquire/release the GIL directly (a component of the standard library would do so). The demon threads, mainly spend their time listening to sockets and running short

[issue36475] PyEval_AcquireLock() and PyEval_AcquireThread() do not handle runtime finalization properly.

New submission from Eric Snow : Daemon threads keep running until they finish or until finalization starts. For the latter, there is a check right after the thread acquires the GIL which causes the thread to exit if runtime finalization has started. [1] However, there are functions in the

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Remy Noel added the comment: Thank you a lot for this detailed answer. Does the "causes of exit" may terminate the thread without releasing the GIL ? Because as far as i can tell, none of the threads seems to own the GIL (i only checked _PyThreadState_Current though there might be a better

[issue36474] RecursionError resets trace function set via sys.settrace

daniel hahler added the comment: Discovered via / relevant for coverage's PyTracer: https://github.com/nedbat/coveragepy/issues/787. -- ___ Python tracker ___

[issue36474] RecursionError resets trace function set via sys.settrace

New submission from daniel hahler : A RecursionError causes the trace function set via `sys.settrace` to get removed/unset. Given the following script: ``` import sys def trace(*args): print("trace", args) return trace sys.settrace(trace) def f(): f() print(sys.gettrace())

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: Here are some things that would likely help: * in the main thread stop your daemon threads if you hit SystemExit * make sure daemon threads release/acquire the GIL frequently (so they notice finalization) * make sure daemon threads otherwise exit promptly (no

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: At this point I think it's likely that the problem relates to how daemon threads are handled during runtime finalization. What normally happens in the main thread of the "python3" executable is this: 1. Python runtime initializes 2. main interpreter initializes

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Remy Noel added the comment: std modules: atexit, json, os, signal, socket, ssl, subprocess, sys, time, threading, xmlrpc.client The non-standard extension: psutil, PIL (only for image encoding though). The amount of threads may vary, but i may have around 20 threads at all time. Most of

[issue35224] PEP 572: Assignment Expressions

Carol Willing added the comment: @veky As a Jupyter notebook maintainer, I can see your point and I suspect some would like it. I'm not sure how big a benefit it would be for folks based on current notebook usage and practices. I just don't know. It's worth a discussion, but it should take

[issue36463] python37.dll crashing 0xc000041d

Brett Cannon added the comment: Please provide code which consistently causes the crash, otherwise your use of ctypes makes the very likely not Python's fault and nearly impossible to debug without a working example. -- nosy: +brett.cannon status: open -> pending

[issue36463] python37.dll crashing 0xc000041d

Change by Brett Cannon : -- nosy: -brett.cannon status: pending -> open ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36448] Message "You will need to rebuild pythoncore to see the changes" should mention "make regen-all"

Steve Dower added the comment: Merged. It doesn't need a backport - the target audience is CI users who will see this on master first. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> compile error versions: -Python 3.7

[issue36472] Some old PR with CLA not signed

Brett Cannon added the comment: I'm already going through the "CLA not signed" issues and cleaning them up, so there's no need for anyone to duplicate my work. And this is not a steering council concern but a core-workflow concern. -- resolution: -> not a bug stage: -> resolved

[issue36448] Message "You will need to rebuild pythoncore to see the changes" should mention "make regen-all"

Steve Dower added the comment: New changeset 3396d1e0ca858065c5bb7e5a9737be6ffc4028f7 by Steve Dower (Jeroen Demeyer) in branch 'master': bpo-36448: mention 'make regen-all' in error message (GH-12585) https://github.com/python/cpython/commit/3396d1e0ca858065c5bb7e5a9737be6ffc4028f7

[issue35224] PEP 572: Assignment Expressions

Change by Miro Hrončok : -- nosy: -hroncok ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34915] LWPCookieJar.save() creates *.lwp file in 644 mode

Karthikeyan Singaravelan added the comment: I guess this is a good choice and distutils stores .pypirc [0] in this manner that has username and password. [0] https://github.com/python/cpython/blob/2f54908afc5665937d763510b4430f10cf764641/Lib/distutils/config.py#L45 -- nosy:

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: * Are any signals (or signal handlers) involved? * Are you monkeypatching any builtins, builtin/stdlib modules (or any parts of those)? Keep in mind that a number of bugs have been fixed in later releases related to the various things I've asked about. For

[issue36470] dataclasses.replace raises an exception if InitVar with default argument is not provided.

Greg Kuhn added the comment: Fixed title -- title: dataclasses replace raises an exception with an empty -> dataclasses.replace raises an exception if InitVar with default argument is not provided. ___ Python tracker

[issue30703] Non-reentrant signal handler (test_multiprocessing_forkserver hangs)

Change by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35707] time.sleep() should support objects with __float__

Jeroen Demeyer added the comment: Is anybody willing to review PR 11636? -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue36448] Message "You will need to rebuild pythoncore to see the changes" should mention "make regen-all"

Jeroen Demeyer added the comment: > I'd propose adding "%0D%0A%0D%0AIf you are developing on another platform, > try make regen-all and commit the updated files" I updated the PR with wording similar to that. I don't want to bikeshed too much about the precise wording. If you disagree with

[issue35224] PEP 572: Assignment Expressions

Vedran Čačić added the comment: Sorry, I don't have the energy for endless discussions without any result that almost always happen there. If you - of all people - don't see an obvious benefit of this (not even a feature - just a removal of a quite pointless limitation), then I'm probably

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: Also: * are any of your threads daemon threads? -- ___ Python tracker ___ ___ Python-bugs-list

[issue35983] tp_dealloc trashcan shouldn't be called for subclasses

Jeroen Demeyer added the comment: I created an additional PR 12607 with some more changes to the, in particular to make the old backwards-compatibility trashcan macros safer. This should be seen as part of the same bugfix but I decided to make a new PR because PR 11841 had several positive

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Eric Snow added the comment: As Inada-san indicated, the problem might be resolved already. So without the option of reproducing the problem, it will be hard to resolve this. Here's some information you could provide that might help narrow down the scope a bit: * what

[issue36473] Detect all dictionary changes during iteration

Serhiy Storchaka added the comment: This is a duplicate of issue6017, issue19332 and issue29420. -- nosy: +pitrou, rhettinger, serhiy.storchaka ___ Python tracker ___

[issue36473] Detect all dictionary changes during iteration

Change by Karthikeyan Singaravelan : -- nosy: +inada.naoki ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35550] Some define guards for Solaris are wrong

Change by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Remy Noel added the comment: The bug happens about once every two weeks on a script that is fired more than 10K times a day. Sadly, i can't update the whole production environment to try it on the latest. (and i was unable to trigger the bug by myself). I was hoping we could find

[issue36452] Detect dict iteration "overflow" when changing keys

Change by Thomas Perl : -- pull_requests: +12555 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36473] Detect all dictionary changes during iteration

Change by Thomas Perl : -- keywords: +patch pull_requests: +12554 stage: -> patch review ___ Python tracker ___ ___

[issue36473] Detect all dictionary changes during iteration

New submission from Thomas Perl : On top of issue 36452, I noticed some other corner cases that are still not handled. For one, the patch (Github PR 12596) only handles iterating over keys, but not iterating over values or items: == a = {0: 0} it = iter(a.values()) print('Length hint:',

[issue36471] PEP 432, PEP 587: Add _Py_RunMain()

STINNER Victor added the comment: New changeset 2f54908afc5665937d763510b4430f10cf764641 by Victor Stinner in branch 'master': bpo-36471: Add _Py_RunMain() (GH-12618) https://github.com/python/cpython/commit/2f54908afc5665937d763510b4430f10cf764641 --

[issue36472] Some old PR with CLA not signed

Stéphane Wirtel added the comment: Brett would like to reduce the number of PRs, maybe we need to ask to the council about that point. -- nosy: +matrixise ___ Python tracker

[issue36471] PEP 432, PEP 587: Add _Py_RunMain()

Change by STINNER Victor : -- keywords: +patch pull_requests: +12553 stage: -> patch review ___ Python tracker ___ ___

[issue36469] Stuck during interpreter exit, attempting to take the GIL

Inada Naoki added the comment: Can you reproduce it on 3.7 or master branch? Python 3.5 is security fix only mode now. https://devguide.python.org/#status-of-python-branches -- nosy: +inada.naoki ___ Python tracker

[issue35224] PEP 572: Assignment Expressions

Guido van Rossum added the comment: @veky -- please take this up on python-ideas. -- ___ Python tracker ___ ___ Python-bugs-list

[issue36472] Some old PR with CLA not signed

Emmanuel Arias added the comment: > I would request this to be discussed in other channels like > https://discuss.python.org/c/core-workflow or zulip core-workflow chat or > mailing list. Ok. It good for you if I send this issue to https://discuss.python.org/c/core-workflow? Then, I close

[issue36472] Some old PR with CLA not signed

Karthikeyan Singaravelan added the comment: There were cases in the past where CLA was signed but there was mismatch in the bpo details and GitHub usernames linked due to which bot didn't change it to CLA signed. I would request this to be discussed in other channels like

[issue36472] Some old PR with CLA not signed

New submission from Emmanuel Arias : Hello everybody! Making a searching on GitHub: is:open label:"CLA not signed" We can see that there are some PR opened with CLA not signed label. The newest is 22 days ago and the oldest is from May 8, 2017. I can closed it if you consider apropiate

[issue36471] PEP 432, PEP 587: Add _Py_RunMain()

STINNER Victor added the comment: I'm working on a PR to implement it. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36471] PEP 432, PEP 587: Add _Py_RunMain()

New submission from STINNER Victor : The PEP 587 adds new functions taking command line arguments: Py_PreInitializeFromArgs(config, argc, argv) Py_PreInitializeFromWideArgs(config, argc, argv) Py_InitializeFromArgs(config, argc, argv) Py_InitializeFromWideArgs(config, argc, argv) I propose to

[issue36470] dataclasses replace raises an exception with an empty

Change by Karthikeyan Singaravelan : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36470] dataclasses replace raises an exception with an empty

New submission from Greg Kuhn : I have a snippet below which runs fine on python 3.7.0 but raises a ValueError exception on 3.7.1. I believe it's related to https://bugs.python.org/issue33805. The error: c:\python\lib\dataclasses.py:1219: ValueError The script: from dataclasses import

[issue28375] cgi.py spam in Apache server logs

yoch added the comment: Same issue here (python 3.6). This is very annoying, especially in case of large entries in FieldStorage, because the whole data is written to the log. Example: FieldStorage('image', 'upload.jpg', b'...can be very long...') -- components: +Library (Lib)

[issue27797] ASCII file with UNIX line conventions and enough lines throws SyntaxError when ASCII-compatible codec is declared

Change by Inada Naoki : -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> SyntaxError: encoding problem: iso-8859-1 on Windows ___ Python tracker

[issue36468] Treeview: wrong color change

Change by SilentGhost : -- nosy: +gpolo, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36469] Stuck during interpreter exit, attempting to take the GIL

New submission from Remy Noel : I have a script (sadly, I can't publish it) spawning multiple threads that, in rare occurences, does not manage to exit properly and get stuck forever. More precisely, this seems to happen during Interpreter exit: The atexit callbacks are called sucessfully,

[issue36463] python37.dll crashing 0xc000041d

Savagery added the comment: crash is caused by the WndProc definitions, seems having python code that does anything inside of those WINFUNCTYPE ctypes callbacks increasing the frequency of the python crash with positive correlation to amount of python code in the function. --

[issue36463] python37.dll crashing 0xc000041d

Change by Savagery : -- components: +Windows ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

  1   2   >