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.

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?

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.

Can't you just inherit PyStructSequence with tp_base?

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.

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.

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.

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.

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 :)

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

Why deprecate the functions then?

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?

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

What's the story on this?

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

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

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.

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