GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Pathlib is_* functions do not fail in case of errno=EIO · Issue #160959 · python/cpython

Pathlib is_* functions do not fail in case of errno=EIO #160959

New issue
Copy link
New issue
Copy link
Closed as not planned
Closed as not planned
Pathlib is_* functions do not fail in case of errno=EIO#160959
Copy link
Labels
pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is providedtopic-pathlibtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or errortype-featureA feature request or enhancementA feature request or enhancement

Description

@socketpair
socketpair
opened on Oct 30, 2026
Issue body actions

Bug report

Pathlib functions do not fall with exception if they can not check. For example, .is_mount() will say False on mountpoint with failed FS. The most correct way - is to raise an Exception is check can not be done. EIO means "I don't know", not "this is not a mountpoint". The same with other is_* (like is_dir(), is_file() и is_symlink())

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux


The same: mkdir(exist_ok=True) - will silently return on EIO. Any EIO must not be swallowed, as I think.

Activity

  1. socketpair
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    on Oct 30, 2026
  2. socketpair
    changed the title [-]Ptahlib function do not fail in case of errno=EIO[/-] [+]Pathlib is_* functions do not fail in case of errno=EIO[/+] on Oct 30, 2026
  3. aisk
    added
    topic-pathlib
    on Oct 30, 2026
  4. picnixz commented on Oct 30, 2026

    @picnixz
    picnixz
    on Oct 30, 2026
    Member
    More actions

    This will be a breaking change. Is the behavior inconsistent with other functions or oa.path.* ones?

  5. picnixz
    added
    type-featureA feature request or enhancementA feature request or enhancement
    pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
    on Oct 30, 2026
  6. socketpair commented on Oct 30, 2026

    @socketpair
    socketpair
    on Oct 30, 2026
    ContributorAuthor
    More actions

    @picnixz

    Yes, it is inconsistent with pathlib's own previous behavior.

    Up to 3.13, Path.exists()/is_*() suppressed only errors that genuinely mean
    "no" (ENOENT, ENOTDIR, EBADF, ELOOP); EIO, EACCES etc. propagated. In 3.14
    (gh-101357 / gh-118243) this was widened to all OSError as a side effect of
    a Windows performance optimization. So the breaking change has already
    happened; restoring the old behavior would fix a regression.

    The principle: if the check could not be done, there is no correct boolean
    answer, so raise. EIO means "I don't know", not "no". Returning False hides
    real problems like a failing disk or a dead NFS/FUSE mount.

    Proposal: restore the strict behavior by default. If that's not acceptable,
    add a keyword-only strict= parameter (as eryksun suggested in gh-101357).

  7. picnixz commented on Oct 30, 2026

    @picnixz
    picnixz
    on Oct 30, 2026
    Member
    More actions

    Yes, it is inconsistent with pathlib's own previous behavior.

    I meant, is it inconsistent with existing behavior of other functions. What is preferrable is whether this changes with respect to os.path.is* functions, i.e. os.path.islink can raise EIO while Pathlib.islink cannot? what's important to me is that os.path* functions and pathlib do the same unless told otherwise.

    I'm ok with a strict keyword though (we have some strict policy that was added in 3.15). However, we won't change 3.14 I believe. AFAICT, ismount() was not affected by that change and forwarded to os.path.ismount.

    cc @zooba @barneygale @serhiy-storchaka @encukou

  8. ronaldoussoren commented on Oct 30, 2026

    @ronaldoussoren
    ronaldoussoren
    on Oct 30, 2026
    Contributor
    More actions

    The documentation mentions this is an intentional change and consistent with the os.path.is* functions:

    Changed in version 3.14: The methods given above now return False instead of raising any OSError exception from the operating system. In previous versions, some kinds of OSError exception are raised, and others suppressed. The new behaviour is consistent with os.path.exists(), os.path.isdir(), etc. Use stat() to retrieve the file status without suppressing exceptions.

    Reacted by Коренберг Марк
  9. socketpair commented on Oct 31, 2026

    @socketpair
    socketpair
    on Oct 31, 2026
    ContributorAuthor
    More actions

    That's pity :(

    So, I suggest strict= option for these functions. And probably the same for os.path.xxxx

  10. picnixz commented on Oct 31, 2026

    @picnixz
    picnixz
    on Oct 31, 2026
    Member
    More actions

    Please open a separate issue for that to indicate which functions should be modified. Strict policy already exists in some os.path functions (added in 3.15) so we may have some conflicts of notations.

    Reacted by Petr Viktorin
  11. picnixz
    closed this as not plannedon Oct 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    pendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is providedtopic-pathlibtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or errortype-featureA feature request or enhancementA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.