fin = ossaudiodev.open(dspfile, 'r') 
if fin.closed == True: 
AttributeError: closed 
 

Logged In: YES 
user_id=593130

From Lib Ref 14.11 ossaudiodev "open( [device, ]mode) 
Open an audio device and return an OSS audio device object.
"
Checking http://python.org/doc/current/lib/ossaudio-device-
objects.html 14.11.1 Audio Device Objects I can find no 
mention of closed attribute or indeed of any attributes other 
than methods.  Why were you expecting such?  If report is a 
mistake, please close.

Logged In: YES 
user_id=314434

Please see: 
http://python.org/doc/current/lib/bltin-file-objects.html 
""" 
File objects also offer a number of other interesting attributes. 
These are not required for file-like objects, but should be 
implemented if they make sense for the particular object.  
"" 
 
"Should be" when they "make sense"  is my rational for 
reporting this as a bug. 
 
I found this by trying to convert existing code from a normal 
open of /dev/dsp to ossaudiodev.open(), that IMO "should" 
have worked.  : P 
 
Other attributes that "should be" implemented  (mode and 
name) because they "make sense" may also be missing...I 
haven't checked.  
 

Logged In: YES 
user_id=314434

That was the point of the bug report. It has no closed 
or other file-like attributes. According the python docs 
then and current: 
'File objects also offer a number of other interesting 
attributes. These are not required for file-like objects, 
but should be implemented if they make sense for 
the particular object. ' 
 
I take that to mean these attributes are mandatory, 
unless it does not make sense to implement them. 
 
In the case of file-like Audio Device Objects, they 
make sense, and thus should be there.  
 
Either this statement of file-like object policy is a bug, 
or the lack of such attributes in Audio Device Objects 
is a bug.  
 

Logged In: YES 
user_id=593130

I am not sure who your last comment is aimed at.  As near as I 
can tell, Greg merely updated the group to Py2.4, implying that 
this issue is still relevant.

In Pythonese, should is advisory; only must is mandatory.  So I 
see this as a request for a pre-approved enhancement.  Since 
ossaudiodevice directly wraps an OS open file descripter, rather 
than a Python file object, the patch is more than a triviality.

Logged In: YES 
user_id=14422

For the record, I consider this an enhancement, not a bug
fix.  As the previous commenter pointed out, "should" is not
mandatory.  But it's a useful feature, and I have no
objection to adding it on a stable branch.  So I've checked
it in on 2.4:

Modules/ossaudiodev.c             rev 1.35.4.1
Lib/test/test_ossaudiodev.py      rev 1.8.10.1
Doc/lib/libossaudiodev.tex        rev 1.12.4.2
Lib/test/output/test_ossaudiodev  rev 1.2.12.1

and merged to the trunk:

Modules/ossaudiodev.c             rev 1.36
Lib/test/test_ossaudiodev.py      rev 1.9
Doc/lib/libossaudiodev.tex        rev 1.14
Lib/test/output/test_ossaudiodev  rev 1.3

Logged In: YES 
user_id=314434

'As the previous commenter pointed out, "should" is 
not mandatory. ' 
 
Don't want to nit-pick...but in common usage and 
especially legalese (which the world is unfortuntaly 
infected with, that being laws) 'shall' is interperted to 
mean an absolute. Should, the past tense of 'shall' , 
therefor inherits the definition of shall...which is: 
1 archaic a : will have to : MUST b : will be able to : 
CAN 
2 a -- used to express a command or exhortation 
<you shall go> b -- used in laws, regulations, or 
directives to express what is mandatory 
 
Thus, I think it's a poor idea that the use of 'should', or 
'shall', should not imply what is mandatory. After all 
they are a synonym for 'must'! 
 
If the language 'may be' was used instead of 'should 
be' I would not have reported this as a bug.  
 
I think as an issue of documentation policy, this 
should be...uhmmm...I mean...must  be changed.  : )  
I don't know where I would raise this issue.  
 

Logged In: YES 
user_id=14422

If you wish to dispute the meaning of "should", I can only
refer you to RFC 2119.  I'm no grammarian, but this RFC is
quite explicit that "should" != "shall", which certainly
agrees with my understanding of English.

If you think this should be formally addressed by Python
documentation standards, you should probably post to
doc-sig@python.org.  I suspect you'll be met with a wall of
indifference, but you never know.

Logged In: YES 
user_id=593130

According to my dictionary, while should can be the past tense 
of shall, it is also a helper (auxiliary) word, as in 'should be' that 
can have various shades of meaning: obligation, propriety, 
expectation, likelihood, and others similar to would.  I personally 
understand it as desired and proper, in between may and must. I 
also believe that the standard for acceptance of library 
submissions has risen in the years since this module went in.

Logged In: YES 
user_id=14422

Oops: since this is a new feature, I should not have added
it on the 2.4 branch.  This will only be in Python 2.5, not
2.4.1.  Reverted changes in:
Modules/ossaudiodev.c rev 1.35.4.2
Lib/test/test_ossaudiodev.py rev 1.8.10.2
Doc/lib/libossaudiodev.tex rev 1.12.4.3