Re: [Python-Dev] httplib and bad response chunking
[me, on 25 July] > I have > discovered other hypothetical cases of bad chunking that cause httplib > to go into an infinite loop or block forever on socket.readline(). > Should we worry about those cases as well, despite not having seen them > happen in the wild? More annoying, I can reproduce the "block forever" > case using a real socket, but not using the StringIO-based FakeSocket > class in test_httplib. [John J Lee] > They have been seen in the wild :-) > > http://python.org/sf/1411097 Thanks -- that was really all the encouragement I needed to keep banging away at this bug. Did you look at the crude attempt at testing for this bug that I hacked into test_httplib.py? I posted it to bug #1486335 here: http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=186245&aid=1486335 The idea is simple: put various chunked responses into strings and then feed those strings to HTTPConnection. The trouble is that StringIO does not behave the same as a real socket: where HTTPResponse fails one way reading from a real socket (eg. infinite loop), it fails differently (or not at all) reading from a StringIO. Makes testing with the FakeSocket class in test_httplib.py problematic. Maybe the right way to test httplib is to spawn a server process (thread?) to listen on some random port, feed various HTTP responses at HTTPConnection/HTTPResponse, and see what happens. I'm not sure how to do that portably, though. Well, I'll see if I can whip up a Unix-y solution and see if anyone knows how to make it portable. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Be careful: sometimes, you're only standing on the shoulders of idiots. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] httplib and bad response chunking
So I accidentally discovered the other day that httplib does not handle a particular type of mangled HTTP response very well. In particular, it tends to blow up with an undocumented ValueError when the server screws up "chunked" encoding. I'm not the first to discover this, either: see http://www.python.org/sf/1486335 . HTTP 1.1 response chunking allows clients to know how many bytes of response to expect for dynamic content, i.e. when it's not possible to include a "Content-length" header. A chunked response might look like this: 0005\r\nabcd\n\r\n0004\r\nabc\n\r\n0\r\n\r\n which means: 0x0005 bytes in first chunk, which is "abcd\n" 0x0004 bytes in second chunk, which is "abc\n" Each chunk size is terminated with "\r\n"; each chunk is terminated with "\r\n"; end of response is indicated by a chunk of 0 bytes, hence the "\r\n\r\n" at the end. Details in RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1 Anyways, what I discovered in the wild the other day was a response like this: 0005\r\nabcd\n\r\n0004\r\nabc\n\r\n\r\n i.e. the chunk-size for the terminating empty chunk was missing. This cause httplib.py to blow up with ValueError because it tried to call int(line, 16) assuming that 'line' contained a hex number, when in fact it was the empty string. Oops. IMHO the minimal fix is to turn ValueError into HTTPException (or a subclass thereof); httplib should not raise ValueError just because some server sends a bad response. (The server in question was Apache 2.0.52 running PHP 4.3.9 sending a big hairy error page because the database was down.) Where I'm getting hung up is how far to test this stuff. I have discovered other hypothetical cases of bad chunking that cause httplib to go into an infinite loop or block forever on socket.readline(). Should we worry about those cases as well, despite not having seen them happen in the wild? More annoying, I can reproduce the "block forever" case using a real socket, but not using the StringIO-based FakeSocket class in test_httplib. Anyways, I've cobbled together a crude hack to test_httplib.py that exposes the problem: http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=186245&aid=1486335 Feedback welcome. (Fixing the inadvertent ValueError is trivial, so I'm concentrating on getting the tests right first.) Oh yeah, my patch is relative to the 2.4 branch. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I don't believe there really IS a GAS SHORTAGE.. I think it's all just a BIG HOAX on the part of the plastic sign salesmen -- to sell more numbers!! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dropping externally maintained packages (Was: Please stop changing wsgiref on the trunk)
[Guido] > While I am an enthusiastic supporter of several of those additions, I > am *not* in favor of the special status granted to software > contributed by certain developers, since it is a burden for all other > developers. [Martin] > Each maintainer should indicate whether he is happy with a "this is > part of Python" approach. If so, the entry should be removed from PEP > 360 (*); if not, the code should be removed from Python before beta 1. I very much identify with Phillip's gripe, but I gotta admit Guido has the compelling argument here. Personally, I have noticed very few "rogue" changes to optparse.py over the years, and have quietly grumbled and backported most of them over to Optik for eventual re-merge to optparse. (One or two got dropped because I had already fixed the problem differently in Optik.) I think this is just the price that must be paid for maintaining two copies of something. It's nice that Optik has an existence of its own (every time I break compatibility with Python 2.0, someone comes along with a patch to restore it), but I think it's better that the burden of keeping track of what is effectively a closely-tracked fork should be on the person who knows the code best (me), not on a horde of Python developers who may occasionally stumble across a style issue or shallowf bug and just fix it. In retrospect, I'm *really* glad that I didn't release textwrap separately, and just stuffed it in the stdlib. And while I have been thinking about Optik 2.0 for a couple of years now, I think that I have just decided that there will be no Optik 2.0: there will only be optparse2. (Unless I can figure out a backwards-compatible way of making the changes I've been thinking about all these years, in which case there will only be optparse. Unlikely.) Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Reality is for people who can't handle science fiction. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
python-dev@python.org
On 23 March 2005, Oleg Broytmann said: >I'd like to remove all those redirects. Any opinion? +0.5. The beauty of Python is that it generally provides thin wrappers: when writing a convenient wrapper, it's OK to expose the underlying beast, warts and all. (I had a minor epiphany about this recently when digging into ossaudiodev again: turns out that certain ioctls are implemented subtly differently in OSS and in ALSA's OSS emulation layer. ossaudiodev, as it turns out, faithfully mirrors this inconsistency to Python programmers. The inconsistency is not ossaudiodev's fault, so it's not ossaudiodev's problem to fix it. Python programmers should have access to everything that C programmers have access to, only with less typing. If that means they have to worry about Mozilla dumping lots of text to stdout, or ALSA implementing certain ioctls differently than OSS, so be it.) (But, oh yeah: +1 to Fred's suggestion of making redirection controllable. Something like this: default should be no redirection, programmer should be allowed to specify what to do with stdout/stderr of GUI browsers.) Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ If at first you don't succeed, give up--no use making a damn fool of yourself. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch review: all webbrowser.py related patches up to 2005-03-20
On 20 March 2005, [EMAIL PROTECTED] said: > 1166780 Fix _tryorder in webbrowser.py > --- > > This is my own patch. > > At the present time (Py2.4) documentation says: > """ > Under Unix, if the environment variable BROWSER exists, > it is interpreted to override the platform default list of > browsers,... > """ > (extract from Python-2.4/Doc/html/lib/module-webbrowser.html) > > But, when the environment variable BROWSER is messed up, > there is no reason not to try the other detected browser alternatives. I like it. Short, simple, and obvious. Can you think of a way to unit-test it? I took a brief look at the code, and it wasn't obvious to me. Might require factoring out a lazy initializer, and even then it might not work. And that would certainly call for more unit tests! Still, it's worth a shot. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Predestination was doomed from the start. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP to make file objects support non-blocking mode.
On 18 March 2005, Donovan Baarda said: > Rationale > = > > Many Python library methods and classes like select.select(), os.popen2(), > and subprocess.Popen() return and/or operate on builtin file objects. > However even simple applications of these methods and classes require the > files to be in non-blocking mode. > > Currently the built in file type does not support non-blocking mode very > well. Setting a file into non-blocking mode and reading or writing to it > can only be done reliably by operating on the file.fileno() file descriptor. > This requires using the fnctl and os module file descriptor manipulation > methods. Is having to use fcntl and os really so awful? At least it requires the programmer to prove he knows what he's doing putting this file into non-blocking mode, and that he really wants to do it. ;-) > Details > === > > The documentation of file.read() warns; "Also note that when in non-blocking > mode, less data than what was requested may be returned, even if no size > parameter was given". An empty string is returned to indicate an EOF > condition. It is possible that file.read() in non-blocking mode will not > produce any data before EOF is reached. Currently there is no documented > way to identify the difference between reaching EOF and an empty > non-blocking read. > > The documented behaviour of file.write() in non-blocking mode is undefined. > When writing to a file in non-blocking mode, it is possible that not all of > the data gets written. Currently there is no documented way of handling or > indicating a partial write. That's more interesting and a better motivation for this PEP. > file.read([size]) Changes > -- > > The read method's current behaviour needs to be documented, so its actual > behaviour can be used to differentiate between an empty non-blocking read, > and EOF. This means recording that IOError(EAGAIN) is raised for an empty > non-blocking read. > > > file.write(str) Changes > > > The write method needs to have a useful behaviour for partial non-blocking > writes defined, implemented, and documented. This includes returning how > many bytes of "str" are successfully written, and raising IOError(EAGAIN) > for an unsuccessful write (one that failed to write anything). Proposing semantic changes to file.read() and write() is bound to raise hackles. One idea for soothing such objections: only make these changes active when setblocking(False) is in effect. I.e., a setblocking(True) file (the default, right?) behaves as you described above, warts and all. (So old code that uses fcntl() continues to "work" as before.) But files that have had setblocking(False) called could gain these new semantics that you propose. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I just forgot my whole philosophy of life!!! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] LinkedHashSet/LinkedHashMap equivalents
On 09 March 2005, Delaney, Timothy C (Timothy) said: > For those who don't know, LinkedHashSet and LinkedHashMap are simply > hashed sets and maps that iterate in the order that the keys were added > to the set/map. I almost invariably use them for the above scenario - > removing duplicates without changing order. > > Does anyone else think it would be worthwhile adding these to > collections, or should I just make a cookbook entry? +1 on a cookbook entry. +0 on adding to stdlib. I'll attach another approach to the same problem, an ordered dictionary object. I believe the semantics of adding/readding/deleting keys is the same as java.util.LinkedHashMap -- certainly it seems the most sensible and easy-to-implement semantics. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I brought my BOWLING BALL -- and some DRUGS!! """ Provides odict, a subclass of the standard dict type that preserves insertion order. """ __revision__ = "$Id: odict.py,v 1.1 2004/03/09 02:32:08 gward Exp $" class odict(dict): """ An order-preserving mapping: lookup works like a dictionary, but keys(), values(), items(), etc. all return items in order of insertion. (Resetting a key preserves order; deleting a key and re-adding it moves it to the end.) Don't use this for enormous dictionaries, since it increases the memory use of the whole object, and the worst-case runtime for many common operations is O(N) rather than O(1). """ def __init__(self, arg=None): super(odict, self).__init__() self.order = [] if isinstance(arg, dict): self.update(arg) def copy(self): return self.__class__(self) def __delitem__(self, key): dict.__delitem__(self, key) self.order.remove(key) def __iter__(self): return iter(self.order) def __setitem__(self, key, value): add = key not in self dict.__setitem__(self, key, value) if add: self.order.append(key) def items(self): return [(key, self[key]) for key in self.order] def keys(self): return self.order def values(self): return [self[key] for key in self.order] def iteritems(self): for key in self.order: yield (key, self[key]) iterkeys = __iter__ def itervalues(self): for key in self.order: yield self[key] def clear(self): dict.clear(self) self.order.clear() def popitem(self): """ Remove and return the most-recently-added item of the mapping. """ key = self.order.pop() value = self[key] dict.__delitem__(self, key) return value def setdefault(self, key, value=None): if key in self: return self[key] else: self[key] = value return value def update(self, other): for key in other: self[key] = other[key] if __name__ == "__main__": m = odict() m['foo'] = 43 m['bar'] = 'barf' m[42] = None print m.items() ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
@deprecated (was Re: [Python-Dev] Re: Useful thread project for 2.5?)
On 08 March 2005, Michael Chermside said: > Greg writes: > > This is one of my top two Java features [1]. > ... > > [1] The other is compiler recognition of "@deprecated" in doc comments. > > Hmm... what a good idea! Let's see... what exactly does "@deprecated" DO in > Java? Why it causes the compiler to emit a warning if you use the function in > question. Not a bad idea. Isn't it, though? > Amusingly enough, the syntax is even the same in > Python: [...code omitted...] Cl. So simple, and yet so powerful. One might even call it Pythonic! > So... shall I go add this to the cookbook? Hell yes! Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Always look on the bright side of life. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
No new features (was Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36)
On 09 March 2005, Anthony Baxter said (privately): > Thanks! I really want to keep the no-new-features thing going for > as long as possible, pending any AoG (Acts of Guido), of course. Grumble. How do you feel about upgrading optparse to sync with Optik 1.5.1? I'm a bit embarassed that Python 2.4's optparse has __version__ == "1.5a2" because I didn't release Optik 1.5 in time. And yes, there were some tiny new features in 1.5 and a few more coming in 1.5.1: * SF patch #870807: allow users to specify integer option arguments in hexadecimal, octal, or binary with leading "0x", "0", or "0b" (1.5 final). * SF feature #1050184: add 'append_const' action (patch by Andrea 'fwyzard' Bocci) (1.5 final). * Keep going if importing gettext fails (so optparse can be used in the Python build process) (1.5 final). * Fix so the 'merge' script works again (bugs spotted, and mostly fixed, by Andrea 'fwyzard' Bocci). (1.5.1) * SF bug #1145594: add 'finish()' method to OptionParser so applications can explicitly break reference cycles, making life easier for Python's garbage collector. (1.5.1) * SF feature #988126: add 'epilog' attribute to OptionParser (and constructor arg): paragraph of text to print after the main option help. (1.5.1) * Corrected French translation (po/optik/fr.po) (Laurent Laporte). (1.5.1) Every one of these is useful to someone, and none of them are even remotely destabilizing. But they all add functionality that would be present in 2.4.1 and not in 2.4. That doesn't bother me in the slightest, but I guess it bothers some people. I'd like to check this in for 2.4.1. But I won't if anyone says "don't do it". Nor will I if no one else says "do it". Burnt once... Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Any priest or shaman must be presumed guilty until proven innocent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36
On 08 March 2005, Anthony Baxter said: > I really would like to see it reverted, please. Done. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I just forgot my whole philosophy of life!!! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Useful thread project for 2.5?
On 06 March 2005, Fazal Majid said: > Since I started this, I might as well finish it. I do have some Python > developer experience (hey, I even voted for comp.lang.python back > when...) but not in the core interpreter itself. What would be *really* spiffy is to provide a way for externally-triggered thread dumps. This is one of my top two Java features [1]. The way this works in Java is a bit awkward -- "kill -QUIT" the Java process and it writes a traceback for every running thread to stdout -- but it works. Something similar ought to be possible for Python, although optional (because Python apps can handle signals themselves, unlike Java apps). It could be as simple as this: calling sys.enablethreaddump(signal=signal.SIGQUIT) from the program enables externally-triggered thread dumps via the specified signal. Greg [1] The other is compiler recognition of "@deprecated" in doc comments. -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Think honk if you're a telepath. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
On 07 March 2005, "Martin v. Löwis" said: > OTOH, I wonder whether the distutils CVS needs to be converted at all, > or whether it would be sufficient to only migrate the python "module" > (in which case your approach would be sufficient). The last time I looked (late 2000), there was useful content in /distutils that was not in /python/dist/src/Lib/distutils. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I can never remember how to spell "mnemonic". ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36
On 07 March 2005, Anthony Baxter said: > Um, unless I misread this, you added new attributes to the ossaudiodev > objects in the 2.4 branch. Please don't do this - this is a new > feature, and suddenly people who want to use those new attributes have > to either test for version >= 2.4.1, or else do a hasattr test. Please > see the bugfix PEP for more rationale on this... D'ohhh -- busted! My only excuse is that the lack of these attributes was originally filed as a bug report, and I suddenly realized "oops! new attributes == feature request" just as I was checking the change in on 2.4. I'll revert the change on 2.4 if you (or anyone) really wants me to. Otherwise, I'd rather leave it as-is and go fix more bugs. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I don't believe there really IS a GAS SHORTAGE.. I think it's all just a BIG HOAX on the part of the plastic sign salesmen -- to sell more numbers!! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Documentation for __new__
On 07 March 2005, Steve Holden said: > Just to offer alternatives: Cool, I liked some of your changes. I'm happy with this doc change. Will checkin Doc/ref/ref3.tex on 2.4 branch and merge to trunk shortly. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ "What do you mean -- a European or an African swallow?" ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failing tests: marshal, warnings
On 06 March 2005, I said: > I'll check this in and merge to the trunk once I see all tests passing. Checked in on 2.4 branch. Not merged to trunk since Raymond hasn't merged his stuff to the trunk yet. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I repeat myself when under stress I repeat myself when under stress I repeat--- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failing tests: marshal, warnings
On 06 March 2005, I said:
> OK, I've narrowed it down: test_warnings fails when run after
> test_descr:
Raymond Hettinger, step right up! You're the next contestant on The
Tests Are Failing! Your recent checkins include...
working file: Lib/test/test_descr.py; sticky tag: release24-maint
revision: 1.202.2.1
date: 2005/03/03 16:55:53; author: rhettinger; lines: +13 -0
SF bug #1155938: Missing None check for __init__().
revision: 1.202.2.2
date: 2005/03/04 04:47:04; author: rhettinger; lines: +7 -1
Convert "__init__ should return None" from an exception to a warning.
If I revert test_descr.py to 1.202 (the branch point for 2.4), then
running
./python -E Lib/test/regrtest.py test_descr test_warnings
works just fine. If I revert to 1.202.2.1, then test_descr fails, but
test_warnings passes. If I update to the latest, 1.202.2.2, then
test_desc passes, but test_warnings fails.
[...a few minutes of tinkering and reading up on warning filters...]
A-ha! I get it. There are two mistakes in test_descr.py:test_init():
lack of "finally" clause, and failure to make a copy of
warnings.filters. This patch fixes both:
"""
--- Lib/test/test_descr.py 4 Mar 2005 04:47:04 - 1.202.2.2
+++ Lib/test/test_descr.py 7 Mar 2005 00:54:00 -
@@ -3973,15 +3973,18 @@
def __init__(self):
return 10
-oldfilters = warnings.filters
-warnings.filterwarnings("error", category=RuntimeWarning)
+oldfilters = warnings.filters[:]
try:
-Foo()
-except RuntimeWarning:
pass
-else:
-raise TestFailed, "did not test __init__() for None return"
-warnings.filters = oldfilters
+warnings.filterwarnings("error", category=RuntimeWarning)
+try:
+Foo()
+except RuntimeWarning:
+pass
+else:
+raise TestFailed, "did not test __init__() for None return"
+finally:
+warnings.filters = oldfilters
def test_main():
"""
I'll check this in and merge to the trunk once I see all tests passing.
Greg
--
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
I hope something GOOD came in the mail today so I have a REASON to live!!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failing tests: marshal, warnings
On 06 March 2005, I said: > Anyone else seeing test failures on the 2.4 branch right now? I started > seeing this failure: > > test_warnings > test test_warnings failed -- Traceback (most recent call last): > File "/scratch/src/python-2.4/Lib/test/test_warnings.py", line 57, in > test_warn_specific_category > warnings.warn(text, category) > File "/scratch/src/python-2.4/Lib/warnings.py", line 57, in warn > warn_explicit(message, category, filename, lineno, module, registry) > File "/scratch/src/python-2.4/Lib/warnings.py", line 92, in warn_explicit > raise message > RuntimeWarning: unfiltered RuntimeWarning [...] > Naturally, they only fail when running the full test suite. OK, I've narrowed it down: test_warnings fails when run after test_descr: $ ./python -E Lib/test/regrtest.py test_descr test_warnings test_descr test_warnings test test_warnings failed -- Traceback (most recent call last): File "/scratch/src/python-2.4/Lib/test/test_warnings.py", line 57, in test_warn_specific_category warnings.warn(text, category) File "/scratch/src/python-2.4/Lib/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/scratch/src/python-2.4/Lib/warnings.py", line 92, in warn_explicit raise message RuntimeWarning: unfiltered RuntimeWarning Does this ring alarm bells with anyone? Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Gee, I feel kind of LIGHT in the head now, knowing I can't make my satellite dish PAYMENTS! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failing tests: marshal, warnings
Anyone else seeing test failures on the 2.4 branch right now? I started seeing this failure: test_warnings test test_warnings failed -- Traceback (most recent call last): File "/scratch/src/python-2.4/Lib/test/test_warnings.py", line 57, in test_warn_specific_category warnings.warn(text, category) File "/scratch/src/python-2.4/Lib/warnings.py", line 57, in warn warn_explicit(message, category, filename, lineno, module, registry) File "/scratch/src/python-2.4/Lib/warnings.py", line 92, in warn_explicit raise message RuntimeWarning: unfiltered RuntimeWarning yesterday, so I "cvs up"'d today to see if it had been fixed. Now, not only is test_warnings failing, so is test_marshal: test_marshal test test_marshal failed -- Traceback (most recent call last): File "/scratch/src/python-2.4/Lib/test/test_marshal.py", line 88, in test_floats got = marshal.load(file(test_support.TESTFN, "rb")) IOError: [Errno 2] No such file or directory: '@test' Naturally, they only fail when running the full test suite. ;-( I sure hope my recent fix to textwrap isn't to blame! I'll fiddle around a bit in my working dir and see if I can figure out what's going on, but I'd like to know if I'm the only one seeing these problems... Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Never underestimate the power of human stupidity. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation for __new__
I've LaTeX'ified the proposed documentation for __new__() and uploaded the patch to SF: http://sourceforge.net/tracker/download.php?group_id=5470&atid=105470&file_id=124422&aid=1156412 Someone who really understands new-style classes should give this a look. (Guido?) I've tested that Python 2.3.5 and 2.4 (CVS) actually implement what's described in this doc patch, but it wouldn't hurt if someone read it from the point of view of what the promised constract is supposed to be! Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I'd like some JUNK FOOD ... and then I want to be ALONE -- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
On 06 March 2005, "Martin v. Löwis" said: > - It has imported the CVSROOT directory as well. I don't > know whether this is deliberate/useful. This is just an artifact of how SourceForge CVS repositories are organized. When I converted Optik's CVS to Subversion, I just did this: cvs2svn -s /home/svn/optik /home/cvs/optik/optik where /home/cvs/optik is what I got after unpacking the tarball downloaded from SF. Presumably for Python's repository, this would work: cvs2svn -s /home/svn/python /home/cvs/python/python ...except, umm, isn't distutils a separate top-level directory in the Python repository or something? That'll probably have to be fixed manually. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ The NSA. We care: we listen to our customers. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ossaudiodev test failure
I just discovered that the ossaudiodev test fails on Linux 2.6 with ALSA's OSS emulation layer. I'm pretty sure this can be blamed on ALSA (The difference is this: if you pass bogus sampling parameters to setparameters(), OSS will accept the request and set the hardware to something reasonable, while ALSA will reject the request by returning -1 and setting errno, which becomes IOException.) (IMHO, test_ossaudiodev.py should not test this feature if it's not reliably emulated by ALSA.) Anyways, if you're running Linux or FreeBSD, or any other OS that contains OSS drivers or OSS emulation, can you please run ./python ./Lib/test/test_ossaudiodev.py from your CVS tree and email me the following info: * whether the test passed or not * what version of what OS you're running * what sound hardware you have * (Linux only) are you using ALSA or OSS? * whether other audio software (eg. xmms, xine, mpg123, audacity) works for you A passing test looks like this: playing test sound file... elapsed time: 3.1 sec and has a uniquely Pythonesque sound. ;-) The failure I've been seeing is this (you'll see a slightly different traceback, because I've refactored the code a bit in my working dir): playing test sound file... elapsed time: 3.1 sec Traceback (most recent call last): File "Lib/test/test_ossaudiodev.py", line 147, in ? test() File "Lib/test/test_ossaudiodev.py", line 142, in test test_bad_setparameters(dsp) File "Lib/test/test_ossaudiodev.py", line 125, in test_bad_setparameters result = dsp.setparameters(fmt, channels, rate, False) IOError: [Errno 22] Invalid argument Oh, to find out if you're using ALSA or OSS: * run "lsmod" and look for a bunch of modules starting with "snd_" -- this is ALSA * look for device files like /dev/snd/pcmC0D* -- ALSA again If you're using ALSA and /dev/dsp doesn't work, try "modprobe snd_pcm_oss" -- that's the OSS emulation layer. Thanks! Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I used to be a FUNDAMENTALIST, but then I heard about the HIGH RADIATION LEVELS and bought an ENCYCLOPEDIA!! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation for __new__
On 05 March 2005, Nick Coghlan said: > Steven Bethard has put together some text to add __new__ to the list of > Basic Customisation methods in the language reference. Would one of the > documentation folks care to take a look at it? I've tried to tighten up the text there and hopefully make it a smidgeon clearer and more accurate. Here's my best effort: __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. Feedback welcome. Has anyone volunteered to render this in LaTeX yet? If not, I might. Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ I hope something GOOD came in the mail today so I have a REASON to live!! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Annoying $Id$ in Misc/NEWS
This entry in Misc/NEWS """ - SF patch 995225: The test file testtar.tar accidentally contained CVS keywords (like $Id: NEWS,v 1.1266 2005/03/05 02:53:17 gward Exp $), which could cause spurious failures in test_tarfile.py depending on how the test file was checked out. """ just caused a conflict when I merged something from 2.4 onto the trunk. (It was "Id: ... 1.265 ... mloewis" on the trunk, but "Id: ... 1.1193.2.32 ... gward" on the branch.) This is deliciously ironic: you can't talk about accidental CVS keywords in testtar.tar without having accidental CVS keywords in the text that talks about accidental CVS keywords!! Aieee!!! The obvious fix is to disable keyword expansion for Misc/NEWS: cvs admin -ko Misc/NEWS Anyone mind if I do that? wondering-what-will-happen-to-my-subject-line'ly, Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Never try to outstubborn a cat. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] textwrap.py wordsep_re
On 21 February 2005, Karl Chen said:
> Except when the string to wrap contains dates -- which I would
> like not to be filled. In general I think wordsep_re can be
> smarter about what it decides are hyphenated words.
>
> For example, this code:
> print textwrap.fill('aa 2005-02-21', 18)
> produces:
> aa 2005-
> 02-21
Oops!
> A slightly tweaked wordsep_re:
> textwrap.TextWrapper.wordsep_re =\
> re.compile(r'(\s+|' # any whitespace
>r'[^\s\w]*\w+[a-zA-Z]-(?=[a-zA-Z]\w+)|' # hyphenated words
>r'(?<=[\w\!\"\'\&\.\,\?])-{2,}(?=\w))') # em-dash
> print textwrap.fill('aa 2005-02-21', 18)
> behaves better:
> aa
> 2005-02-21
Post a patch to SF and assign it to me. Make sure the unit tests still
pass, and add a new one that doesn't pass without your fix. Pester me
mercilessly until I act on it. (I think your change is probably fine,
but I need more time to examine it than I have right now.)
Greg
--
Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/
Cheops' Law: Nothing *ever* gets built on schedule or within budget.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
