| msg66898 - (view) |
Author: Brett Cannon (brett.cannon) *  |
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) * |
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) * |
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) * |
Date: 2008-06-08 23:22 |
| Can't you just inherit PyStructSequence with tp_base? |
|
|
| msg68023 - (view) |
Author: Barry A. Warsaw (barry) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2008-07-16 22:05 |
| Why deprecate the functions then? |
|
|
| msg69873 - (view) |
Author: Brett Cannon (brett.cannon) * |
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) * |
Date: 2008-09-01 15:48 |
| Deferring to 2.7/3.1 as discussed on the mailing list. |
|
|
| msg83557 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-03-14 01:11 |
| What's the story on this? |
|
|
| msg83597 - (view) |
Author: Brett Cannon (brett.cannon) * |
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) * |
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) * |
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) * |
Date: 2010-02-03 08:21 |
| OK, this ain't ever going to happen, so I am just going to close this issue. |
|
|