classification
Title: Remove use of the stat module in the stdlib
Type: behavior Stage: test needed
Components: Library (Lib) Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: alexandre.vassalotti, barry, benjamin.peterson, brett.cannon, georg.brandl, jackdied, pitrou
Priority: low Keywords: patch

Created on 2008-05-16 04:45 by brett.cannon, last changed 2010-02-03 08:21 by brett.cannon. This issue is now closed.

Files
File name Uploaded Description Edit
posix.diff georg.brandl, 2008-06-12 22:51
Messages (19)
msg66898 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-05-16 04:45
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.
msg66963 - (view) Author: Alexandre Vassalotti (alexandre.vassalotti) * (Python committer) Date: 2008-05-16 18:56
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?
msg66964 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-05-16 19:20
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.
msg67851 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-06-08 23:22
Can't you just inherit PyStructSequence with tp_base?
msg68023 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2008-06-11 21:24
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.
msg68105 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-06-12 22:51
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.
msg69630 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-07-13 23:04
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.
msg69631 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-07-13 23:32
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.
msg69634 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-07-14 00:55
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?
msg69837 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-07-16 21:12
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 :)
msg69843 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-07-16 21:57
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
msg69846 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2008-07-16 22:05
Why deprecate the functions then?
msg69873 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2008-07-17 05:29
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?
msg72265 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-09-01 15:48
Deferring to 2.7/3.1 as discussed on the mailing list.
msg83557 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-03-14 01:11
What's the story on this?
msg83597 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-03-14 18:44
We never came to an agreement on how to handle this so it's just been
sitting here.
msg90969 - (view) Author: Jack Diederich (jackdied) * (Python committer) Date: 2009-07-27 00:26
The stat module wasn't deprecated in 3.1, so is this now a non-issue? 
If not, is it related to issue#1820?
msg90970 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-07-27 00:32
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.
msg98779 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2010-02-03 08:21
OK, this ain't ever going to happen, so I am just going to close this issue.
History
Date User Action Args
2010-02-03 08:21:16brett.cannonsetstatus: open -> closed
resolution: wont fix
messages: + msg98779
2009-07-27 00:32:55brett.cannonsetpriority: critical -> low

messages: + msg90970
stage: test needed
2009-07-27 00:26:15jackdiedsetnosy: + jackdied
messages: + msg90969
2009-03-14 18:44:13brett.cannonsetmessages: + msg83597
2009-03-14 01:11:39pitrousetnosy: + pitrou
messages: + msg83557
2008-09-01 15:48:05benjamin.petersonsetpriority: release blocker -> critical
messages: + msg72265
versions: + Python 3.1, Python 2.7, - Python 2.6
2008-08-21 14:54:43benjamin.petersonsetpriority: critical -> release blocker
2008-07-17 05:29:48brett.cannonsetmessages: + msg69873
2008-07-16 22:05:36georg.brandlsetmessages: + msg69846
2008-07-16 21:57:45brett.cannonsetmessages: + msg69843
2008-07-16 21:12:01georg.brandlsetmessages: + msg69837
2008-07-14 00:55:31brett.cannonsetmessages: + msg69634
2008-07-13 23:32:19brett.cannonsetmessages: + msg69631
2008-07-13 23:04:41brett.cannonsetmessages: + msg69630
2008-06-12 22:51:46georg.brandlsetfiles: + posix.diff
keywords: + patch
messages: + msg68105
nosy: + georg.brandl
2008-06-11 21:25:02barrysetpriority: release blocker -> critical
nosy: + barry
messages: + msg68023
2008-06-08 23:22:17benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg67851
2008-05-16 19:20:59brett.cannonsetmessages: + msg66964
2008-05-16 18:56:32alexandre.vassalottisetnosy: + alexandre.vassalotti
messages: + msg66963
2008-05-16 04:45:57brett.cannonlinkissue2775 dependencies
2008-05-16 04:45:44brett.cannoncreate