[issue11016] Add S_ISDOOR to the stat module

STINNER Victor added the comment: > I have created a C implementation of the stat module for Python 3.4. Oh, your C module is called "stat", as the "stat" module implemented in Python (Lib/stat.py). What is your plan? Replace completly the Python module with the C module? It may be nice to kee

[issue11016] Add S_ISDOOR to the stat module

STINNER Victor added the comment: If we use the C language, I would prefer to only expose what does really exist, and not add "fake" functions like: +#ifndef S_ISDOOR +# define S_ISDOOR(mode) 0 +#endif So in: +static PyMethodDef stat_methods[] = { +{"S_ISDIR", stat_S_ISDIR, METH

[issue11016] Add S_ISDOOR to the stat module

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue11016] Add S_ISDOOR to the stat module

Changes by Christian Heimes : -- keywords: +patch Added file: http://bugs.python.org/file30153/statmodule.patch ___ Python tracker ___ ___

[issue11016] Add S_ISDOOR to the stat module

R. David Murray added the comment: "Cannot be implemented correctly in Python" is a darned good reason :) -- ___ Python tracker ___ __

[issue11016] Add S_ISDOOR to the stat module

Antoine Pitrou added the comment: > We've been *adding* python implementations for other modules, so I > don't see why we would remove this one. Well, the one reason is that the C constants aren't accessible from Python code. Once the constants are there, the rest is so trivial that it doesn't r

[issue11016] Add S_ISDOOR to the stat module

R. David Murray added the comment: We've been *adding* python implementations for other modules, so I don't see why we would remove this one. -- nosy: +r.david.murray ___ Python tracker ___

[issue11016] Add S_ISDOOR to the stat module

Charles-François Natali added the comment: > We've been *adding* python implementations for other modules, so I don't see > why we would remove this one. Because it's buggy, and cannot be implemented correctly in python. -- ___ Python tracker

[issue11016] Add S_ISDOOR to the stat module

Charles-François Natali added the comment: Christian, could you post it as a mercurial diff for review? Also, it would maybe be better to rename this issue to "rewrite stat module in C". Shouldn't we also remove the Python version? -- nosy: +neologix __

[issue11016] Add S_ISDOOR to the stat module

Christian Heimes added the comment: I have created a C implementation of the stat module for Python 3.4. It implements all current features, handling for DOOR, PORT, WHT and a fix for #17913. The first half of the file has lots of #ifndef checks. I'm not sure if they are really required. I gu

[issue11016] Add S_ISDOOR to the stat module

Christian Heimes added the comment: I have done some research. The POSIX 1.b extensions aren't used on any supported system (neither Linux nor BSD, Solaris or AIX). random...@fastmail.us has compiled a list of even more file types: Heirloom toolchest "ls" supports: http://heirloom.cvs.sourcef

[issue11016] Add S_ISDOOR to the stat module

Christian Heimes added the comment: The stat module (or whatever it is going to be in Python 3.4) is missing more checks than S_ISDOOR: # Solaris S_ISDOOR() S_ISPORT() # POSIX 1.b real-time extension S_ISMSG() S_ISSEM() S_ISSHM() # whiteout, translucent file systems S_ISWHT -- nosy:

[issue11016] Add S_ISDOOR to the stat module

Changes by Jesús Cea Avión : -- versions: +Python 3.4 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue11016] Add S_ISDOOR to the stat module

