[issue39832] Modules with decomposable characters in module name not found on macOS

[Norbert]

New submission from Norbert :

Modules whose names contain characters that are in precomposed form but can be 
decomposed in Normalization Form D can’t be found on macOS.


To reproduce:

1. Download and unzip the attached file Modules.zip. This produces a directory 
Modules with four Python source files.

2. In Terminal, go to the directory that contains Modules.

3. Run "python3 -m Modules.Import".


Expected behavior:

The following lines should be generated:
Maerchen
Märchen


Actual behavior:

The first line, “Maerchen” is generated, but then an error occurs:
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/runpy.py", 
line 193, in _run_module_as_main
   return _run_code(code, main_globals, None,
 File 
"/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/runpy.py", 
line 86, in _run_code
   exec(code, run_globals)
 File "/Users/business/tmp/pyimports/Modules/Import.py", line 5, in 
   from Modules.Märchen import hello2
ModuleNotFoundError: No module named 'Modules.Märchen'


Evaluation:

In the source file Modules/Import.py, the name of the module “Märchen” is 
written with the precomposed character U+00E4. The file name Märchen.py uses 
the decomposed character sequence U+0061 U+0308 instead. Macintosh file names 
commonly use a variant of Normalization Form D in file names – the old file 
system HFS enforces this, and while APFS doesn’t, the Finder still generates 
file names in this form. U+00E4 and U+0061 U+0308 are canonically equivalent, 
so they should be treated as equal in module loading.


Tested configuration:

CPython 3.8.2
macOS 10.14.6

--
components: Interpreter Core
files: Modules.zip
messages: 363224
nosy: Norbert
priority: normal
severity: normal
status: open
title: Modules with decomposable characters in module name not found on macOS
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48944/Modules.zip

___
Python tracker 
<https://bugs.python.org/issue39832>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39832] Modules with decomposable characters in module name not found on macOS

[Norbert]

Norbert  added the comment:

Yes, if the Python runtime caches file names and determines based on the cache 
whether a file exists, then it needs to normalize both the file names in the 
cache and the name of the file it’s looking for. As far as I know, both HFS and 
APFS do this themselves when asked for a file by name, but if you ask for a 
list of available files, they don’t know what you’re comparing against.

I don’t think codecs would be involved here; I’d use unicodedata.normalize with 
either NFC or NFD – doesn’t matter which one.

--

___
Python tracker 
<https://bugs.python.org/issue39832>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41672] imaplib: wrong return type documented

[Norbert Cyran]

New submission from Norbert Cyran :

Documentation on IMAP4 class specifies wrong return type of its commands:

Each command returns a tuple: (type, [data, ...]) where type is 
usually 'OK' or 'NO', and data is either the text from the command 
response, or mandated results from the command. Each data is either a 
string, or a tuple. If a tuple, then the first part is the header of 
the response, and the second part contains the data (ie: ‘literal’ 
value).

That's not valid for Python 3, as IMAP4 commands return bytes-like objects in 
data, what's shown in the example before::
  >>> from imaplib import IMAP4
  >>> with IMAP4("domain.org") as M:
  ... M.noop()
  ...
  ('OK', [b'Nothing Accomplished. d25if65hy903weo.87'])

That of course can cause a lot of trouble due to incompatibility of strings and 
bytes. Suggested change is to replace string occurences to bytes-like object. I 
don't know what types are returned in case when tuple is returned though.

--
assignee: docs@python
components: Documentation
messages: 376143
nosy: docs@python, norbertcyran
priority: normal
severity: normal
status: open
title: imaplib: wrong return type documented
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 
<https://bugs.python.org/issue41672>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41672] imaplib: wrong return type documented

[Norbert Cyran]

Norbert Cyran  added the comment:

@ericsmith

Sure, I can create a PR and link it here when I'm done.

--

___
Python tracker 
<https://bugs.python.org/issue41672>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41672] imaplib: wrong return type documented

[Norbert Cyran]

Change by Norbert Cyran :


--
keywords: +patch
pull_requests: +21261
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/22207

___
Python tracker 
<https://bugs.python.org/issue41672>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41672] imaplib: wrong return type documented

[Norbert Cyran]

Norbert Cyran  added the comment:

@corona10 PR added: https://github.com/python/cpython/pull/22207

--

___
Python tracker 
<https://bugs.python.org/issue41672>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com