Add .path method/property to tempfile.* for a pathlib.Path

[8527e2fb-3575-4b29-bda6-022dc83e1251]

BPO	43480
Nosy	@pxeger

^{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 2021-03-12.15:49:24.927>
labels = ['type-feature', 'library', '3.10']
title = 'Add .path method/property to tempfile.* for a pathlib.Path'
updated_at = <Date 2021-03-12.15:49:24.927>
user = 'https://github.com/pxeger'

bugs.python.org fields:

activity = <Date 2021-03-12.15:49:24.927>
actor = 'pxeger'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-03-12.15:49:24.927>
creator = 'pxeger'
dependencies = []
files = []
hgrepos = []
issue_num = 43480
keywords = []
message_count = 1.0
messages = ['388540']
nosy_count = 1.0
nosy_names = ['pxeger']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue43480'
versions = ['Python 3.10']

Linked PRs

• gh-104466
• gh-114765

[8527e2fb-3575-4b29-bda6-022dc83e1251]

It would be nice to have a .path method or property on tempfile.NamedTemporaryFile, tempfile.TemporaryDirectory which produces a pathlib.Path of their .name attribute, so one can use the modern interface directly.

I think a method would be more appropriate than a property because you're explicitly allocating a new object (unless you use @functools.cached_property or similar to have a shared object between successive calls)

I can do a PR.

[barneygale]

Proposal: make NamedTemporaryFile and TemporaryDirectory subclasses of Path. We'd need to deprecate and remove the existing name attribute first as it means something different to pathlib's name. IMO it should be replaced with __fspath__(), so this code:

with NamedTemporaryFile() as tf:
    path = tf.name

Could be replaced with:

with NamedTemporaryFile() as tf:
    path = os.fspath(tf)

[AlexWaygood]

...Is the deprecation cycle for the name attribute really worth the hassle, and pain to users? I agree that that's how I might do it if I were writing tempfile from scratch today. But the proposed PR has fairly nice semantics, in my opinion, and we could implement it now without having to force any users to modify their code that's currently working today.

While I love it and generally reach for it in my code, it's also the case that not all users will need or want pathlib's interface -- some might be happy with string paths and os.path. For these users, reimplementing these classes as Path subclasses might lead to an unnecessary performance regression.

[barneygale]

I think you're right Alex, and I'm probably being too idealistic. Thanks for the feedback!

[barneygale]

I'm still not convinced about this feature request, though. Is this not already easy and explicit?

# currently possible
with NamedTemporaryFile() as tf:
    temppath = Path(tf)

# proposed
with NamedTemporaryFile() as tf:
    temppath = tf.path

I don't think the name .path makes it as obvious that this is a rich path object. os.DirEntry also has a .path attribute, but it's a string, not a pathlib.Path object.

[AlexWaygood]

I'm still not convinced about this feature request, though. Is this not already easy and explicit?

# currently possible
with NamedTemporaryFile() as tf:
    temppath = Path(tf)

# proposed
with NamedTemporaryFile() as tf:
    temppath = tf.path

I don't think the name .path makes it as obvious that this is a rich path object. os.DirEntry also has a .path attribute, but it's a string, not a pathlib.Path object.

Yes, I think that's a much better objection. For me, I use the TemporaryDirectory()/Path combination a fair bit, and so it's annoying to have to repeat the same boilerplate-y "and now we convert the string to a path immediately" thing over and over again. But that certainly doesn't justify an unclear/confusing API, and it's hard to know what a good API would be here :)

[barneygale]

I've just realised that these classes aren't os.PathLike. If we add an __fspath__() method to them, then this becomes possible:

with NamedTemporaryFile() as tf:
    temppath = Path(tf)

I prefer this to a .path attribute.

[barneygale]

I'm going to adjust the title and remove the topic-pathlib tag, because I think there's very little prospect of exposing pathlib.Path objects in tempfile APIs. We may still wish to make some tempfile classes os.PathLike.

[Salamandar]

I'm struggling with a library that might return either a Path or a TemporaryDict, and having one inheriting the other would really be interesting.