[ python-Bugs-1157665 ] RuntimeWarning: unfiltered RuntimeWarning
Bugs item #1157665, was opened at 2005-03-06 12:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157665&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: RuntimeWarning: unfiltered RuntimeWarning Initial Comment: after updating to latest cvs version for 2.4 i'v got an error while performing full test on win xp: test test_warnings failed -- Traceback (most recent call last): File "s:\binw\py24\lib\test\test_warnings.py", line 57, in test_warn_specific_category warnings.warn(text, category) File "s:\binw\py24\lib\warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "s:\binw\py24\lib\warnings.py", line 92, in warn_explicit raise message RuntimeWarning: unfiltered RuntimeWarning on other side - coll, only one failing test as compared to previous version: 254 tests OK. 1 test failed: test_warnings 35 tests skipped: test__locale test_aepack test_al test_applesingle test_cd test_cl test_commands test_curses test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp test_imgfile test_ioctl test_linuxaudiodev test_macfs test_macostools test_mhlib test_nis test_openpty test_ossaudiodev test_plistlib test_poll test_posix test_pty test_pwd test_resource test_scriptpackages test_signal test_sunaudiodev test_threadsignals test_timing Those skips are all expected on win32. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157665&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Bugs item #1153075, was opened at 2005-02-27 21:55 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Armin Rigo (arigo) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. -- >Comment By: Michael Hudson (mwh) Date: 2005-03-06 18:47 Message: Logged In: YES user_id=6656 I think the attached fixes all this. What it does: check the return value of PySequence_Tuple (duh). Check that the returned sequence contains only types or old-style classes. Checks that the solid_base of each type in the returned sequence is a supertype of the solid_base of type being built. Adds a few tests. The error messages are a bit inscrutable. I find it hard to care. Assigning to Armin for the first look. Might want to get Guido to look at it too. When Armin and I talked about this on IRC we found a few oddities in the general area, but I don't know if it's worth opening a new bug report for them... -- Comment By: Michael Hudson (mwh) Date: 2005-03-03 09:50 Message: Logged In: YES user_id=6656 Certainly some more checking of what the user-defined MRO contains would be good -- check the attached, which dumps core at class definition time... -- Comment By: Armin Rigo (arigo) Date: 2005-03-03 09:34 Message: Logged In: YES user_id=4771 The PyXxx_Check() macros are #defined with PyObject_TypeCheck(). Should we change all these #defines to use a new PyObject_LayoutCheck() or something, and document to C extension writers that they should also switch to the new function? More generally, should we review *all* usages of PyObject_TypeCheck() and decide if they really meant that or PyObject_LayoutCheck()? Do we care about types that are solid subclasses of 'int' but don't have it in their MRO? Should we just forget the whole idea and sanity-check the user-defined mro, which after all would just add another strange undocumented condition to typeobject.c? :-) -- Comment By: Michael Hudson (mwh) Date: 2005-03-02 20:11 Message: Logged In: YES user_id=6656 Hmm, yeah, that works. It wasn't totally clear to me that the user couldn't maliciously influence tp_base, but I don't think they can... A helper function is presumably in order, unless PyType_IsSubtype should be changed. -- Comment By: Armin Rigo (arigo) Date: 2005-03-02 17:03 Message: Logged In: YES user_id=4771 To solve the problem, as hinted in the title of this tracker, I think that PyXxx_Check() should simply not trust any mro. What PyInt_Check() really means at the C level is to check if an object memory layout is compatible with PyIntObject. This is easy to figure out by walking the "solid base" chain, tp_base. As a side note, PyPy gives the same error as Python 2.2. However, both in PyPy and in Python 2.2, you can still build an instance of the strange class X as follows: >>> x = object.__new__(X) Still, all the methods of x are resolved via the dict type. In PyPy we get a clean TypeError because the methods thus found don't apply to non-dict objects. In Python 2.2 you can crash the interpreter just as in more recent Python releases, e.g. with x[5]=6. -- Comment By: Michael Hudson (mwh) Date: 2005-03-01 20:18 Message: Logged In: YES user_id=6656 I wonder if Guido owes Armin a beer (read typeobject.c around line 5230). Well, not really, but it's that code that is making the difference. However, reversing the order of dict and object is sufficient to make 2.2 crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting code chopped out which gives the error jelper observes on the original). I wonder what to do about this. Removing the ability to customize the mro from user code is one obvious approach -- I don't know how much code uses this feature though. --
[ python-Bugs-1157901 ] xml.dom.minidom.Node.removeChild() doesn't remove
Bugs item #1157901, was opened at 2005-03-06 22:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kempka (mkempka) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom.minidom.Node.removeChild() doesn't remove Initial Comment: There seems to be a constellation where xml.dom.minidom.Node.removeChild() doesn't remove childs properly. I found this bug in 2.3.4 and it is still in: Python 2.3.5 (#2, Feb 9 2005, 00:38:15) [GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2 I attached 3 files, the dombug.py demonstrates the problem: First, I iterate over all children of a specific element, check their tag name and remove them using removeChild() and then child.unlink(). After the elements are removed I iterate again, do the same check for a tag and find there are still elements in there. That is, there are still elements in there when I parse the file errorintroducer.xml. When I parse the file errorfree.xml the elements are all removed. The difference between the xml files is the carriage return after each closing tag. Since to my knowledge both xml files are well-formed I would expect in both cases that all elements are removed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1157901 ] xml.dom.minidom.Node.removeChild() doesn't remove
Bugs item #1157901, was opened at 2005-03-06 22:17 Message generated for change (Comment added) made by mkempka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kempka (mkempka) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom.minidom.Node.removeChild() doesn't remove Initial Comment: There seems to be a constellation where xml.dom.minidom.Node.removeChild() doesn't remove childs properly. I found this bug in 2.3.4 and it is still in: Python 2.3.5 (#2, Feb 9 2005, 00:38:15) [GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2 I attached 3 files, the dombug.py demonstrates the problem: First, I iterate over all children of a specific element, check their tag name and remove them using removeChild() and then child.unlink(). After the elements are removed I iterate again, do the same check for a tag and find there are still elements in there. That is, there are still elements in there when I parse the file errorintroducer.xml. When I parse the file errorfree.xml the elements are all removed. The difference between the xml files is the carriage return after each closing tag. Since to my knowledge both xml files are well-formed I would expect in both cases that all elements are removed. -- >Comment By: Matthias Kempka (mkempka) Date: 2005-03-06 22:24 Message: Logged In: YES user_id=736381 so.. this form posts the error report with uploading files...interesting... Anyway, the output I get when running the program with errorintroducer.xml is: > python dombug.py found element 1 .. removed found element 3 .. removed found element 5 .. removed ---everything removed from timerList[0]--- found Element2 found Element4 found Element6 imho it should be, as it is with errorfree.xml: found element 1 .. removed found element 2 .. removed found element 3 .. removed found element 4 .. removed found element 5 .. removed found element 6 .. removed ---everything removed from timerList[0]--- -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157901&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121416 ] zip incorrectly and incompletely documented
Bugs item #1121416, was opened at 2005-02-12 12:18
Message generated for change (Comment added) made by aisaac0
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Alan (aisaac0)
Assigned to: Raymond Hettinger (rhettinger)
Summary: zip incorrectly and incompletely documented
Initial Comment:
See the zip documentation:
http://www.python.org/dev/doc/devel/lib/built-in-funcs.html
i. documentation refers to sequences not to iterables
ii. The other problem is easier to explain by example.
Let it=iter([1,2,3,4]).
What is the result of zip(*[it]*2)?
The current answer is: [(1,2),(3,4)],
but it is impossible to determine this from the docs,
which would allow [(1,3),(2,4)] instead (or indeed
other possibilities).
The example expresses the solution to an actual need,
so the behavior should be documented or warned against,
I believe.
--
>Comment By: Alan (aisaac0)
Date: 2005-03-06 16:36
Message:
Logged In: YES
user_id=1025672
> The OP's problem should be left as a code smell
indicating a misuse of functionals.
Left how? I did not propose any change in behavior
or intent. I only asked that the behavior shd either
i. be determinate and documented, or
ii. be acknowledged in the docs as indeterminate
as a caution not to rely on current behavior
which seems natural but I take it not guaranteed.
(Ideally the docs would link to a helpful explanation
of why it is appropriate not to guarantee the
behavior.)
The fact that this question came up is evidence,
IMO, that the docs are incomplete. (I'm not the
only one who was puzzled.)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-16 20:10
Message:
Logged In: YES
user_id=80475
The first sentence becomes even less clear with the "in the
same order" wording.
The note about truncating to the shortest sequence length is
essential and should not have been dropped.
The py2.4 change note is in a standard form
(\versionchanged{} following the explanation of current
behavior) and should not have been altered.
The part that addresses the OP's concern is too specific to
the his one example and is unclear unless you know about
that example. The wording is discomforting, doesn't add new
information, and is somewhat not obvious in its meaning.
I suggest simply changing "sequence" to "iterable".
There is no sense in stating that the order of combination
is undefined. It doesn't help with the OP's original desire
to be able to predict the outcome of the example. However,
it does have the negative effect of making a person question
whether they've understood the preceding description of what
actually zip() does do.
zip() is about lockstep iteration and the docs should serve
those users as straight-forwardly as possible. The OP's
issue on the other hand only comes up when trying funky
iterator magic -- adding a sentence about undefined ordering
doesn't help one bit.
There is a lesson in all this. These tools were borrowed
from the world of functional programming which is all about
programming that is free of side-effects. The OP's problem
should be left as a code smell indicating a misuse of
functionals.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-02-16 19:03
Message:
Logged In: YES
user_id=593130
I agree that the zip doc needs improvement. Confusion will
continue until it is. Here is my suggested rewrite:
---
zip([iterable1, ...])
Return a list of tuples, where the i-th tuple contains the i-th
element from each input in the same order as the inputs.
With no arguments, return an empty list (before 2.4, a
TypeError was raised instead.) With a single input, return a
list of 1-tuples. With multiple inputs, the output length is
that of the shorted input. When multiple input lengths are
equal, zip(i1, ...) is similar to map(None, i1, ...), but there is
no padding when otherwise. The result of zipping a volatile
iterable with itself is undefined. New in 2.0.
---
There you have it. More information is about 15% fewer
words. The reduction came from greatly condensing the
overwordy sentence about obsolete behavior into a
parenthetical comment. For comparison, here is the current
version.
---
zip( [seq1, ...])
This function returns a list of tuples, where the i-th tuple
contains the i-th element from each of the argument
sequences. The returned list is truncated in length to the
length of the shortest argument sequence. When there are
multiple argument sequences which ar
[ python-Bugs-1156412 ] add documentation for __new__
Bugs item #1156412, was opened at 2005-03-03 22:00 Message generated for change (Settings changed) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) >Assigned to: Greg Ward (gward) Summary: add documentation for __new__ Initial Comment: 3.3.1 Basic customization does not document __new__. Proposed addition: __new__(cls[, ...]) Called to create a new instance of the class. __new__ is a staticmethod (special-cased so you need not declare it as such) that takes the class to be created as the first argument. The remaining arguments are those passed to the class constructor expression. The return value of __new__ should be the new object instance. Typical usage is to create a new instance of the class by invoking the superclass's __new__ method using "super(BaseClass, cls).__new__([...])" with appropriate arguments, modifying the returned instance if necessary, and then returning it. If the returned value is an instance of "cls" (the first argument to __new__), its __init__ will be invoked. Note that you need not return an instance of "cls", but if you don't, the new instance's __init__ method will not be invoked. The __new__ staticmethod is intended mainly to allow modification of immutable types like int, long, float, str and tuple. -- Comment By: Steven Bethard (bediviere) Date: 2005-03-05 15:30 Message: Logged In: YES user_id=945502 Looks pretty good to me. Only one change: "super(currentclass, cls).__new__([...])" should look like: "super(currentclass, cls).__new__(cls[, ...])" Sorry I didn't catch this earlier. But, since it's a staticmethod, of course you need to pass 'cls' manually. -- Comment By: Greg Ward (gward) Date: 2005-03-05 11:34 Message: Logged In: YES user_id=14422 Here's an alternative text -- a bit tighter, hopefully a tad more accurate and clearer: __new__(cls[, ...]) Called to create a new instance of class 'cls'. __new__() is a static method (special-cased so you need not declare it as such) that takes the class to create an instance of as the first argument. The remaining arguments are those passed to the object constructor expression. The return value of __new__() should be the new object instance. Typical usage is to create a new instance of the class by invoking the superclass's __new__() method using "super(currentclass, cls).__new__([...])" with appropriate arguments, modifying the returned instance if necessary, and then returning it. If the returned value is an instance of 'cls', its __init__() will be invoked like "__init__(self[, ...])", where the extra arguments are the same as were passed to __new__(). You do need not to return an instance of 'cls', but if you do not, the new instance's __init__() method will not be invoked. __new__() is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation. -- Comment By: Greg Ward (gward) Date: 2005-03-05 11:11 Message: Logged In: YES user_id=14422 I think that last paragraph can be written even more concisely: "The __new__ staticmethod is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation." Also, the usual convention when talking about methods and functions is to write "__new__()", not "__new__". At least that's how the 2.3.3 language ref which I have on my PC looks. Finally, this bug is in the "Python 2.5" group -- surely there's no harm in checking this in to the 2.4 docs and merging forward? -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-03-04 23:02 Message: Logged In: YES user_id=1038590 Close, but the phrasing's a bit awkward. Getting rid of the commas seems to fix that: "The __new__ staticmethod is intended mainly to allow you to customize instance creation in a subclass of an immutable type (like int, long, float, complex, str, unicode, or tuple)." -- Comment By: Steven Bethard (bediviere) Date: 2005-03-04 15:19 Message: Logged In: YES user_id=945502 Good point. How about: "The __new__ staticmethod is intended mainly to allow you, in a subclass of an immutable type (like int, long, float, complex, str, unicode, or tuple), to customize instance creation." -- Comment By: Oren Tirosh (orenti) Date: 2005-03-04 13:05 Message: Logged In: YES user_id=562624 "The __new__ staticmethod is intended mainly to allow modification of immutable types like int, lon
[ python-Bugs-1158005 ] unixccompiler.py should deal with env in linker
Bugs item #1158005, was opened at 2005-03-06 16:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Edward Moy (edwardmoy) Assigned to: Nobody/Anonymous (nobody) Summary: unixccompiler.py should deal with env in linker Initial Comment: When the linker command begins with env, plus some environment settings, and when the target is c++, the modified linker command should place the c++ command in the proper place, which is not the first element of the linker array. The following seems to be fix the problem: --- unixccompiler.py.orig 2004-08-29 09:45:13.0 -0700 +++ unixccompiler.py2005-03-06 16:36:05.0 -0800 @@ -172,7 +172,12 @@ else: linker = self.linker_so[:] if target_lang == "c++" and self.compiler_cxx: -linker[0] = self.compiler_cxx[0] +i = 0 +if os.path.basename(linker[0]) == "env": +i = 1 +while '=' in linker[i]: +i = i + 1 +linker[i] = self.compiler_cxx[0] self.spawn(linker + ld_args) except DistutilsExecError, msg: raise LinkError, msg -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1158005&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-818006 ] ossaudiodev object does not support common readonly attrs
Bugs item #818006, was opened at 2003-10-05 02:30 Message generated for change (Settings changed) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dave Cinege (dcinege) Assigned to: Greg Ward (gward) >Summary: ossaudiodev object does not support common readonly attrs Initial Comment: fin = ossaudiodev.open(dspfile, 'r') if fin.closed == True: AttributeError: closed -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-05 15:48 Message: 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. -- Comment By: Dave Cinege (dcinege) Date: 2005-03-05 13:08 Message: 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. -- Comment By: Dave Cinege (dcinege) Date: 2003-10-05 16:32 Message: 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. -- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-05 16:16 Message: 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. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-818006 ] ossaudiodev object does not support common readonly attrs
Feature Requests item #818006, was opened at 2003-10-05 02:30 Message generated for change (Comment added) made by gward You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470 >Category: Extension Modules >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dave Cinege (dcinege) Assigned to: Greg Ward (gward) Summary: ossaudiodev object does not support common readonly attrs Initial Comment: fin = ossaudiodev.open(dspfile, 'r') if fin.closed == True: AttributeError: closed -- >Comment By: Greg Ward (gward) Date: 2005-03-06 20:41 Message: 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.texrev 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.texrev 1.14 Lib/test/output/test_ossaudiodev rev 1.3 -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-05 15:48 Message: 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. -- Comment By: Dave Cinege (dcinege) Date: 2005-03-05 13:08 Message: 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. -- Comment By: Dave Cinege (dcinege) Date: 2003-10-05 16:32 Message: 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. -- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-05 16:16 Message: 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. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-818006 ] ossaudiodev object does not support common readonly attrs
Feature Requests item #818006, was opened at 2003-10-05 02:30 Message generated for change (Comment added) made by dcinege You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=818006&group_id=5470 Category: Extension Modules Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Dave Cinege (dcinege) Assigned to: Greg Ward (gward) Summary: ossaudiodev object does not support common readonly attrs Initial Comment: fin = ossaudiodev.open(dspfile, 'r') if fin.closed == True: AttributeError: closed -- >Comment By: Dave Cinege (dcinege) Date: 2005-03-06 21:36 Message: 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 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. -- Comment By: Greg Ward (gward) Date: 2005-03-06 20:41 Message: 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.texrev 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.texrev 1.14 Lib/test/output/test_ossaudiodev rev 1.3 -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-05 15:48 Message: 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. -- Comment By: Dave Cinege (dcinege) Date: 2005-03-05 13:08 Message: 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. -- Comment By: Dave Cinege (dcinege) Date: 2003-10-05 16:32 Message: 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. -- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-05 16:16 Message: 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. " C
[ python-Bugs-1157665 ] RuntimeWarning: unfiltered RuntimeWarning
Bugs item #1157665, was opened at 2005-03-06 06:11 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157665&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: RuntimeWarning: unfiltered RuntimeWarning Initial Comment: after updating to latest cvs version for 2.4 i'v got an error while performing full test on win xp: test test_warnings failed -- Traceback (most recent call last): File "s:\binw\py24\lib\test\test_warnings.py", line 57, in test_warn_specific_category warnings.warn(text, category) File "s:\binw\py24\lib\warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "s:\binw\py24\lib\warnings.py", line 92, in warn_explicit raise message RuntimeWarning: unfiltered RuntimeWarning on other side - coll, only one failing test as compared to previous version: 254 tests OK. 1 test failed: test_warnings 35 tests skipped: test__locale test_aepack test_al test_applesingle test_cd test_cl test_commands test_curses test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp test_imgfile test_ioctl test_linuxaudiodev test_macfs test_macostools test_mhlib test_nis test_openpty test_ossaudiodev test_plistlib test_poll test_posix test_pty test_pwd test_resource test_scriptpackages test_signal test_sunaudiodev test_threadsignals test_timing Those skips are all expected on win32. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1157665&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