Jesús Cea Avión added the comment: After reviewing the code, I agree with Martin v. Löwis that "stat.py" is a joke. Neither can we trust the numerical constants (each OS is free to choose a different meaning) neither the code in "filemode()" can cope with modes with more than a bit active (lik

[issue11016] Add S_ISDOOR to the stat module

Martin v. Löwis added the comment: >> Apparently, contributor have the illusion that the values they put >> into the file are somehow standardized, when they are actually not. > > Are there actual bugs with that or is it merely a theoretical concern? Neither, nor (i.e. it's in the middle). I'm

[issue11016] Add S_ISDOOR to the stat module

Antoine Pitrou added the comment: > Apparently, contributor have the illusion that the values they put > into the file are somehow standardized, when they are actually not. Are there actual bugs with that or is it merely a theoretical concern? -- __

[issue11016] Add S_ISDOOR to the stat module

Martin v. Löwis added the comment: Am 31.01.2011 12:46, schrieb Jesús Cea Avión: > > Jesús Cea Avión added the comment: > > Martin, I guess "stat" deprecation could require a few years and it > would be an extra incompatibility burden between 2.7 and 3.x. > > Beside the symbolic constants, w

[issue11016] Add S_ISDOOR to the stat module

Jesús Cea Avión added the comment: Martin, I guess "stat" deprecation could require a few years and it would be an extra incompatibility burden between 2.7 and 3.x. Beside the symbolic constants, why would you see "stat" deprecated?. -- ___ Python

[issue11016] Add S_ISDOOR to the stat module

Martin v. Löwis added the comment: > Martin, what if C posix module (or whoever) would export the symbolic > constants, and update "stat.py" to use those symbolic constants?. > > Do you think that would be an improvement?. Improvement compared to what? The status quo? Certainly. Compared to a

[issue11016] Add S_ISDOOR to the stat module

Jesús Cea Avión added the comment: Martin, what if C posix module (or whoever) would export the symbolic constants, and update "stat.py" to use those symbolic constants?. Do you think that would be an improvement?. -- ___ Python tracker

[issue11016] Add S_ISDOOR to the stat module

Martin v. Löwis added the comment: Am 26.01.2011 14:14, schrieb Jesús Cea Avión: > > Jesús Cea Avión added the comment: > > Antoine, I am not talking about python, I am talking about the UNIX > standarization process. In particular, how a new flag (for > filesystems) in an OS can be "skipped"

[issue11016] Add S_ISDOOR to the stat module

Martin v. Löwis added the comment: > I am thinking about how to manage OS's with no support for doors. > Instead of conditionally compile the new STAT, I would rather have > the function always available, but returning FALSE when the OS > doesn't support doors. But what happen if you mount a Sol

[issue11016] Add S_ISDOOR to the stat module

Jesús Cea Avión added the comment: I am looking at Linux :-). Anyway the feedback has been very useful. I will implement this as soon as mercurial switch is done. -- ___ Python tracker __

[issue11016] Add S_ISDOOR to the stat module

John Levon added the comment: Jesus, yes, it's totally possible that POSIX might define: (stat.S_IFSOCK + stat.S_IFIFO) to mean something other than S_IDOOR. However, the POSIX committee is always careful to respect existing usage. It's vanishingly unlikely that any attempt to do this would ac

[issue11016] Add S_ISDOOR to the stat module

Jesús Cea Avión added the comment: Antoine, I am not talking about python, I am talking about the UNIX standarization process. In particular, how a new flag (for filesystems) in an OS can be "skipped" and not being reused for some other purpuse in other OS. Off topic for python, but curious t

[issue11016] Add S_ISDOOR to the stat module

Antoine Pitrou added the comment: > But now I am wondering... Which organization defines flags like > S_IFSOCK or S_IFIFO?. Posix members?. I am worried about flag > collision between OSs. They are defined unconditionally in Lib/stat.py. > For instance, if DOORS were a real flag defined in Sol

[issue11016] Add S_ISDOOR to the stat module

Jesús Cea Avión added the comment: Given the behaviour of Solaris DOORS, the flags selected are very cleverly chosen. Sensible engineering :). But now I am wondering... Which organization defines flags like S_IFSOCK or S_IFIFO?. Posix members?. I am worried about flag collision between OSs.

[issue11016] Add S_ISDOOR to the stat module

Antoine Pitrou added the comment: > I do know, but when you are working inside a zone, I am not sure you > can count of that file being always present. Syslog even could be > disabled or not available inside a zone. Then you can just skip the test. > I am thinking about how to manage OS's with

[issue11016] Add S_ISDOOR to the stat module

Jesús Cea Avión added the comment: I do know, but when you are working inside a zone, I am not sure you can count of that file being always present. Syslog even could be disabled or not available inside a zone. I am thinking about how to manage OS's with no support for doors. Instead of cond

[issue11016] Add S_ISDOOR to the stat module

Antoine Pitrou added the comment: > Thanks for the feature request. It seems trivial to implement, but not > trivial to test :). You can test against an existing file, such as "/var/run/syslog_door" (given its name, it is unlikely to be anything other than a door) --

[issue11016] Add S_ISDOOR to the stat module

Jesús Cea Avión added the comment: Thanks for the feature request. It seems trivial to implement, but not trivial to test :). I assign this to myself. I will work on it after Mercurial migration is finished. Getting impatient :). -- assignee: -> jcea ___

[issue11016] Add S_ISDOOR to the stat module

New submission from Antoine Pitrou : Solaris has an additional kind of special files named doors. The standard headers define the following macro: #define S_ISDOOR(mode) (((mode)&0xF000) == 0xd000) Perhaps it would be nice to include the equivalent in the stat module. (although funnily