You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remove use of the stat module in the stdlib #47123
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=Noneclosed_at=<Date2010-02-03.08:21:16.268>created_at=<Date2008-05-16.04:45:44.868>labels= ['type-bug', 'library']
title='Remove use of the stat module in the stdlib'updated_at=<Date2010-02-03.08:21:16.266>user='https://github.com/brettcannon'
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.
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.
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.
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.
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.
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?
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 :)
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.
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?
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.
Activity
brettcannon commentedon May 16, 2008
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.
avassalotti commentedon May 16, 2008
Brett wrote:
How do you add new methods to a PyStructSequence?
brettcannon commentedon May 16, 2008
On Fri, May 16, 2008 at 11:56 AM, Alexandre Vassalotti
<report@bugs.python.org> wrote:
No clue. =) Might not be doable. In the end a custom class might be
needed that supports indexes.
benjaminp commentedon Jun 8, 2008
Can't you just inherit PyStructSequence with tp_base?
warsaw commentedon Jun 11, 2008
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.
birkenfeld commentedon Jun 12, 2008
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.
brettcannon commentedon Jul 13, 2008
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.
brettcannon commentedon Jul 13, 2008
On Sun, Jul 13, 2008 at 4:04 PM, Brett Cannon <report@bugs.python.org> wrote:
Although I noticed that what fields are available are affected by
compile-time info, so that might not be the best solution.
brettcannon commentedon Jul 14, 2008
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?
birkenfeld commentedon Jul 16, 2008
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 :)
brettcannon commentedon Jul 16, 2008
On Wed, Jul 16, 2008 at 2:12 PM, Georg Brandl <report@bugs.python.org> wrote:
Yeah, I was thinking it might work out to just deprecate the functions
and leave the module around for the constants.
-Brett
birkenfeld commentedon Jul 16, 2008
Why deprecate the functions then?
brettcannon commentedon Jul 17, 2008
On Wed, Jul 16, 2008 at 3:05 PM, Georg Brandl <report@bugs.python.org> wrote:
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?
benjaminp commentedon Sep 1, 2008
Deferring to 2.7/3.1 as discussed on the mailing list.
pitrou commentedon Mar 14, 2009
What's the story on this?
brettcannon commentedon Mar 14, 2009
We never came to an agreement on how to handle this so it's just been
sitting here.
jackdied commentedon Jul 27, 2009
The stat module wasn't deprecated in 3.1, so is this now a non-issue?
If not, is it related to issue#1820?
brettcannon commentedon Jul 27, 2009
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.
brettcannon commentedon Feb 3, 2010
OK, this ain't ever going to happen, so I am just going to close this issue.