Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify the behavior of listdir(fd) in both code and documentation #59381

Closed
larryhastings opened this issue Jun 25, 2012 · 12 comments
Closed

Clarify the behavior of listdir(fd) in both code and documentation #59381

larryhastings opened this issue Jun 25, 2012 · 12 comments
Assignees
Labels
release-blocker type-feature A feature request or enhancement

Comments

@larryhastings
Copy link
Contributor

BPO 15176
Nosy @birkenfeld, @ncoghlan, @larryhastings
Files
  • larry.listdir.clarification.1.diff: First patch clarifying matters around our mysterious friend listdir.
  • larry.listdir.clarification.4.diff: Patch Update Python Software Foundation Copyright Year. #4, hopefully Rietveld likes this one.
  • 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 = 'https://github.com/larryhastings'
    closed_at = <Date 2012-06-25.11:50:45.262>
    created_at = <Date 2012-06-25.03:39:57.701>
    labels = ['type-feature', 'release-blocker']
    title = 'Clarify the behavior of listdir(fd) in both code and documentation'
    updated_at = <Date 2012-06-25.11:50:45.261>
    user = 'https://github.com/larryhastings'

    bugs.python.org fields:

    activity = <Date 2012-06-25.11:50:45.261>
    actor = 'larry'
    assignee = 'larry'
    closed = True
    closed_date = <Date 2012-06-25.11:50:45.262>
    closer = 'larry'
    components = []
    creation = <Date 2012-06-25.03:39:57.701>
    creator = 'larry'
    dependencies = []
    files = ['26140', '26150']
    hgrepos = []
    issue_num = 15176
    keywords = ['patch']
    message_count = 12.0
    messages = ['163885', '163887', '163890', '163891', '163895', '163896', '163908', '163921', '163930', '163932', '163944', '163951']
    nosy_count = 5.0
    nosy_names = ['georg.brandl', 'ncoghlan', 'larry', 'Arfrever', 'python-dev']
    pr_nums = []
    priority = 'release blocker'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue15176'
    versions = ['Python 3.3']

    @larryhastings
    Copy link
    Contributor Author

    When you pass in a file descriptor as the first argument to listdir, its output is a list of strings, not a list of bytes. This should be mentioned in the documentation. It's also worth making a pass over the other functions accepting an fd.

    As it happens, the code that implements this behavior is obtuse. So I propose also modifying it to be more intelligible.

    @larryhastings larryhastings self-assigned this Jun 25, 2012
    @larryhastings larryhastings added the type-feature A feature request or enhancement label Jun 25, 2012
    @larryhastings
    Copy link
    Contributor Author

    Maybe the correct fix for this is to change the interface?

    os.listdir(path, *, dir_fd=None)

    Then we'll pick up the return type (str/bytes) from the path variable.

    It would make bpo-15177 even easier too, should we go down that route.

    @ncoghlan
    Copy link
    Contributor

    +1 for changing the API for any cases where the filesystem path is also used to determine the return type - given that we stuffed this up for the rmtree implementation, I expect end users would be prone to making exactly the same mistake.

    Retaining the ability to control the return type explicitly even when pass a descriptor would be a *lot* cleaner than other possibilities (which would all involve a bunch of manual encoding and decoding with os.fsencode() and os.fsdecode()).

    @larryhastings
    Copy link
    Contributor Author

    Nick, how do you feel specifically about listdir(path, *, dir_fd)? I'm mentally exhausted from the past couple of days and have temporarily lost the ability to infer.

    @larryhastings
    Copy link
    Contributor Author

    Nevermind, I'm an idiot. fdopendir doesn't support dir_fd as a separate path, so listdir can't support it either.

    There's an unwritten property of the os module on a POSIX system: all the functions are essentially-atomic. This is useful and should not be broken lightly.

    I'll make a patch clarifying the behavior of listdir.

    @ncoghlan
    Copy link
    Contributor

    Don't forget to point people to os.fsencode() if they actually wanted bytes, or os.fsdecode() if they already have bytes and want to convert them to text.

    @larryhastings
    Copy link
    Contributor Author

    My first cut at a patch. Made the logic in posix_listdir easy to follow, fixed up the docstring and docs. Posted in the correct issue this time.

    (And Nick: I thought of that independently :D )

    @larryhastings
    Copy link
    Contributor Author

    Removed "do we have os.listdir" checks from the unit tests. Yes, Virginia, we always have os.listdir in Python 3.3.

    @larryhastings
    Copy link
    Contributor Author

    Regenerated patch to make Reitveld happy.

    @larryhastings
    Copy link
    Contributor Author

    GRAHH HULK SMASH
    Regenerating again, because I wasn't actually fresh enough last time.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jun 25, 2012

    New changeset 8172d8e907a4 by Larry Hastings in branch 'default':
    Issue bpo-15176: Clarified behavior, documentation, and implementation
    http://hg.python.org/cpython/rev/8172d8e907a4

    @larryhastings
    Copy link
    Contributor Author

    Good news, everyone!

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    release-blocker type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants