[issue44159] mimetypes - "strict" on Windows
New submission from Norman Lorrain : On Windows 10 machine, unit tests show this error: 0:05:10 load avg: 3.24 [221/427/1] test_mimetypes failed test test_mimetypes failed -- Traceback (most recent call last): File "D:\github\cpython\lib\test\test_mimetypes.py", line 289, in test_guess_type eq(type_info, "I don't know anything about type foo.pic") AssertionError: 'type: image/pict encoding: None' != "I don't know anything about type foo.pic" - type: image/pict encoding: None + I don't know anything about type foo.pic The test is verifying that the code reports `image/pict` as a *non-standard* MIME type: def test_guess_type(self): eq = self.assertEqual type_info = self.mimetypes_cmd("-l", "foo.pic") eq(type_info, "type: image/pict encoding: None") type_info = self.mimetypes_cmd("foo.pic") eq(type_info, "I don't know anything about type foo.pic") Looking in my registry, I see the entry for `.pic` [HKEY_CLASSES_ROOT\.pic] @="QuickTime.pic" "Content Type"="image/pict" ...etc The module seems to report everything it finds in the registry as "strict" -- components: Library (Lib) messages: 393826 nosy: Norman Lorrain priority: normal severity: normal status: open title: mimetypes - "strict" on Windows type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue44159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44159] mimetypes - "strict" on Windows
Norman Lorrain added the comment: Possible solution is to read the Windows Registry entries, assigning those entries as "strict=False". Unit tests pass with this change: diff --git a/Lib/mimetypes.py b/Lib/mimetypes.py index 018793c4f0..dd2bddf064 100644 --- a/Lib/mimetypes.py +++ b/Lib/mimetypes.py @@ -350,7 +350,7 @@ def init(files=None): if files is None or _db is None: db = MimeTypes() if _winreg: -db.read_windows_registry() +db.read_windows_registry(strict = False) if files is None: files = knownfiles -- ___ Python tracker <https://bugs.python.org/issue44159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12403] Mention sys.displayhook in code module docs and the compile builtin docs
Change by Norman Lorrain : -- keywords: +patch nosy: +Norman Lorrain nosy_count: 7.0 -> 8.0 pull_requests: +24834 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/26217 ___ Python tracker <https://bugs.python.org/issue12403> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28661] Fix code example in Python 3.5 telnetlib documentation
Norman Lorrain added the comment: How about a simpler example (this relies on an outside service, fwiw) See attached file. -- nosy: +Norman Lorrain Added file: https://bugs.python.org/file50124/weather.py ___ Python tracker <https://bugs.python.org/issue28661> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38825] shutil.disk_usage - Lacking documentation
Norman Lorrain added the comment: This issue is a bit dated, but here goes: On Unix, the function `statvfs()` is called. `path` should be a path on a mounted filesystem (it should not be a device). On Windows, the function `GetDiskFreeSpaceExW()` is called. `path` is any directory on a disk volume. Looking through the rest of the page, no other functions get into such specifics; maybe this is outside the scope of the document. Maybe the issue should be closed. -- nosy: +Norman Lorrain ___ Python tracker <https://bugs.python.org/issue38825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38825] shutil.disk_usage - Lacking documentation
Norman Lorrain added the comment: Something like this: .. impl-detail:: Where applicable (e.g. Unix) *path* must point to somewhere on a **mounted** filesystem partition. On Sun, 11 Jul 2021 at 16:18, Tyler Crompton wrote: > > Tyler Crompton added the comment: > > Not even the kernel knows how much space is available on a nonmounted > partition. It doesn't know much beyond the fact that it exists and where it > exists. There exist tools that can analyze nonmounted partitions, but these > will vary by filesystem and operating system. If someone wants to implement > solutions for the most common filesystem-OS combinations, then that might > be helpful. > > But considering that no one has done that or even asked for it yet, I'm > not sure that doing so is worth the effort. So I agree that documenting it > is the best approach. It should be documented such that the limitations are > mentioned, not necessarily how it's implemented. If explaining which system > calls are used helps explain the limitations, then so be it. Additionally, > as far as I'm concerned, there's no reason to restrict other Python > implementations from implementing functionality for nonmounted disks. So > the limitations should be described as being CPython-specific, akin to what > is done for `readline.set_auto_history`. > > -- > nosy: +tylercrompton > > ___ > Python tracker > <https://bugs.python.org/issue38825> > ___ > -- ___ Python tracker <https://bugs.python.org/issue38825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com