mailbox does not support new Path object

[loz-hurst]

BPO	41026
Nosy	@ethanfurman, @srinivasreddy, @remilapeyre, @loz-hurst
PRs	bpo-41026: Path-like object support for mailbox module #20976 bpo-41026: Add PathLike object support to Mailbox constructor  #20990

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2020-06-18.16:45:48.340>
labels = ['type-feature', 'library', '3.10']
title = 'mailbox does not support new Path object'
updated_at = <Date 2021-09-08.00:54:18.234>
user = 'https://github.com/loz-hurst'

bugs.python.org fields:

activity = <Date 2021-09-08.00:54:18.234>
actor = 'ethan.furman'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2020-06-18.16:45:48.340>
creator = 'LimaAlphaHotel'
dependencies = []
files = []
hgrepos = []
issue_num = 41026
keywords = ['patch']
message_count = 6.0
messages = ['371823', '371825', '371829', '371853', '371879', '401350']
nosy_count = 4.0
nosy_names = ['ethan.furman', 'thatiparthy', 'remi.lapeyre', 'LimaAlphaHotel']
pr_nums = ['20976', '20990']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue41026'
versions = ['Python 3.10']

[loz-hurst]

The mailbox library, in particular the Mailbox class I'm using, does not support the new Path object requiring a clumsy mbx = Maildir(str(some_path_obj)) to use with a Path instance.

It currently blows up if passed a Path directly (does not support startswith) - perhaps a simple solution is to coerce whatever is passed into a string inside __init__?

Could this support be added?

I feel that strings representing paths should be discouraged as a general principal now we have a truly portable object to represent paths, and supporting Path in all places it makes logical sense (without breaking backwards compatibility, if implemented as I suggest with coercion by str(...) inside the module) in the core library seems like a good thing to me.

[loz-hurst]

Sorry, should read "in particular the Maildir class I'm using"...

Same applies to mbox, however.

[remilapeyre]

Hi Laurence, Maildir predates pathlib so it's not surprising it hasn't been updated yet. Could you open a PR to add this?

BTW, you should use os.fspath() instead of str() here.

[loz-hurst]

Hi Rémi,

I understand why it is the case, I just thought it would be a nice enhancement and quick win to add the support.

RE "you should use os.fspath() instead of str()": I'm following in the pathlib docuementation (https://docs.python.org/3/library/pathlib.html):

The string representation of a path is the raw filesystem path itself (in native form, e.g. with backslashes under Windows), which you can pass to any function taking a file path as a string:
>>>
>>> p = PurePath('/etc')
>>> str(p)
'/etc'
>>> p = PureWindowsPath('c:/Program Files')
>>> str(p)
'c:\\Program Files'

Is the pathlib documentation wrong/out-of-date? I Googled your suggestion of os.fspath and found https://www.python.org/dev/peps/pep-0519/ which reads like the pathlib docs need correcting?

I'm trying to setup a build environment to create a PR for this issue as I type...

Thanks,

Laurence

[loz-hurst]

I have patched the module to accept a path-like object, however it still follows the pre-pathlib ways of doing things elsewhere. There's quite a bit of work to do to modernise the whole module, but this patch at least adds support to pass a Path to the classes it provides so external code can use pathlib and interface with it.

[ethanfurman]

The problem with using str() on a path argument is that the argument may not be a str, nor a pathlib object, but str() will still create a string out of it, leading to difficult bugs.

The documentation for pathlib also predates the addition of os.fspath().