Skip to content

Remove use of the stat module in the stdlib #47123

Closed

Description

@brettcannon
BPO 2874
Nosy @warsaw, @brettcannon, @birkenfeld, @pitrou, @jackdied, @avassalotti, @benjaminp
Files
  • posix.diff
  • 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 = <Date 2010-02-03.08:21:16.268>
    created_at = <Date 2008-05-16.04:45:44.868>
    labels = ['type-bug', 'library']
    title = 'Remove use of the stat module in the stdlib'
    updated_at = <Date 2010-02-03.08:21:16.266>
    user = 'https://github.com/brettcannon'

    bugs.python.org fields:

    activity = <Date 2010-02-03.08:21:16.266>
    actor = 'brett.cannon'
    assignee = 'none'
    closed = True
    closed_date = <Date 2010-02-03.08:21:16.268>
    closer = 'brett.cannon'
    components = ['Library (Lib)']
    creation = <Date 2008-05-16.04:45:44.868>
    creator = 'brett.cannon'
    dependencies = []
    files = ['10608']
    hgrepos = []
    issue_num = 2874
    keywords = ['patch']
    message_count = 19.0
    messages = ['66898', '66963', '66964', '67851', '68023', '68105', '69630', '69631', '69634', '69837', '69843', '69846', '69873', '72265', '83557', '83597', '90969', '90970', '98779']
    nosy_count = 7.0
    nosy_names = ['barry', 'brett.cannon', 'georg.brandl', 'pitrou', 'jackdied', 'alexandre.vassalotti', 'benjamin.peterson']
    pr_nums = []
    priority = 'low'
    resolution = 'wont fix'
    stage = 'test needed'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue2874'
    versions = ['Python 3.1', 'Python 2.7']

    Activity

    1. brettcannon commented on May 16, 2008

      @brettcannon
      MemberAuthor

      The stat module is slated to go in Python 3.0, but that can't happen until
      all uses of the module are gone. This will require moving over to using
      the named tuple features of os.stat() along with adding methods to the
      object that the stat module has as functions.

    2. added
      stdlibStandard Library Python modules in the Lib/ directory
      type-bugAn unexpected behavior, bug, or error
      on May 16, 2008
    3. avassalotti commented on May 16, 2008

      @avassalotti
      Member

      Brett wrote:

      This will require moving over to using the named tuple features of
      os.stat() along with adding methods to the object that the stat module
      has as functions.

      How do you add new methods to a PyStructSequence?

    4. brettcannon commented on May 16, 2008

      @brettcannon
      MemberAuthor

      On Fri, May 16, 2008 at 11:56 AM, Alexandre Vassalotti
      <report@bugs.python.org> wrote:

      Alexandre Vassalotti <alexandre@peadrop.com> added the comment:

      Brett wrote:
      > This will require moving over to using the named tuple features of
      > os.stat() along with adding methods to the object that the stat module
      > has as functions.

      How do you add new methods to a PyStructSequence?

      No clue. =) Might not be doable. In the end a custom class might be
      needed that supports indexes.

    5. benjaminp commented on Jun 8, 2008

      @benjaminp
      Contributor

      Can't you just inherit PyStructSequence with tp_base?

    6. warsaw commented on Jun 11, 2008

      @warsaw
      Member

      Perhaps collections.namedtuple() can be used with a custom subclass?

      In any case, it's not worth holding up the first beta for this. We can
      fix it after beta. Knocking this down to critical.

    7. birkenfeld commented on Jun 12, 2008

      @birkenfeld
      Member

      This is a proof of concept how to add methods to a structseq type.

      Of course PyStructSequence_InitType could also get a companion
      PyStructSequence_InitTypeEx that takes a PyMethodDef* array.

    8. brettcannon commented on Jul 13, 2008

      @brettcannon
      MemberAuthor

      Another option is to eliminate the use of PyStructSequence and handle
      the creation of a named tuple and a class with the methods in os.py.
      Then stat() can just return a tuple and the Python code can create the
      instances from that.

    9. brettcannon commented on Jul 13, 2008

      @brettcannon
      MemberAuthor

      On Sun, Jul 13, 2008 at 4:04 PM, Brett Cannon <report@bugs.python.org> wrote:

      Brett Cannon <brett@python.org> added the comment:

      Another option is to eliminate the use of PyStructSequence and handle
      the creation of a named tuple and a class with the methods in os.py.
      Then stat() can just return a tuple and the Python code can create the
      instances from that.

      Although I noticed that what fields are available are affected by
      compile-time info, so that might not be the best solution.

    10. brettcannon commented on Jul 14, 2008

      @brettcannon
      MemberAuthor

      I just finished taking Georg's idea and fleshing it out. Problem is that
      when I went to change the docs for 'stat', I noticed how many other
      function in the os module rely on the stat module for its constants.
      Should we move the constants over to the os module? Add an os.stats
      module? Or only deprecate the functions?

    11. birkenfeld commented on Jul 16, 2008

      @birkenfeld
      Member

      I don't like the name "os.stats". The os module is already so full of
      constants and functions that one could argue the few from stat won't
      hurt anymore :)

    12. brettcannon commented on Jul 16, 2008

      @brettcannon
      MemberAuthor

      On Wed, Jul 16, 2008 at 2:12 PM, Georg Brandl <report@bugs.python.org> wrote:

      Georg Brandl <georg@python.org> added the comment:

      I don't like the name "os.stats". The os module is already so full of
      constants and functions that one could argue the few from stat won't
      hurt anymore :)

      Yeah, I was thinking it might work out to just deprecate the functions
      and leave the module around for the constants.

      -Brett

    13. birkenfeld commented on Jul 16, 2008

      @birkenfeld
      Member

      Why deprecate the functions then?

    14. brettcannon commented on Jul 17, 2008

      @brettcannon
      MemberAuthor

      On Wed, Jul 16, 2008 at 3:05 PM, Georg Brandl <report@bugs.python.org> wrote:

      Georg Brandl <georg@python.org> added the comment:

      Why deprecate the functions then?

      If they are made into methods on the object returned by os.stat(),
      what is the point of having them around? Or are you suggesting to skip
      adding the methods?

    15. benjaminp commented on Sep 1, 2008

      @benjaminp
      Contributor

      Deferring to 2.7/3.1 as discussed on the mailing list.

    16. pitrou commented on Mar 14, 2009

      @pitrou
      Member

      What's the story on this?

    17. brettcannon commented on Mar 14, 2009

      @brettcannon
      MemberAuthor

      We never came to an agreement on how to handle this so it's just been
      sitting here.

    18. jackdied commented on Jul 27, 2009

      @jackdied
      Contributor

      The stat module wasn't deprecated in 3.1, so is this now a non-issue?
      If not, is it related to issue#1820?

    19. brettcannon commented on Jul 27, 2009

      @brettcannon
      MemberAuthor

      At this point it is a nice idea that no one wants to deal with to make
      happen. Dropping the priority but leaving open for now until I get around
      to making a final decision as to whether to just give up on this to
      finally allow closure on PEP-3108 once profile/cProfile are merged.

    20. brettcannon commented on Feb 3, 2010

      @brettcannon
      MemberAuthor

      OK, this ain't ever going to happen, so I am just going to close this issue.

    21. transferred this issue fromon Apr 10, 2022
    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

      stdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions