This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Fatal Python error: initfsencoding: unable to load the file system codec zipimport.ZipImportError: can't find module 'encodings'
Type: crash Stage: resolved
Components: Windows Versions: Python 3.8, Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: brett.cannon, eric.snow, hyu, lukasz.langa, miss-islington, ncoghlan, ned.deily, paul.moore, schlamar, serhiy.storchaka, steve.dower, tim.golden, vstinner, wwqgtxx, zach.ware
Priority: release blocker Keywords: 3.7regression, patch, patch, patch

Created on 2018-12-27 16:18 by hyu, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 11329 merged steve.dower, 2018-12-27 20:26
PR 11329 merged steve.dower, 2018-12-27 20:26
PR 11331 merged miss-islington, 2018-12-27 20:44
PR 11331 merged miss-islington, 2018-12-27 20:44
PR 11331 merged miss-islington, 2018-12-27 20:44
PR 11465 merged steve.dower, 2019-01-08 02:58
PR 11465 merged steve.dower, 2019-01-08 02:58
PR 11467 merged miss-islington, 2019-01-08 10:38
PR 11467 merged miss-islington, 2019-01-08 10:38
PR 11467 merged miss-islington, 2019-01-08 10:38
Messages (32)
msg332595 - (view) Author: (hyu) Date: 2018-12-27 16:18
>python
Fatal Python error: initfsencoding: unable to load the file system codec
zipimport.ZipImportError: can't find module 'encodings'

There are two vcruntime140.dll with no binary diff.
 Date      Time     Attr     Size   Compressed   Name
------------------- ----- -------- ------------  ----------------
2018-12-10 22:06:34 .....    80128        45532  vcruntime140.dll
...
2018-12-10 22:06:34 .....    80128        45532  vcruntime140.dll

Repeated downloads. Checked both versions:
https://www.python.org/ftp/python/3.7.2/python-3.7.2-embed-amd64.zip
https://www.python.org/ftp/python/3.7.2/python-3.7.2-embed-win32.zip

Searched and read release and doc. Checked bugs since yesterday.
msg332610 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-12-27 19:08
Have you tried a proper install as well? Could you do that to rule out any problem on your machine?

Are you repackaging anything as part of your app, or are you just testing the package first and getting this error?

It looks like you're running from the directory you extracted to. Is there anything else in that directory or just the Python files?

When you say there are two vcruntime140.dll, you mean one in each package and they're the same? That might be a problem, but it wouldn't show up like this, so I don't think it's yours. I'm not in A position to check the files right now but I'll get to it later
msg332612 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-12-27 20:16
Okay, this looks like a zipimport issue. When I extract the "python37.zip" file containing the stdlib and reference the directory it works fine. But no matter what I do to the ZIP I can't get it to run.

It seems that zipimport either can't import .pyc files without a matching .py, or it can't import packages marked with __init__.pyc (I haven't gone deep enough, but adding encodings/__init__.py got me further).

This is a regression from 3.7.1.

Things to do:
* fix the regression (Serhiy?)
* add a regression test
* add a ".pyc-only stdlib in ZIP" test (I'll do this)
* remove the double vcruntime in ZIP issue (unrelated, so I'll just fix it)
msg332615 - (view) Author: (hyu) Date: 2018-12-27 20:33
Repeated on two clean install Windows hosts.
No (re)packaging, download and run/start python.
Repeated with versions 3.7.2, 3.7.1, and 3.6.8:

https://www.python.org/ftp/python/3.7.2/python-3.7.2-embed-amd64.zip
https://www.python.org/ftp/python/3.7.1/python-3.7.1-embed-amd64.zip
https://www.python.org/ftp/python/3.6.8/python-3.6.8-embed-amd64.zip

Windows Explorer properly extracted: \tmp\py372, \tmp\py371, \tmp\py368.
Python 3.6.8 and 3.7.1 properly started, executed import sys; sys.exit()
Python 3.7.2 failed to start.  Please suggest proper commands if you claim these are not proper Windows commands.

Worked extra to show both 3.6 and 3.7 regressions.  If you want to claim copying 3.6.8 vcruntime140.dll to 3.7.1 as (re)packaging, then ignore v3.7.1:260ec2c36a below.  

Windows Explorer shows and 7-zip lists two vcruntime140.dll in 3.7.2.  Please ignore 7-zip if you claim that is not proper or (re)package tool and I will attach Windows Explorer screen shot.


Microsoft Windows [Version 10.0.17763.195]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>\tmp\py368\python
Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32
>>> import sys; sys.exit()

C:\>\tmp\py372\python
Fatal Python error: initfsencoding: unable to load the file system codec
zipimport.ZipImportError: can't find module 'encodings'

Current thread 0x00002614 (most recent call first):

C:\>copy \tmp\py368\vcruntime140.dll \tmp\py371\
        1 file(s) copied.

C:\>\tmp\py371\python
Python 3.7.1 (v3.7.1:260ec2c36a, Oct 20 2018, 14:57:15) [MSC v.1915 64 bit (AMD64)] on win32
>>> import sys; sys.exit()

C:\>
msg332616 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-12-27 20:39
Thanks for the extra info, and for confirming that 3.6.8 isn't affected (I hadn't tried that you, so you saved me some work :) )

This is definitely a new zipimport regression in 3.7.2. Thanks for the report.
msg332618 - (view) Author: miss-islington (miss-islington) Date: 2018-12-27 20:44
New changeset 59c2aa25ffc864bf11bf3b3973828f00e268a992 by Miss Islington (bot) (Steve Dower) in branch 'master':
bpo-35596: Fix vcruntime140.dll being added to embeddable distro multiple times. (GH-11329)
https://github.com/python/cpython/commit/59c2aa25ffc864bf11bf3b3973828f00e268a992
msg332630 - (view) Author: miss-islington (miss-islington) Date: 2018-12-28 01:04
New changeset bbf695441af9def8a121ff3e245415d9fc0bab9a by Miss Islington (bot) in branch '3.7':
bpo-35596: Fix vcruntime140.dll being added to embeddable distro multiple times. (GH-11329)
https://github.com/python/cpython/commit/bbf695441af9def8a121ff3e245415d9fc0bab9a
msg332654 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-12-28 11:52
There were no changes in zipimport between 3.7.1 and 3.7.2, and there were just few looking unrelated changes in the import machinery. Maybe this is caused by some changes in the interpreter initialization code?
msg332660 - (view) Author: miss-islington (miss-islington) Date: 2018-12-28 14:22
New changeset bbf695441af9def8a121ff3e245415d9fc0bab9a by Miss Islington (bot) in branch '3.7':
bpo-35596: Fix vcruntime140.dll being added to embeddable distro multiple times. (GH-11329)
https://github.com/python/cpython/commit/bbf695441af9def8a121ff3e245415d9fc0bab9a
msg332664 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2018-12-28 15:02
Reviewing the diff at https://github.com/python/cpython/compare/v3.7.1...v3.7.2 the only item I've spotted that seems like it could even plausibly be related is the tweak at https://github.com/python/cpython/compare/v3.7.1...v3.7.2#diff-baf5eab51059d96fb8837152dab0d1a4

(Click the Files tab to get your browser to jump to the anchor in the second link)

That's a change to the function that emits the "Fatal Python error: initfsencoding: unable to load the file system codec" message.

That change means that embedding applications could potentially be hitting the codec name resolution at https://github.com/python/cpython/blob/3.7/Python/pylifecycle.c#L1643 with the filesystem encoding set as "ascii", rather than handling that case through the "get_locale_encoding()" branch, which does the initial codec name lookup with the filesystem encoding still set to NULL (and hence falling back to the locale encoding as the default).

However, the only way that new branch could trigger is if check_force_ascii() (at https://github.com/python/cpython/blob/v3.7.2/Python/fileutils.c#L100 ) is returning 1 for some reason, which we only expect it to do on some misbehaving BSD OSes, not on Windows: https://github.com/python/cpython/pull/10233
msg332674 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-12-28 19:06
None of the code you linked is defined on Windows at all, so it can't be that.

Are any stat checks done when there's only a .pyc to import? Could it be deciding that the .pyc is out of date and then failing to find source?
msg332696 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-12-29 03:19
I took a closer look at the diff since 3.7.1, and I'm not seeing anything either. I suspect we need to step through zipimport/importlib and figure out exactly where it rejects the .pyc files in the zip.
msg332800 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2018-12-31 05:09
Ah, you're right - I missed that the ForceASCII stuff was on the non-Windows side of an ifdef so it's literally impossible for that change to affect Windows, not just highly unlikely.

It would be interesting to compare the output of `python -vv` between the working case and the non-working case, as the second level of verbosity will print out all the different candidates the two versions are considering, and which ones they're accepting. For example, here's my Linux system Python up to the point where it finishes importing the UTF-8 codec:

========================
$ python3 -vv
import _frozen_importlib # frozen
import _imp # builtin
import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
import '_warnings' # <class '_frozen_importlib.BuiltinImporter'>
import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
# installing zipimport hook
import 'zipimport' # <class '_frozen_importlib.BuiltinImporter'>
# installed zipimport hook
import '_frozen_importlib_external' # <class '_frozen_importlib.FrozenImporter'>
import '_io' # <class '_frozen_importlib.BuiltinImporter'>
import 'marshal' # <class '_frozen_importlib.BuiltinImporter'>
import 'posix' # <class '_frozen_importlib.BuiltinImporter'>
import _thread # previously loaded ('_thread')
import '_thread' # <class '_frozen_importlib.BuiltinImporter'>
import _weakref # previously loaded ('_weakref')
import '_weakref' # <class '_frozen_importlib.BuiltinImporter'>
# /usr/lib64/python3.7/encodings/__pycache__/__init__.cpython-37.pyc matches /usr/lib64/python3.7/encodings/__init__.py
# code object from '/usr/lib64/python3.7/encodings/__pycache__/__init__.cpython-37.pyc'
# trying /usr/lib64/python3.7/codecs.cpython-37m-x86_64-linux-gnu.so
# trying /usr/lib64/python3.7/codecs.abi3.so
# trying /usr/lib64/python3.7/codecs.so
# trying /usr/lib64/python3.7/codecs.py
# /usr/lib64/python3.7/__pycache__/codecs.cpython-37.pyc matches /usr/lib64/python3.7/codecs.py
# code object from '/usr/lib64/python3.7/__pycache__/codecs.cpython-37.pyc'
import '_codecs' # <class '_frozen_importlib.BuiltinImporter'>
import 'codecs' # <_frozen_importlib_external.SourceFileLoader object at 0x7f0ea616eb70>
# trying /usr/lib64/python3.7/encodings/aliases.cpython-37m-x86_64-linux-gnu.so
# trying /usr/lib64/python3.7/encodings/aliases.abi3.so
# trying /usr/lib64/python3.7/encodings/aliases.so
# trying /usr/lib64/python3.7/encodings/aliases.py
# /usr/lib64/python3.7/encodings/__pycache__/aliases.cpython-37.pyc matches /usr/lib64/python3.7/encodings/aliases.py
# code object from '/usr/lib64/python3.7/encodings/__pycache__/aliases.cpython-37.pyc'
import 'encodings.aliases' # <_frozen_importlib_external.SourceFileLoader object at 0x7f0ea6183550>
import 'encodings' # <_frozen_importlib_external.SourceFileLoader object at 0x7f0ea616e5c0>
# trying /usr/lib64/python3.7/encodings/utf_8.cpython-37m-x86_64-linux-gnu.so
# trying /usr/lib64/python3.7/encodings/utf_8.abi3.so
# trying /usr/lib64/python3.7/encodings/utf_8.so
# trying /usr/lib64/python3.7/encodings/utf_8.py
# /usr/lib64/python3.7/encodings/__pycache__/utf_8.cpython-37.pyc matches /usr/lib64/python3.7/encodings/utf_8.py
# code object from '/usr/lib64/python3.7/encodings/__pycache__/utf_8.cpython-37.pyc'
import 'encodings.utf_8' # <_frozen_importlib_external.SourceFileLoader object at 0x7f0ea6191278>
========================
msg332816 - (view) Author: wwq (wwqgtxx) Date: 2018-12-31 13:19
I have tried zipping the stdlib myself form normal version's "Python37\Lib" with all files were end with ".py"(without "site-packages" of course). And then everything work fine. Maybe the loader only reject ".pyc" file from zip load?
msg332840 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-12-31 23:56
Yes, we've established that zipimport is rejecting .pyc files now, but we need to dig through it to figure out why. I haven't had time yet, but if someone else can then don't wait for me.
msg333203 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-08 02:26
Looks like zipimport in 3.7 always rejected CHECKED_HASH pycs, while in 3.8 it always accepts them (or runs it through a validation process that passes them when the source file doesn't exist - I only confirmed by testing a build, not by walking through the new sources).

Rather than changing the old zipimport now, it's more correct to fix the embeddable ZIP build to specify UNCHECKED_HASH.
msg333204 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-08 02:31
And I assume now that the reason it broke in 3.7.2 is because the pyc mode for the embeddable distro changed. Which means the right place for tests is in a separate build that uses properly laid out Python rather than testing in the source tree (like what I have in the windows-appx-tests.yml file and Tools/msi/testrelease.bat script, but apparently also for the embeddable distro).
msg333219 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-08 10:38
New changeset 872bd2b57ce8e4ea7a54acb3934222c0e4e7276b by Steve Dower in branch 'master':
bpo-35596: Use unchecked PYCs for the embeddable distro to avoid zipimport restrictions (GH-11465)
https://github.com/python/cpython/commit/872bd2b57ce8e4ea7a54acb3934222c0e4e7276b
msg333221 - (view) Author: miss-islington (miss-islington) Date: 2019-01-08 10:56
New changeset 69f64b67e43c65c2178c865fd1be80ed07f02d3c by Miss Islington (bot) in branch '3.7':
bpo-35596: Use unchecked PYCs for the embeddable distro to avoid zipimport restrictions (GH-11465)
https://github.com/python/cpython/commit/69f64b67e43c65c2178c865fd1be80ed07f02d3c
msg333250 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-08 20:46
This is now resolved, and only through modifying the build scripts. Which means I can take the existing build and republish a fixed embeddable package without needing a new release.

Unless Ned would prefer a complete release?
msg333252 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-01-08 21:21
It seems like this need not trigger a complete new release and, ATM, I'm not aware of any other showstopper problems that would otherwise trigger an early 3.7.3.  One question would be how and where to document this change in the build artificat.  Suggestions, Steve?
msg333253 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-01-08 21:23
> This is now resolved, and only through modifying the build scripts. Which means I can take the existing build and republish a fixed embeddable package without needing a new release.

Since Python itself doesn't make, I'm ok to not change the Python release. But for pratical issues, would it be possible to use a different *filename*? For example, Python website rely a lot on CDN caching. It can be surprising to have two files with the same name but different content.
msg333254 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-01-08 21:32
CDN caching on python.org is not a problem; we know how to clear out the cache.  But I also strongly dislike silent updates of released files so I agree that names should be changed if we do end up agreeing to replace one or more files.
msg333255 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-08 21:41
I know how to purge the CDN cache, so that's not an issue. And there's no good reason to leave the old one up.

Perhaps we can just add a note to the download page and I'll post on a couple of lists? This is basically a product recall, and those are usually advertised at the point of sale.
msg333257 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-08 21:48
I can add ".post1" to the version number in the file name, but I'd still want to take down the broken one. And anyone who's generating the download URL will get a broken link, which IMO is just as bad as a broken download when we could fix it.
msg333259 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-01-08 22:03
I think we should change the name (post1 is fine), delete the original file, update the file name link in the release page (https://www.python.org/downloads/release/python-372/) to use the new name, and add a sentence or two to the release page describing the change.  If you could write up something for the page, I can add it and change the file name when ready.
msg333260 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-01-08 22:37
It would be weird if building from sources will not give the same distribution as downloaded from official site. It would be not fair to alternate distributors.

I think this is a time to release 3.7.2.1. This would be not the first time of using the fourth number in the version.
msg333264 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-01-08 23:00
> It would be weird if building from sources will not give the same distribution as downloaded from official site. It would be not fair to alternate distributors.

Yes, I agree with that in general but, as I understand it, the change here affects only how the Windows embeddable distribution is packaged.  I don't think we expect alternate distributors to produce such distributions - or do we know of such cases?  And, even if so, it's not a big deal for a third-party to pick up the change. There are parts of the PC and Mac source tree that really are intended only for building of python.org binary releases.  If the changes affected the python executables or standard library files, that would be a very different matter.  It is a trade-off; I just don't think that this is the type of change that needs to trigger a new release cycle and I don't want to go down the path of creating a new level of release.  When was the last time we had a 3.x.y.z? I don't recall one.
msg333266 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-08 23:25
Agreed. My plan is to just replace the precompiled ZIP file of the standard library in the embeddable package with one with PYCs missing the "check source" bit that the old zipimport rejects. It's as simple as a 1 line change in a supporting script in PC/layout (though the actual change I made is more significant to support other use cases).

The binary and library sources are so identical this doesn't even require a rebuild. And anyone building their own distro from source using this script will hit the issue and find this bug. The only reason I missed it was because I tested against master, not realising that the new zipimport changed behaviour here. Nobody else will be blindly releasing these packages with only tests against an incompatible versions the way we do (and now I have tests).
msg333276 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-09 03:23
I've updated the files and sent Ned the info needed to confirm and update the download page.
msg333278 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2019-01-09 04:30
Thanks, Steve.  The download page for 3.7.2 has now been updated with the URLs for the modified embeddable files, the CDN caches updated, and the original embeddable download files and their GPG signature files are no longer accessible so references to the original URLs will result in hard failures.  I considered updating the 3.7.2 blog announcement but decided against it as likely adding more confusion than it was worth.  There just aren't that many users yet of the embeddable files.
msg333290 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-01-09 06:47
> When was the last time we had a 3.x.y.z? I don't recall one.

My apologies, it seems my memory has tricked me. I thought there was on in the 3.3 branch, but it was just that the third number was bumped again just a month ago after a bugfix release.
History
Date User Action Args
2022-04-11 14:59:09adminsetnosy: + lukasz.langa
github: 79777
2019-01-09 06:47:02serhiy.storchakasetkeywords: patch, patch, patch, 3.7regression

messages: + msg333290
2019-01-09 04:30:37ned.deilysetstatus: open -> closed
messages: + msg333278

keywords: patch, patch, patch, 3.7regression
resolution: fixed
stage: patch review -> resolved
2019-01-09 03:23:07steve.dowersetkeywords: patch, patch, patch, 3.7regression

messages: + msg333276
2019-01-08 23:25:08steve.dowersetkeywords: patch, patch, patch, 3.7regression

messages: + msg333266
2019-01-08 23:00:39ned.deilysetkeywords: patch, patch, patch, 3.7regression

messages: + msg333264
2019-01-08 22:37:54serhiy.storchakasetkeywords: patch, patch, patch, 3.7regression

messages: + msg333260
2019-01-08 22:03:59ned.deilysetkeywords: patch, patch, patch, 3.7regression

messages: + msg333259
2019-01-08 21:48:23steve.dowersetkeywords: patch, patch, patch, 3.7regression

messages: + msg333257
2019-01-08 21:41:49steve.dowersetkeywords: patch, patch, patch, 3.7regression

messages: + msg333255
2019-01-08 21:32:59ned.deilysetkeywords: patch, patch, patch, 3.7regression

messages: + msg333254
2019-01-08 21:23:19vstinnersetkeywords: patch, patch, patch, 3.7regression

messages: + msg333253
2019-01-08 21:21:32ned.deilysetkeywords: patch, patch, patch, 3.7regression

messages: + msg333252
2019-01-08 20:46:03steve.dowersetkeywords: patch, patch, patch, 3.7regression

messages: + msg333250
2019-01-08 10:56:26miss-islingtonsetmessages: + msg333221
2019-01-08 10:46:07xtreaklinkissue35684 superseder
2019-01-08 10:39:44njsunlinkissue35684 superseder
2019-01-08 10:38:33miss-islingtonsetpull_requests: + pull_request10957
2019-01-08 10:38:32miss-islingtonsetpull_requests: + pull_request10958
2019-01-08 10:38:30miss-islingtonsetpull_requests: + pull_request10956
2019-01-08 10:38:05steve.dowersetmessages: + msg333219
2019-01-08 10:37:30serhiy.storchakalinkissue35684 superseder
2019-01-08 02:58:45steve.dowersetstage: test needed -> patch review
pull_requests: + pull_request10954
2019-01-08 02:58:23steve.dowersetstage: test needed -> test needed
pull_requests: + pull_request10953
2019-01-08 02:31:45steve.dowersetkeywords: patch, patch, patch, 3.7regression

messages: + msg333204
2019-01-08 02:26:35steve.dowersetkeywords: patch, patch, patch, 3.7regression
assignee: steve.dower
messages: + msg333203
2019-01-07 08:30:36schlamarsetnosy: + schlamar
2018-12-31 23:56:15steve.dowersetkeywords: patch, patch, patch, 3.7regression

messages: + msg332840
2018-12-31 13:19:05wwqgtxxsetnosy: + wwqgtxx
messages: + msg332816
2018-12-31 05:09:14ncoghlansetkeywords: patch, patch, patch, 3.7regression

messages: + msg332800
2018-12-29 03:19:01steve.dowersetkeywords: patch, patch, patch, 3.7regression

messages: + msg332696
2018-12-28 19:06:07steve.dowersetkeywords: patch, patch, patch, 3.7regression

messages: + msg332674
2018-12-28 15:02:41ncoghlansetkeywords: patch, patch, patch, 3.7regression

messages: + msg332664
2018-12-28 14:22:58miss-islingtonsetmessages: + msg332660
2018-12-28 11:52:27serhiy.storchakasetkeywords: patch, patch, patch, 3.7regression
nosy: + brett.cannon, ncoghlan, vstinner, eric.snow
messages: + msg332654

2018-12-28 06:27:00steve.dowerlinkissue35587 superseder
2018-12-28 01:04:11miss-islingtonsetmessages: + msg332630
2018-12-27 22:44:33eryksunsetkeywords: patch, patch, patch, 3.7regression
nosy: + serhiy.storchaka

type: crash
stage: patch review -> test needed
2018-12-27 20:45:07miss-islingtonsetkeywords: + patch
pull_requests: + pull_request10602
2018-12-27 20:44:58miss-islingtonsetkeywords: + patch
pull_requests: + pull_request10601
2018-12-27 20:44:49miss-islingtonsetkeywords: + patch
pull_requests: + pull_request10600
2018-12-27 20:44:29miss-islingtonsetnosy: + miss-islington
messages: + msg332618
2018-12-27 20:39:53steve.dowersetkeywords: + 3.7regression, - patch, patch

messages: + msg332616
versions: + Python 3.8
2018-12-27 20:33:31hyusetnosy: - serhiy.storchaka
type: crash -> (no value)
messages: + msg332615
2018-12-27 20:26:51steve.dowersetkeywords: + patch
stage: test needed -> patch review
pull_requests: + pull_request10595
2018-12-27 20:26:29steve.dowersetkeywords: + patch
stage: test needed -> test needed
pull_requests: + pull_request10594
2018-12-27 20:16:24steve.dowersetpriority: normal -> release blocker

nosy: + ned.deily, serhiy.storchaka
messages: + msg332612

type: crash
stage: test needed
2018-12-27 19:08:23steve.dowersetmessages: + msg332610
2018-12-27 17:35:37ned.deilysetnosy: + paul.moore, tim.golden, zach.ware, steve.dower
components: + Windows
2018-12-27 16:18:27hyucreate