From noreply@sourceforge.net Wed May 1 01:06:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Apr 2002 17:06:46 -0700 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 06:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None >Status: Open Resolution: Rejected Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Michael Hudson (mwh) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 15:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 10:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 09:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 10:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 10:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 10:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Wed May 1 01:09:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Apr 2002 17:09:20 -0700 Subject: [Patches] [ python-Patches-550555 ] short patch to buffer() documentation Message-ID: Patches item #550555, was opened at 2002-04-30 09:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550555&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Gilbert (xscott) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: short patch to buffer() documentation Initial Comment: The documentation incorrectly states that objects returned from the buffer() builtin do not support concatenation or repeating. I don't have an old version of Python at my disposal, but it appears from CVS that they do support concatenation and repeating since version 1.6. ---------------------------------------------------------------------- >Comment By: Scott Gilbert (xscott) Date: 2002-05-01 00:09 Message: Logged In: YES user_id=38318 Just checked Python 1.5.2 on a Linux box at work. The value returned from buffer() has supported repeat/concat for since at least 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550555&group_id=5470 From noreply@sourceforge.net Wed May 1 15:16:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 May 2002 07:16:31 -0700 Subject: [Patches] [ python-Patches-551008 ] Cygwin operator and cPickle patch Message-ID: Patches item #551008, was opened at 2002-05-01 06:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551008&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin operator and cPickle patch Initial Comment: This patch re-enables the clean building of the operator and cPickle modules under Cygwin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551008&group_id=5470 From noreply@sourceforge.net Wed May 1 15:25:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 May 2002 07:25:15 -0700 Subject: [Patches] [ python-Patches-551009 ] Cygwin array patch Message-ID: Patches item #551009, was opened at 2002-05-01 06:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551009&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin array patch Initial Comment: This patch re-enables the clean building of the array module under Cygwin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551009&group_id=5470 From noreply@sourceforge.net Wed May 1 15:32:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 May 2002 07:32:24 -0700 Subject: [Patches] [ python-Patches-551011 ] Cygwin pyexpat patch Message-ID: Patches item #551011, was opened at 2002-05-01 06:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551011&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin pyexpat patch Initial Comment: This patch enables the clean building of the pyexpat module under Cygwin. Note that this patch is a "cleaner" version of the one in following: http://mail.python.org/pipermail/xml-sig/2002-January/006943.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551011&group_id=5470 From noreply@sourceforge.net Wed May 1 18:47:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 May 2002 10:47:39 -0700 Subject: [Patches] [ python-Patches-551093 ] Cygwin forced --enable-shared patch Message-ID: Patches item #551093, was opened at 2002-05-01 09:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin forced --enable-shared patch Initial Comment: This patch forces the configure --enable-shared option under Cygwin even if not specified by the user. Cygwin, like Win32, requires a shared python library. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 From noreply@sourceforge.net Wed May 1 18:57:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 May 2002 10:57:47 -0700 Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks Message-ID: Patches item #432401, was opened at 2001-06-12 15:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Postponed Priority: 6 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode encoding error callbacks Initial Comment: This patch adds unicode error handling callbacks to the encode functionality. With this patch it's possible to not only pass 'strict', 'ignore' or 'replace' as the errors argument to encode, but also a callable function, that will be called with the encoding name, the original unicode object and the position of the unencodable character. The callback must return a replacement unicode object that will be encoded instead of the original character. For example replacing unencodable characters with XML character references can be done in the following way. u"aäoöuüß".encode( "ascii", lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos]) ) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-05-01 19:57 Message: Logged In: YES user_id=89016 OK, PyUnicode_EncodeDecimal is done (diff8.txt), but as the errors argument can't be accessed from Python code, there's not much testing for this. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-20 17:34 Message: Logged In: YES user_id=89016 A new idea for the interface between the codec and the callback: Maybe we could have new exception classes UnicodeEncodeError, UnicodeDecodeError and UnicodeTranslateError derived from UnicodeError. They have all the attributes that are passed as an argument tuple in the current version: string: the original string start: the start position of the unencodable characters/undecodable bytes end: the end position+1 of the unencodable characters/undecodable bytes. reason: the a string, that explains, why the encoding/decoding doesn't work. There is no data object, because when a codec wants to pass extended information to the callback it can do this via a derived class. It might be better to move these attributes to the base class UnicodeError, but this might have backwards compatibility problems. With this method we really can have one global registry for all callbacks, because for callback names that must work with encoding *and* decoding *and* translating (i.e. "strict", "replace" and "ignore"), the callback can check which type of exception was passed, so "replace" can e.g. look like this: def replace(exc): if isinstance(exc, UnicodeDecodeError): return ("?", exc.end) else: return (u"?"*(exc.end-exc.start), exc.end) Another possibility would be to do the commucation callback->codec by assigning to attributes of the exception object. The resyncronisation position could even be preassigned to end, so the callback only needs to specify the replacement in most cases: def replace(exc): if isinstance(exc, UnicodeDecodeError): exc.replacement = "?" else: exc.replacement = u"?"*(exc.end-exc.start) As many of the assignments can now be done on the C level without having to allocate Python objects (except for the replacement string and the reason), this version might even be faster, especially if we allow the codec to reuse the exception object for the next call to the callback. Does this make sense, or is this to fancy? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-18 21:24 Message: Logged In: YES user_id=89016 And here is the test script (test_codeccallbacks.py) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-18 21:22 Message: Logged In: YES user_id=89016 OK, here is the current version of the patch (diff7.txt). PyUnicode_EncodeDecimal and PyUnicode_TranslateCharmap are still missing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-17 22:50 Message: Logged In: YES user_id=89016 > About the difference between encoding > and decoding: you shouldn't just look > at the case where you work with Unicode > and strings, e.g. take the rot-13 codec > which works on strings only or other > codecs which translate objects into > strings and vice-versa. unicode.encode encodes to str and str.decode decodes to unicode, even for rot-13: >>> u"gürk".encode("rot13") 't\xfcex' >>> "gürk".decode("rot13") u't\xfcex' >>> u"gürk".decode("rot13") Traceback (most recent call last): File "", line 1, in ? AttributeError: 'unicode' object has no attribute 'decode' >>> "gürk".encode("rot13") Traceback (most recent call last): File "", line 1, in ? File "/home/walter/Python-current- readonly/dist/src/Lib/encodings/rot_13.py", line 18, in encode return codecs.charmap_encode(input,errors,encoding_map) UnicodeError: ASCII decoding error: ordinal not in range (128) Here the str is converted to unicode first, before encode is called, but the conversion to unicode fails. Is there an example where something else happens? > Error handling has to be flexible enough > to handle all these situations. Since > the codecs know best how to handle the > situations, I'd make this an implementation > detail of the codec and leave the > behaviour undefined in the general case. OK, but we should suggest, that for encoding unencodable characters are collected and for decoding seperate byte sequences that are considered broken by the codec are passed to the callback: i.e for decoding the handler will never get all broken data in one call, e.g. for "\u30\Uffffffff".decode("unicode-escape") the handler will be called twice (once for "\u30" and "truncated \u escape" as the reason and once for "\Uffffffff" and "illegal character" as the reason.) > For the existing codecs, backward > compatibility should be maintained, > if at all possible. If the patch gets > overly complicated because of this, > we may have to provide a downgrade solution > for this particular problem (I don't think > replace is used in any computational context, > though, since you can never be sure how > many replacement character do get > inserted, so the case may not be > that realistic). > > Raising an exception for the charmap codec > is the right way to go, IMHO. I would > consider the current behaviour a bug. OK, this is implemented in PyUnicode_EncodeCharmap now, and collecting unencodable characters works too. I completely changed the implementation, because the stack approach would have gotten much more complicated when unencodable characters are collected. > For new codecs, I think we should > suggest that replace tries to collect > as much illegal data as possible before > invoking the error handler. The handler > should be aware of the fact that it > won't necessarily get all the broken > data in one call. OK for encoders, for decoders see above. > About the codec error handling > registry: You seem to be using a > Unicode specific approach here. > I'd rather like to see a generic > approach which uses the API > we discussed earlier. Would that be possible? The handlers in the registry are all Unicode specific. and they are different for encoding and for decoding. I renamed the function because of your comment from 2001-06-13 10:05 (which becomes exceedingly difficult to find on this long page! ;)). > In that case, the codec API should > probably be called > codecs.register_error('myhandler', myhandler). > > Does that make sense ? We could require that unique names are used for custom handlers, but for the standard handlers we do have name collisions. To prevent them, we could either remove them from the registry and require that the codec implements the error handling for those itself, or we could to some fiddling, so that u"üöä".encode("ascii", "replace") becomes u"üöä".encode("ascii", "unicodeencodereplace") behind the scenes. But I think two unicode specific registries are much simpler to handle. > BTW, the patch which uses the callback > registry does not seem to be available > on this SF page (the last patch still > converts the errors argument to a > PyObject, which shouldn't be needed > anymore with the new approach). > Can you please upload your > latest version? OK, I'll upload a preliminary version tomorrow. PyUnicode_EncodeDecimal and PyUnicode_TranslateCharmap are still missing, but otherwise the patch seems to be finished. All decoders work and the encoders collect unencodable characters and implement the handling of known callback handler names themselves. As PyUnicode_EncodeDecimal is only used by the int, long, float, and complex constructors, I'd love to get rid of the errors argument, but for completeness sake, I'll implement the callback functionality. > Note that the highlighting codec > would make a nice example > for the new feature. This could be part of the codec callback test script, which I've started to write. We could kill two birds with one stone here: 1. Test the implementation. 2. Document and advocate what is possible with the patch. Another idea: we could have as an example a decoding handler that relaxes the UTF-8 minimal encoding restriction, e.g. def relaxedutf8(enc, uni, startpos, endpos, reason, data): if uni[startpos:startpos+2] == u"\xc0\x80": return (u"\x00", startpos+2) else: raise UnicodeError(...) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-04-17 21:40 Message: Logged In: YES user_id=38388 Sorry for the late response. About the difference between encoding and decoding: you shouldn't just look at the case where you work with Unicode and strings, e.g. take the rot-13 codec which works on strings only or other codecs which translate objects into strings and vice-versa. Error handling has to be flexible enough to handle all these situations. Since the codecs know best how to handle the situations, I'd make this an implementation detail of the codec and leave the behaviour undefined in the general case. For the existing codecs, backward compatibility should be maintained, if at all possible. If the patch gets overly complicated because of this, we may have to provide a downgrade solution for this particular problem (I don't think replace is used in any computational context, though, since you can never be sure how many replacement character do get inserted, so the case may not be that realistic). Raising an exception for the charmap codec is the right way to go, IMHO. I would consider the current behaviour a bug. For new codecs, I think we should suggest that replace tries to collect as much illegal data as possible before invoking the error handler. The handler should be aware of the fact that it won't necessarily get all the broken data in one call. About the codec error handling registry: You seem to be using a Unicode specific approach here. I'd rather like to see a generic approach which uses the API we discussed earlier. Would that be possible ? In that case, the codec API should probably be called codecs.register_error('myhandler', myhandler). Does that make sense ? BTW, the patch which uses the callback registry does not seem to be available on this SF page (the last patch still converts the errors argument to a PyObject, which shouldn't be needed anymore with the new approach). Can you please upload your latest version ? Note that the highlighting codec would make a nice example for the new feature. Thanks. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-17 12:21 Message: Logged In: YES user_id=89016 Another note: the patch will change the meaning of charmap encoding slightly: currently "replace" will put a ? into the output, even if ? is not in the mapping, i.e. codecs.charmap_encode(u"c", "replace", {ord("a"): ord ("b")}) will return ('?', 1). With the patch the above example will raise an exception. Off course with the patch many more replace characters can appear, so it is vital that for the replacement string the mapping is done. Is this semantic change OK? (I guess all of the existing codecs have a mapping ord("?")->ord("?")) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-15 18:19 Message: Logged In: YES user_id=89016 So this means that the encoder can collect illegal characters and pass it to the callback. "replace" will replace this with (end-start)*u"?". Decoders don't collect all illegal byte sequences, but call the callback once for every byte sequence that has been found illegal and "replace" will replace it with u"?". Does this make sense? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-15 18:06 Message: Logged In: YES user_id=89016 For encoding it's always (end-start)*u"?": >>> u"ää".encode("ascii", "replace") '??' But for decoding, it is neither nor: >>> "\Ux\U".decode("unicode-escape", "replace") u'\ufffd\ufffd' i.e. a sequence of 5 illegal characters was replace by two replacement characters. This might mean that decoders can't collect all the illegal characters and call the callback once. They might have to call the callback for every single illegal byte sequence to get the old behaviour. (It seems that this patch would be much, much simpler, if we only change the encoders) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-08 19:36 Message: Logged In: YES user_id=38388 Hmm, whatever it takes to maintain backwards compatibility. Do you have an example ? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-08 18:31 Message: Logged In: YES user_id=89016 What should replace do: Return u"?" or (end-start)*u"?" ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-08 16:15 Message: Logged In: YES user_id=38388 Sounds like a good idea. Please keep the encoder and decoder APIs symmetric, though, ie. add the slice information to both APIs. The slice should use the same format as Python's standard slices, that is left inclusive, right exclusive. I like the highlighting feature ! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-08 00:09 Message: Logged In: YES user_id=89016 I'm think about extending the API a little bit: Consider the following example: >>> "\u1".decode("unicode-escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 2: truncated \uXXXX escape The error message is a lie: Not the '1' in position 2 is the problem, but the complete truncated sequence '\u1'. For this the decoder should pass a start and an end position to the handler. For encoding this would be useful too: Suppose I want to have an encoder that colors the unencodable character via an ANSI escape sequences. Then I could do the following: >>> import codecs >>> def color(enc, uni, pos, why, sta): ... return (u"\033[1m<%d>\033[0m" % ord(uni[pos]), pos+1) ... >>> codecs.register_unicodeencodeerrorhandler("color", color) >>> u"aäüöo".encode("ascii", "color") 'a\x1b[1m<228>\x1b[0m\x1b[1m<252>\x1b[0m\x1b[1m<246>\x1b [0mo' But here the sequences "\x1b[0m\x1b[1m" are not needed. To fix this problem the encoder could collect as many unencodable characters as possible and pass those to the error callback in one go (passing a start and end+1 position). This fixes the above problem and reduces the number of calls to the callback, so it should speed up the algorithms in case of custom encoding names. (And it makes the implementation very interesting ;)) What do you think? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-07 02:29 Message: Logged In: YES user_id=89016 I started from scratch, and the current state is this: Encoding mostly works (except that I haven't changed TranslateCharmap and EncodeDecimal yet) and most of the decoding stuff works (DecodeASCII and DecodeCharmap are still unchanged) and the decoding callback helper isn't optimized for the "builtin" names yet (i.e. it still calls the handler). For encoding the callback helper knows how to handle "strict", "replace", "ignore" and "xmlcharrefreplace" itself and won't call the callback. This should make the encoder fast enough. As callback name string comparison results are cached it might even be faster than the original. The patch so far didn't require any changes to unicodeobject.h, stringobject.h or stringobject.c ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-05 17:49 Message: Logged In: YES user_id=38388 Walter, are you making any progress on the new scheme we discussed on the mailing list (adding an error handler registry much like the codec registry itself instead of trying to redo the complete codec API) ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 12:38 Message: Logged In: YES user_id=38388 I am postponing this patch until the PEP process has started. This feature won't make it into Python 2.2. Walter, you may want to reference this patch in the PEP. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 12:53 Message: Logged In: YES user_id=38388 I think we ought to summarize these changes in a PEP to get some more feedback and testing from others as well. I'll look into this after I'm back from vacation on the 10.09. Given the release schedule I am not sure whether this feature will make it into 2.2. The size of the patch is huge and probably needs a lot of testing first. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-27 05:55 Message: Logged In: YES user_id=89016 Changing the decoding API is done now. There are new functions codec.register_unicodedecodeerrorhandler and codec.lookup_unicodedecodeerrorhandler. Only the standard handlers for 'strict', 'ignore' and 'replace' are preregistered. There may be many reasons for decoding errors in the byte string, so I added an additional argument to the decoding API: reason, which gives the reason for the failure, e.g.: >>> "\U1111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 8: truncated \UXXXXXXXX escape >>> "\U11111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 9: illegal Unicode character For symmetry I added this to the encoding API too: >>> u"\xff".encode("ascii") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'ascii' can't decode byte 0xff in position 0: ordinal not in range(128) The parameters passed to the callbacks now are: encoding, unicode, position, reason, state. The encoding and decoding API for strings has been adapted too, so now the new API should be usable everywhere: >>> unicode("a\xffb\xffc", "ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' >>> "a\xffb\xffc".decode("ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' I had a problem with the decoding API: all the functions in _codecsmodule.c used the t# format specifier. I changed that to O! with &PyString_Type, because otherwise we would have the problem that the decoding API would must pass buffer object around instead of strings, and the callback would have to call str() on the buffer anyway to access a specific character, so this wouldn't be any faster than calling str() on the buffer before decoding. It seems that buffers aren't used anyway. I changed all the old function to call the new ones so bugfixes don't have to be done in two places. There are two exceptions: I didn't change PyString_AsEncodedString and PyString_AsDecodedString because they are documented as deprecated anyway (although they are called in a few spots) This means that I duplicated part of their functionality in PyString_AsEncodedObjectEx and PyString_AsDecodedObjectEx. There are still a few spots that call the old API: E.g. PyString_Format still calls PyUnicode_Decode (but with strict decoding) because it passes the rest of the format string to PyUnicode_Format when it encounters a Unicode object. Should we switch to the new API everywhere even if strict encoding/decoding is used? The size of this patch begins to scare me. I guess we need an extensive test script for all the new features and documentation. I hope you have time to do that, as I'll be busy with other projects in the next weeks. (BTW, I have't touched PyUnicode_TranslateCharmap yet.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-23 19:03 Message: Logged In: YES user_id=89016 New version of the patch with the error handling callback registry. > > OK, done, now there's a > > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > > codecs.escapereplace_unicodeencode_errors > > that uses \u (or \U if x>0xffff (with a wide build > > of Python)). > > Great! Now PyCodec_EscapeReplaceUnicodeEncodeErrors uses \x in addition to \u and \U where appropriate. > > [...] > > But for special one-shot error handlers, it might still be > > useful to pass the error handler directly, so maybe we > > should leave error as PyObject *, but implement the > > registry anyway? > > Good idea ! > > One minor nit: codecs.registerError() should be named > codecs.register_errorhandler() to be more inline with > the Python coding style guide. OK, but these function are specific to unicode encoding, so now the functions are called: codecs.register_unicodeencodeerrorhandler codecs.lookup_unicodeencodeerrorhandler Now all callbacks (including the new ones: "xmlcharrefreplace" and "escapereplace") are registered in the codecs.c/_PyCodecRegistry_Init so using them is really simple: u"gürk".encode("ascii", "xmlcharrefreplace") ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-13 13:26 Message: Logged In: YES user_id=38388 > > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > > with \uxxxx replacement callback. > > > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > > I'd rather leave the special encoder in place, > > > > since it is being used a lot in Python and > > > > probably some applications too. > > > > > > It would be a slowdown. But callbacks open many > > > possiblities. > > > > True, but in this case I believe that we should stick with > > the native implementation for "unicode-escape". Having > > a standard callback error handler which does the \uXXXX > > replacement would be nice to have though, since this would > > also be usable with lots of other codecs (e.g. all the > > code page ones). > > OK, done, now there's a > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > codecs.escapereplace_unicodeencode_errors > that uses \u (or \U if x>0xffff (with a wide build > of Python)). Great ! > > [...] > > > Should the old TranslateCharmap map to the new > > > TranslateCharmapEx and inherit the > > > "multicharacter replacement" feature, > > > or should I leave it as it is? > > > > If possible, please also add the multichar replacement > > to the old API. I think it is very useful and since the > > old APIs work on raw buffers it would be a benefit to have > > the functionality in the old implementation too. > > OK! I will try to find the time to implement that in the > next days. Good. > > [Decoding error callbacks] > > > > About the return value: > > > > I'd suggest to always use the same tuple interface, e.g. > > > > callback(encoding, input_data, input_position, > state) -> > > (output_to_be_appended, new_input_position) > > > > (I think it's better to use absolute values for the > > position rather than offsets.) > > > > Perhaps the encoding callbacks should use the same > > interface... what do you think ? > > This would make the callback feature hypergeneric and a > little slower, because tuples have to be created, but it > (almost) unifies the encoding and decoding API. ("almost" > because, for the encoder output_to_be_appended will be > reencoded, for the decoder it will simply be appended.), > so I'm for it. That's the point. Note that I don't think the tuple creation will hurt much (see the make_tuple() API in codecs.c) since small tuples are cached by Python internally. > I implemented this and changed the encoders to only > lookup the error handler on the first error. The UCS1 > encoder now no longer uses the two-item stack strategy. > (This strategy only makes sense for those encoder where > the encoding itself is much more complicated than the > looping/callback etc.) So now memory overflow tests are > only done, when an unencodable error occurs, so now the > UCS1 encoder should be as fast as it was without > error callbacks. > > Do we want to enforce new_input_position>input_position, > or should jumping back be allowed? No; moving backwards should be allowed (this may be useful in order to resynchronize with the input data). > Here's is the current todo list: > 1. implement a new TranslateCharmap and fix the old. > 2. New encoding API for string objects too. > 3. Decoding > 4. Documentation > 5. Test cases > > I'm thinking about a different strategy for implementing > callbacks > (see http://mail.python.org/pipermail/i18n-sig/2001- > July/001262.html) > > We coould have a error handler registry, which maps names > to error handlers, then it would be possible to keep the > errors argument as "const char *" instead of "PyObject *". > Currently PyCodec_UnicodeEncodeHandlerForObject is a > backwards compatibility hack that will never go away, > because > it's always more convenient to type > u"...".encode("...", "strict") > instead of > import codecs > u"...".encode("...", codecs.raise_encode_errors) > > But with an error handler registry this function would > become the official lookup method for error handlers. > (PyCodec_LookupUnicodeEncodeErrorHandler?) > Python code would look like this: > --- > def xmlreplace(encoding, unicode, pos, state): > return (u"&#%d;" % ord(uni[pos]), pos+1) > > import codec > > codec.registerError("xmlreplace",xmlreplace) > --- > and then the following call can be made: > u"äöü".encode("ascii", "xmlreplace") > As soon as the first error is encountered, the encoder uses > its builtin error handling method if it recognizes the name > ("strict", "replace" or "ignore") or looks up the error > handling function in the registry if it doesn't. In this way > the speed for the backwards compatible features is the same > as before and "const char *error" can be kept as the > parameter to all encoding functions. For speed common error > handling names could even be implemented in the encoder > itself. > > But for special one-shot error handlers, it might still be > useful to pass the error handler directly, so maybe we > should leave error as PyObject *, but implement the > registry anyway? Good idea ! One minor nit: codecs.registerError() should be named codecs.register_errorhandler() to be more inline with the Python coding style guide. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-12 13:03 Message: Logged In: YES user_id=89016 > > [...] > > so I guess we could change the replace handler > > to always return u'?'. This would make the > > implementation a little bit simpler, but the > > explanation of the callback feature *a lot* > > simpler. > > Go for it. OK, done! > [...] > > > Could you add these docs to the Misc/unicode.txt > > > file ? I will eventually take that file and turn > > > it into a PEP which will then serve as general > > > documentation for these things. > > > > I could, but first we should work out how the > > decoding callback API will work. > > Ok. BTW, Barry Warsaw already did the work of converting > the unicode.txt to PEP 100, so the docs should eventually > go there. OK. I guess it would be best to do this when everything is finished. > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > with \uxxxx replacement callback. > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > I'd rather leave the special encoder in place, > > > since it is being used a lot in Python and > > > probably some applications too. > > > > It would be a slowdown. But callbacks open many > > possiblities. > > True, but in this case I believe that we should stick with > the native implementation for "unicode-escape". Having > a standard callback error handler which does the \uXXXX > replacement would be nice to have though, since this would > also be usable with lots of other codecs (e.g. all the > code page ones). OK, done, now there's a PyCodec_EscapeReplaceUnicodeEncodeErrors/ codecs.escapereplace_unicodeencode_errors that uses \u (or \U if x>0xffff (with a wide build of Python)). > > For example: > > > > Why can't I print u"gürk"? > > > > is probably one of the most frequently asked > > questions in comp.lang.python. For printing > > Unicode stuff, print could be extended the use an > > error handling callback for Unicode strings (or > > objects where __str__ or tp_str returns a Unicode > > object) instead of using str() which always > > returns an 8bit string and uses strict encoding. > > There might even be a > > sys.setprintencodehandler()/sys.getprintencodehandler () > > There already is a print callback in Python (forgot the > name of the hook though), so this should be possible by > providing the encoding logic in the hook. True: sys.displayhook > [...] > > Should the old TranslateCharmap map to the new > > TranslateCharmapEx and inherit the > > "multicharacter replacement" feature, > > or should I leave it as it is? > > If possible, please also add the multichar replacement > to the old API. I think it is very useful and since the > old APIs work on raw buffers it would be a benefit to have > the functionality in the old implementation too. OK! I will try to find the time to implement that in the next days. > [Decoding error callbacks] > > About the return value: > > I'd suggest to always use the same tuple interface, e.g. > > callback(encoding, input_data, input_position, state) -> > (output_to_be_appended, new_input_position) > > (I think it's better to use absolute values for the > position rather than offsets.) > > Perhaps the encoding callbacks should use the same > interface... what do you think ? This would make the callback feature hypergeneric and a little slower, because tuples have to be created, but it (almost) unifies the encoding and decoding API. ("almost" because, for the encoder output_to_be_appended will be reencoded, for the decoder it will simply be appended.), so I'm for it. I implemented this and changed the encoders to only lookup the error handler on the first error. The UCS1 encoder now no longer uses the two-item stack strategy. (This strategy only makes sense for those encoder where the encoding itself is much more complicated than the looping/callback etc.) So now memory overflow tests are only done, when an unencodable error occurs, so now the UCS1 encoder should be as fast as it was without error callbacks. Do we want to enforce new_input_position>input_position, or should jumping back be allowed? > > > > One additional note: It is vital that errors > > > > is an assignable attribute of the StreamWriter. > > > > > > It is already ! > > > > I know, but IMHO it should be documented that an > > assignable errors attribute must be supported > > as part of the official codec API. > > > > Misc/unicode.txt is not clear on that: > > """ > > It is not required by the Unicode implementation > > to use these base classes, only the interfaces must > > match; this allows writing Codecs as extension types. > > """ > > Good point. I'll add that to the PEP 100. OK. Here's is the current todo list: 1. implement a new TranslateCharmap and fix the old. 2. New encoding API for string objects too. 3. Decoding 4. Documentation 5. Test cases I'm thinking about a different strategy for implementing callbacks (see http://mail.python.org/pipermail/i18n-sig/2001- July/001262.html) We coould have a error handler registry, which maps names to error handlers, then it would be possible to keep the errors argument as "const char *" instead of "PyObject *". Currently PyCodec_UnicodeEncodeHandlerForObject is a backwards compatibility hack that will never go away, because it's always more convenient to type u"...".encode("...", "strict") instead of import codecs u"...".encode("...", codecs.raise_encode_errors) But with an error handler registry this function would become the official lookup method for error handlers. (PyCodec_LookupUnicodeEncodeErrorHandler?) Python code would look like this: --- def xmlreplace(encoding, unicode, pos, state): return (u"&#%d;" % ord(uni[pos]), pos+1) import codec codec.registerError("xmlreplace",xmlreplace) --- and then the following call can be made: u"äöü".encode("ascii", "xmlreplace") As soon as the first error is encountered, the encoder uses its builtin error handling method if it recognizes the name ("strict", "replace" or "ignore") or looks up the error handling function in the registry if it doesn't. In this way the speed for the backwards compatible features is the same as before and "const char *error" can be kept as the parameter to all encoding functions. For speed common error handling names could even be implemented in the encoder itself. But for special one-shot error handlers, it might still be useful to pass the error handler directly, so maybe we should leave error as PyObject *, but implement the registry anyway? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-10 14:29 Message: Logged In: YES user_id=38388 Ok, here we go... > > > raise an exception). U+FFFD characters in the > replacement > > > string will be replaced with a character that the > encoder > > > chooses ('?' in all cases). > > > > Nice. > > But the special casing of U+FFFD makes the interface > somewhat > less clean than it could be. It was only done to be 100% > backwards compatible. With the original "replace" > error > handling the codec chose the replacement character. But as > far as I can tell none of the codecs uses anything other > than '?', True. > so I guess we could change the replace handler > to always return u'?'. This would make the implementation a > little bit simpler, but the explanation of the callback > feature *a lot* simpler. Go for it. > And if you still want to handle > an unencodable U+FFFD, you can write a special callback for > that, e.g. > > def FFFDreplace(enc, uni, pos): > if uni[pos] == "\ufffd": > return u"?" > else: > raise UnicodeError(...) > > > ...docs... > > > > Could you add these docs to the Misc/unicode.txt file ? I > > will eventually take that file and turn it into a PEP > which > > will then serve as general documentation for these things. > > I could, but first we should work out how the decoding > callback API will work. Ok. BTW, Barry Warsaw already did the work of converting the unicode.txt to PEP 100, so the docs should eventually go there. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > > replacement callback. > > > > Hmm, wouldn't that result in a slowdown ? If so, I'd > rather > > leave the special encoder in place, since it is being > used a > > lot in Python and probably some applications too. > > It would be a slowdown. But callbacks open many > possiblities. True, but in this case I believe that we should stick with the native implementation for "unicode-escape". Having a standard callback error handler which does the \uXXXX replacement would be nice to have though, since this would also be usable with lots of other codecs (e.g. all the code page ones). > For example: > > Why can't I print u"gürk"? > > is probably one of the most frequently asked questions in > comp.lang.python. For printing Unicode stuff, print could be > extended the use an error handling callback for Unicode > strings (or objects where __str__ or tp_str returns a > Unicode object) instead of using str() which always returns > an 8bit string and uses strict encoding. There might even > be a > sys.setprintencodehandler()/sys.getprintencodehandler() There already is a print callback in Python (forgot the name of the hook though), so this should be possible by providing the encoding logic in the hook. > > > I have not touched PyUnicode_TranslateCharmap yet, > > > should this function also support error callbacks? Why > > > would one want the insert None into the mapping to > call > > > the callback? > > > > 1. Yes. > > 2. The user may want to e.g. restrict usage of certain > > character ranges. In this case the codec would be used to > > verify the input and an exception would indeed be useful > > (e.g. say you want to restrict input to Hangul + ASCII). > > OK, do we want TranslateCharmap to work exactly like > encoding, > i.e. in case of an error should the returned replacement > string again be mapped through the translation mapping or > should it be copied to the output directly? The former would > be more in line with encoding, but IMHO the latter would > be much more useful. It's better to take the second approach (copy the callback output directly to the output string) to avoid endless recursion and other pitfalls. I suppose this will also simplify the implementation somewhat. > BTW, when I implement it I can implement patch #403100 > ("Multicharacter replacements in > PyUnicode_TranslateCharmap") > along the way. I've seen it; will comment on it later. > Should the old TranslateCharmap map to the new > TranslateCharmapEx > and inherit the "multicharacter replacement" feature, > or > should I leave it as it is? If possible, please also add the multichar replacement to the old API. I think it is very useful and since the old APIs work on raw buffers it would be a benefit to have the functionality in the old implementation too. [Decoding error callbacks] > > > A remaining problem is how to implement decoding error > > > callbacks. In Python 2.1 encoding and decoding errors > are > > > handled in the same way with a string value. But with > > > callbacks it doesn't make sense to use the same > callback > > > for encoding and decoding (like > codecs.StreamReaderWriter > > > and codecs.StreamRecoder do). Decoding callbacks have > a > > > different API. Which arguments should be passed to the > > > decoding callback, and what is the decoding callback > > > supposed to do? > > > > I'd suggest adding another set of PyCodec_UnicodeDecode... > () > > APIs for this. We'd then have to augment the base classes > of > > the StreamCodecs to provide two attributes for .errors > with > > a fallback solution for the string case (i.s. "strict" > can > > still be used for both directions). > > Sounds good. Now what is the decoding callback supposed to > do? > I guess it will be called in the same way as the encoding > callback, i.e. with encoding name, original string and > position of the error. It might returns a Unicode string > (i.e. an object of the decoding target type), that will be > emitted from the codec instead of the one offending byte. Or > it might return a tuple with replacement Unicode object and > a resynchronisation offset, i.e. returning (u"?", 1) > means > emit a '?' and skip the offending character. But to make > the offset really useful the callback has to know something > about the encoding, perhaps the codec should be allowed to > pass an additional state object to the callback? > > Maybe the same should be added to the encoding callbacks to? > Maybe the encoding callback should be able to tell the > encoder if the replacement returned should be reencoded > (in which case it's a Unicode object), or directly emitted > (in which case it's an 8bit string)? I like the idea of having an optional state object (basically this should be a codec-defined arbitrary Python object) which then allow the callback to apply additional tricks. The object should be documented to be modifyable in place (simplifies the interface). About the return value: I'd suggest to always use the same tuple interface, e.g. callback(encoding, input_data, input_position, state) -> (output_to_be_appended, new_input_position) (I think it's better to use absolute values for the position rather than offsets.) Perhaps the encoding callbacks should use the same interface... what do you think ? > > > One additional note: It is vital that errors is an > > > assignable attribute of the StreamWriter. > > > > It is already ! > > I know, but IMHO it should be documented that an assignable > errors attribute must be supported as part of the official > codec API. > > Misc/unicode.txt is not clear on that: > """ > It is not required by the Unicode implementation to use > these base classes, only the interfaces must match; this > allows writing Codecs as extension types. > """ Good point. I'll add that to the PEP 100. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-22 22:51 Message: Logged In: YES user_id=38388 Sorry to keep you waiting, Walter. I will look into this again next week -- this week was way too busy... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 19:00 Message: Logged In: YES user_id=38388 On your comment about the non-Unicode codecs: let's keep this separated from the current patch. Don't have much time today. I'll comment on the other things tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 17:49 Message: Logged In: YES user_id=89016 Guido van Rossum wrote in python-dev: > True, the "codec" pattern can be used for other > encodings than Unicode. But it seems to me that the > entire codecs architecture is rather strongly geared > towards en/decoding Unicode, and it's not clear > how well other codecs fit in this pattern (e.g. I > noticed that all the non-Unicode codecs ignore the > error handling parameter or assert that > it is set to 'strict'). I noticed that too. asserting that errors=='strict' would mean that the encoder is not able to deal in any other way with unencodable stuff than by raising an error. But that is not the problem here, because for zlib, base64, quopri, hex and uu encoding there can be no unencodable characters. The encoders can simply ignore the errors parameter. Should I remove the asserts from those codecs and change the docstrings accordingly, or will this be done separately? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 15:57 Message: Logged In: YES user_id=89016 > > [...] > > raise an exception). U+FFFD characters in the replacement > > string will be replaced with a character that the encoder > > chooses ('?' in all cases). > > Nice. But the special casing of U+FFFD makes the interface somewhat less clean than it could be. It was only done to be 100% backwards compatible. With the original "replace" error handling the codec chose the replacement character. But as far as I can tell none of the codecs uses anything other than '?', so I guess we could change the replace handler to always return u'?'. This would make the implementation a little bit simpler, but the explanation of the callback feature *a lot* simpler. And if you still want to handle an unencodable U+FFFD, you can write a special callback for that, e.g. def FFFDreplace(enc, uni, pos): if uni[pos] == "\ufffd": return u"?" else: raise UnicodeError(...) > > The implementation of the loop through the string is done > > in the following way. A stack with two strings is kept > > and the loop always encodes a character from the string > > at the stacktop. If an error is encountered and the stack > > has only one entry (during encoding of the original string) > > the callback is called and the unicode object returned is > > pushed on the stack, so the encoding continues with the > > replacement string. If the stack has two entries when an > > error is encountered, the replacement string itself has > > an unencodable character and a normal exception raised. > > When the encoder has reached the end of it's current string > > there are two possibilities: when the stack contains two > > entries, this was the replacement string, so the replacement > > string will be poppep from the stack and encoding continues > > with the next character from the original string. If the > > stack had only one entry, encoding is finished. > > Very elegant solution ! I'll put it as a comment in the source. > > (I hope that's enough explanation of the API and > implementation) > > Could you add these docs to the Misc/unicode.txt file ? I > will eventually take that file and turn it into a PEP which > will then serve as general documentation for these things. I could, but first we should work out how the decoding callback API will work. > > I have renamed the static ...121 function to all lowercase > > names. > > Ok. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > replacement callback. > > Hmm, wouldn't that result in a slowdown ? If so, I'd rather > leave the special encoder in place, since it is being used a > lot in Python and probably some applications too. It would be a slowdown. But callbacks open many possiblities. For example: Why can't I print u"gürk"? is probably one of the most frequently asked questions in comp.lang.python. For printing Unicode stuff, print could be extended the use an error handling callback for Unicode strings (or objects where __str__ or tp_str returns a Unicode object) instead of using str() which always returns an 8bit string and uses strict encoding. There might even be a sys.setprintencodehandler()/sys.getprintencodehandler() > [...] > I think it would be worthwhile to rename the callbacks to > include "Unicode" somewhere, e.g. > PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but > then it points out the application field of the callback > rather well. Same for the callbacks exposed through the > _codecsmodule. OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors really is a long name ;)) > > I have not touched PyUnicode_TranslateCharmap yet, > > should this function also support error callbacks? Why > > would one want the insert None into the mapping to call > > the callback? > > 1. Yes. > 2. The user may want to e.g. restrict usage of certain > character ranges. In this case the codec would be used to > verify the input and an exception would indeed be useful > (e.g. say you want to restrict input to Hangul + ASCII). OK, do we want TranslateCharmap to work exactly like encoding, i.e. in case of an error should the returned replacement string again be mapped through the translation mapping or should it be copied to the output directly? The former would be more in line with encoding, but IMHO the latter would be much more useful. BTW, when I implement it I can implement patch #403100 ("Multicharacter replacements in PyUnicode_TranslateCharmap") along the way. Should the old TranslateCharmap map to the new TranslateCharmapEx and inherit the "multicharacter replacement" feature, or should I leave it as it is? > > A remaining problem is how to implement decoding error > > callbacks. In Python 2.1 encoding and decoding errors are > > handled in the same way with a string value. But with > > callbacks it doesn't make sense to use the same callback > > for encoding and decoding (like codecs.StreamReaderWriter > > and codecs.StreamRecoder do). Decoding callbacks have a > > different API. Which arguments should be passed to the > > decoding callback, and what is the decoding callback > > supposed to do? > > I'd suggest adding another set of PyCodec_UnicodeDecode... () > APIs for this. We'd then have to augment the base classes of > the StreamCodecs to provide two attributes for .errors with > a fallback solution for the string case (i.s. "strict" can > still be used for both directions). Sounds good. Now what is the decoding callback supposed to do? I guess it will be called in the same way as the encoding callback, i.e. with encoding name, original string and position of the error. It might returns a Unicode string (i.e. an object of the decoding target type), that will be emitted from the codec instead of the one offending byte. Or it might return a tuple with replacement Unicode object and a resynchronisation offset, i.e. returning (u"?", 1) means emit a '?' and skip the offending character. But to make the offset really useful the callback has to know something about the encoding, perhaps the codec should be allowed to pass an additional state object to the callback? Maybe the same should be added to the encoding callbacks to? Maybe the encoding callback should be able to tell the encoder if the replacement returned should be reencoded (in which case it's a Unicode object), or directly emitted (in which case it's an 8bit string)? > > One additional note: It is vital that errors is an > > assignable attribute of the StreamWriter. > > It is already ! I know, but IMHO it should be documented that an assignable errors attribute must be supported as part of the official codec API. Misc/unicode.txt is not clear on that: """ It is not required by the Unicode implementation to use these base classes, only the interfaces must match; this allows writing Codecs as extension types. """ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 10:05 Message: Logged In: YES user_id=38388 > How the callbacks work: > > A PyObject * named errors is passed in. This may by NULL, > Py_None, 'strict', u'strict', 'ignore', u'ignore', > 'replace', u'replace' or a callable object. > PyCodec_EncodeHandlerForObject maps all of these objects to > one of the three builtin error callbacks > PyCodec_RaiseEncodeErrors (raises an exception), > PyCodec_IgnoreEncodeErrors (returns an empty replacement > string, in effect ignoring the error), > PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode > replacement character to signify to the encoder that it > should choose a suitable replacement character) or directly > returns errors if it is a callable object. When an > unencodable character is encounterd the error handling > callback will be called with the encoding name, the original > unicode object and the error position and must return a > unicode object that will be encoded instead of the offending > character (or the callback may of course raise an > exception). U+FFFD characters in the replacement string will > be replaced with a character that the encoder chooses ('?' > in all cases). Nice. > The implementation of the loop through the string is done in > the following way. A stack with two strings is kept and the > loop always encodes a character from the string at the > stacktop. If an error is encountered and the stack has only > one entry (during encoding of the original string) the > callback is called and the unicode object returned is pushed > on the stack, so the encoding continues with the replacement > string. If the stack has two entries when an error is > encountered, the replacement string itself has an > unencodable character and a normal exception raised. When > the encoder has reached the end of it's current string there > are two possibilities: when the stack contains two entries, > this was the replacement string, so the replacement string > will be poppep from the stack and encoding continues with > the next character from the original string. If the stack > had only one entry, encoding is finished. Very elegant solution ! > (I hope that's enough explanation of the API and implementation) Could you add these docs to the Misc/unicode.txt file ? I will eventually take that file and turn it into a PEP which will then serve as general documentation for these things. > I have renamed the static ...121 function to all lowercase > names. Ok. > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > replacement callback. Hmm, wouldn't that result in a slowdown ? If so, I'd rather leave the special encoder in place, since it is being used a lot in Python and probably some applications too. > PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, > PyCodec_ReplaceEncodeErrors are globally visible because > they have to be available in _codecsmodule.c to wrap them as > Python function objects, but they can't be implemented in > _codecsmodule, because they need to be available to the > encoders in unicodeobject.c (through > PyCodec_EncodeHandlerForObject), but importing the codecs > module might result in an endless recursion, because > importing a module requires unpickling of the bytecode, > which might require decoding utf8, which ... (but this will > only happen, if we implement the same mechanism for the > decoding API) I think that codecs.c is the right place for these APIs. _codecsmodule.c is only meant as Python access wrapper for the internal codecs and nothing more. One thing I noted about the callbacks: they assume that they will always get Unicode objects as input. This is certainly not true in the general case (it is for the codecs you touch in the patch). I think it would be worthwhile to rename the callbacks to include "Unicode" somewhere, e.g. PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but then it points out the application field of the callback rather well. Same for the callbacks exposed through the _codecsmodule. > I have not touched PyUnicode_TranslateCharmap yet, > should this function also support error callbacks? Why would > one want the insert None into the mapping to call the callback? 1. Yes. 2. The user may want to e.g. restrict usage of certain character ranges. In this case the codec would be used to verify the input and an exception would indeed be useful (e.g. say you want to restrict input to Hangul + ASCII). > A remaining problem is how to implement decoding error > callbacks. In Python 2.1 encoding and decoding errors are > handled in the same way with a string value. But with > callbacks it doesn't make sense to use the same callback for > encoding and decoding (like codecs.StreamReaderWriter and > codecs.StreamRecoder do). Decoding callbacks have a > different API. Which arguments should be passed to the > decoding callback, and what is the decoding callback > supposed to do? I'd suggest adding another set of PyCodec_UnicodeDecode...() APIs for this. We'd then have to augment the base classes of the StreamCodecs to provide two attributes for .errors with a fallback solution for the string case (i.s. "strict" can still be used for both directions). > One additional note: It is vital that errors is an > assignable attribute of the StreamWriter. It is already ! > Consider the XML example: For writing an XML DOM tree one > StreamWriter object is used. When a text node is written, > the error handling has to be set to > codecs.xmlreplace_encode_errors, but inside a comment or > processing instruction replacing unencodable characters with > charrefs is not possible, so here codecs.raise_encode_errors > should be used (or better a custom error handler that raises > an error that says "sorry, you can't have unencodable > characters inside a comment") Sure. > BTW, should we continue the discussion in the i18n SIG > mailing list? An email program is much more comfortable than > a HTML textarea! ;) I'd rather keep the discussions on this patch here -- forking it off to the i18n sig will make it very hard to follow up on it. (This HTML area is indeed damn small ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 21:18 Message: Logged In: YES user_id=89016 One additional note: It is vital that errors is an assignable attribute of the StreamWriter. Consider the XML example: For writing an XML DOM tree one StreamWriter object is used. When a text node is written, the error handling has to be set to codecs.xmlreplace_encode_errors, but inside a comment or processing instruction replacing unencodable characters with charrefs is not possible, so here codecs.raise_encode_errors should be used (or better a custom error handler that raises an error that says "sorry, you can't have unencodable characters inside a comment") BTW, should we continue the discussion in the i18n SIG mailing list? An email program is much more comfortable than a HTML textarea! ;) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 20:59 Message: Logged In: YES user_id=89016 How the callbacks work: A PyObject * named errors is passed in. This may by NULL, Py_None, 'strict', u'strict', 'ignore', u'ignore', 'replace', u'replace' or a callable object. PyCodec_EncodeHandlerForObject maps all of these objects to one of the three builtin error callbacks PyCodec_RaiseEncodeErrors (raises an exception), PyCodec_IgnoreEncodeErrors (returns an empty replacement string, in effect ignoring the error), PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode replacement character to signify to the encoder that it should choose a suitable replacement character) or directly returns errors if it is a callable object. When an unencodable character is encounterd the error handling callback will be called with the encoding name, the original unicode object and the error position and must return a unicode object that will be encoded instead of the offending character (or the callback may of course raise an exception). U+FFFD characters in the replacement string will be replaced with a character that the encoder chooses ('?' in all cases). The implementation of the loop through the string is done in the following way. A stack with two strings is kept and the loop always encodes a character from the string at the stacktop. If an error is encountered and the stack has only one entry (during encoding of the original string) the callback is called and the unicode object returned is pushed on the stack, so the encoding continues with the replacement string. If the stack has two entries when an error is encountered, the replacement string itself has an unencodable character and a normal exception raised. When the encoder has reached the end of it's current string there are two possibilities: when the stack contains two entries, this was the replacement string, so the replacement string will be poppep from the stack and encoding continues with the next character from the original string. If the stack had only one entry, encoding is finished. (I hope that's enough explanation of the API and implementation) I have renamed the static ...121 function to all lowercase names. BTW, I guess PyUnicode_EncodeUnicodeEscape could be reimplemented as PyUnicode_EncodeASCII with a \uxxxx replacement callback. PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, PyCodec_ReplaceEncodeErrors are globally visible because they have to be available in _codecsmodule.c to wrap them as Python function objects, but they can't be implemented in _codecsmodule, because they need to be available to the encoders in unicodeobject.c (through PyCodec_EncodeHandlerForObject), but importing the codecs module might result in an endless recursion, because importing a module requires unpickling of the bytecode, which might require decoding utf8, which ... (but this will only happen, if we implement the same mechanism for the decoding API) I have not touched PyUnicode_TranslateCharmap yet, should this function also support error callbacks? Why would one want the insert None into the mapping to call the callback? A remaining problem is how to implement decoding error callbacks. In Python 2.1 encoding and decoding errors are handled in the same way with a string value. But with callbacks it doesn't make sense to use the same callback for encoding and decoding (like codecs.StreamReaderWriter and codecs.StreamRecoder do). Decoding callbacks have a different API. Which arguments should be passed to the decoding callback, and what is the decoding callback supposed to do? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 20:00 Message: Logged In: YES user_id=38388 About the Py_UNICODE*data, int size APIs: Ok, point taken. In general, I think we ought to keep the callback feature as open as possible, so passing in pointers and sizes would not be very useful. BTW, could you summarize how the callback works in a few lines ? About _Encode121: I'd name this _EncodeUCS1 since that's what it is ;-) About the new functions: I was referring to the new static functions which you gave PyUnicode_... names. If these are not supposed to turn into non-static functions, I'd rather have them use lower case names (since that's how the Python internals work too -- most of the times). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 18:56 Message: Logged In: YES user_id=89016 > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. Another problem is, that the callback requires a Python object, so in the PyObject *version, the refcount is incref'd and the object is passed to the callback. The Py_UNICODE*/int version would have to create a new Unicode object from the data. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 18:32 Message: Logged In: YES user_id=89016 > * please don't place more than one C statement on one line > like in: > """ > + unicode = unicode2; unicodepos = > unicode2pos; > + unicode2 = NULL; unicode2pos = 0; > """ OK, done! > * Comments should start with a capital letter and be > prepended > to the section they apply to Fixed! > * There should be spaces between arguments in compares > (a == b) not (a==b) Fixed! > * Where does the name "...Encode121" originate ? encode one-to-one, it implements both ASCII and latin-1 encoding. > * module internal APIs should use lower case names (you > converted some of these to PyUnicode_...() -- this is > normally reserved for APIs which are either marked as > potential candidates for the public API or are very > prominent in the code) Which ones? I introduced a new function for every old one, that had a "const char *errors" argument, and a few new ones in codecs.h, of those PyCodec_EncodeHandlerForObject is vital, because it is used to map for old string arguments to the new function objects. PyCodec_RaiseEncodeErrors can be used in the encoder implementation to raise an encode error, but it could be made static in unicodeobject.h so only those encoders implemented there have access to it. > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. I look through the code and found no situation where the Py_UNICODE*/int version is really used and having two (PyObject *)s (the original and the replacement string), instead of UNICODE*/int and PyObject * made the implementation a little easier, but I can fix that. > Please separate the errors.c patch from this patch -- it > seems totally unrelated to Unicode. PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with four hex digits. I removed it. I'll upload a revised patch as soon as it's done. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 16:29 Message: Logged In: YES user_id=38388 Thanks for the patch -- it looks very impressive !. I'll give it a try later this week. Some first cosmetic tidbits: * please don't place more than one C statement on one line like in: """ + unicode = unicode2; unicodepos = unicode2pos; + unicode2 = NULL; unicode2pos = 0; """ * Comments should start with a capital letter and be prepended to the section they apply to * There should be spaces between arguments in compares (a == b) not (a==b) * Where does the name "...Encode121" originate ? * module internal APIs should use lower case names (you converted some of these to PyUnicode_...() -- this is normally reserved for APIs which are either marked as potential candidates for the public API or are very prominent in the code) One thing which I don't like about your API change is that you removed the Py_UNICODE*data, int size style arguments -- this makes it impossible to use the new APIs on non-Python data or data which is not available as Unicode object. Please separate the errors.c patch from this patch -- it seems totally unrelated to Unicode. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Thu May 2 04:38:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 May 2002 20:38:50 -0700 Subject: [Patches] [ python-Patches-551250 ] Fix for httplib bug with 100 Continue Message-ID: Patches item #551250, was opened at 2002-05-01 23:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551250&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for httplib bug with 100 Continue Initial Comment: This patch fixes a problem with httplib, which gets stuck when it encounters a response code of 100 ("Continue"). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551250&group_id=5470 From noreply@sourceforge.net Thu May 2 06:27:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 May 2002 22:27:17 -0700 Subject: [Patches] [ python-Patches-551273 ] Fix for httplib bug with 100 Continue Message-ID: Patches item #551273, was opened at 2002-05-02 01:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for httplib bug with 100 Continue Initial Comment: This patch fixes a problem with httplib, which gets stuck when it encounters a response code of 100 ("Continue"). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 From noreply@sourceforge.net Thu May 2 07:02:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 May 2002 23:02:48 -0700 Subject: [Patches] [ python-Patches-550555 ] short patch to buffer() documentation Message-ID: Patches item #550555, was opened at 2002-04-30 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550555&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott Gilbert (xscott) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: short patch to buffer() documentation Initial Comment: The documentation incorrectly states that objects returned from the buffer() builtin do not support concatenation or repeating. I don't have an old version of Python at my disposal, but it appears from CVS that they do support concatenation and repeating since version 1.6. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-02 02:02 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libstdtypes.tex revisions 1.90, 1.80.6.7, and 1.52.4.5. Documentation for versions prior to 2.1.x is not being maintained. ---------------------------------------------------------------------- Comment By: Scott Gilbert (xscott) Date: 2002-04-30 20:09 Message: Logged In: YES user_id=38318 Just checked Python 1.5.2 on a Linux box at work. The value returned from buffer() has supported repeat/concat for since at least 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550555&group_id=5470 From noreply@sourceforge.net Thu May 2 14:39:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 06:39:38 -0700 Subject: [Patches] [ python-Patches-551410 ] xrange() optimization Message-ID: Patches item #551410, was opened at 2002-05-02 13:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() optimization Initial Comment: Performance improvement for xrange() when used in loops or list(xrange()). Does NOT change external interface or restart characteristics. Fills the tp_iter and tp_iternext slots to provide faster looping than access via sq_item wrapped by an iterobject. Times about 25% faster than the original. Brings the performance to within 5 to 7% of range(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 From noreply@sourceforge.net Thu May 2 15:04:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 07:04:24 -0700 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 11:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Michael Hudson (mwh) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-02 14:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 19:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 15:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 14:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 15:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 15:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 15:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Thu May 2 15:06:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 07:06:16 -0700 Subject: [Patches] [ python-Patches-551008 ] Cygwin operator and cPickle patch Message-ID: Patches item #551008, was opened at 2002-05-01 14:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551008&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin operator and cPickle patch Initial Comment: This patch re-enables the clean building of the operator and cPickle modules under Cygwin. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-02 14:06 Message: Logged In: YES user_id=6656 The file is called boolobject.h.diff and patches boolobject.h. I'm guessing that's not the file you meant to attach to this report? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551008&group_id=5470 From noreply@sourceforge.net Thu May 2 15:08:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 07:08:05 -0700 Subject: [Patches] [ python-Patches-551093 ] Cygwin forced --enable-shared patch Message-ID: Patches item #551093, was opened at 2002-05-01 17:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Martin v. Löwis (loewis) Summary: Cygwin forced --enable-shared patch Initial Comment: This patch forces the configure --enable-shared option under Cygwin even if not specified by the user. Cygwin, like Win32, requires a shared python library. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-02 14:08 Message: Logged In: YES user_id=6656 Martin, is this good style? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 From noreply@sourceforge.net Thu May 2 15:31:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 07:31:52 -0700 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 06:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Michael Hudson (mwh) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-02 10:31 Message: Logged In: YES user_id=6380 Giving Jason checkin permission is probably the best solution here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 10:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 15:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 10:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 09:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 10:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 10:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 10:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Thu May 2 15:49:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 07:49:48 -0700 Subject: [Patches] [ python-Patches-551273 ] Fix for httplib bug with 100 Continue Message-ID: Patches item #551273, was opened at 2002-05-02 05:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) >Assigned to: Jeremy Hylton (jhylton) Summary: Fix for httplib bug with 100 Continue Initial Comment: This patch fixes a problem with httplib, which gets stuck when it encounters a response code of 100 ("Continue"). ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-05-02 14:49 Message: Logged In: YES user_id=31392 Do you have some URLs that generate 100 responses so that I can test the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 From noreply@sourceforge.net Thu May 2 16:05:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 08:05:18 -0700 Subject: [Patches] [ python-Patches-551008 ] Cygwin operator and cPickle patch Message-ID: Patches item #551008, was opened at 2002-05-01 06:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551008&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin operator and cPickle patch Initial Comment: This patch re-enables the clean building of the operator and cPickle modules under Cygwin. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-02 07:05 Message: Logged In: YES user_id=86216 No, the patch file is correct: .../operator.c:65: undefined reference to `PyBool_FromLong' and .../cPickle.c:2640: undefined reference to `PyBool_FromLong' Sorry, for not being more obvious. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 06:06 Message: Logged In: YES user_id=6656 The file is called boolobject.h.diff and patches boolobject.h. I'm guessing that's not the file you meant to attach to this report? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551008&group_id=5470 From noreply@sourceforge.net Thu May 2 18:25:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 10:25:40 -0700 Subject: [Patches] [ python-Patches-551273 ] Fix for httplib bug with 100 Continue Message-ID: Patches item #551273, was opened at 2002-05-02 01:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: Jeremy Hylton (jhylton) Summary: Fix for httplib bug with 100 Continue Initial Comment: This patch fixes a problem with httplib, which gets stuck when it encounters a response code of 100 ("Continue"). ---------------------------------------------------------------------- >Comment By: Bob Kline (bkline) Date: 2002-05-02 13:25 Message: Logged In: YES user_id=291529 Yes. Email me privately and I'll send you a python script which establishes a connection to such a server. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-05-02 10:49 Message: Logged In: YES user_id=31392 Do you have some URLs that generate 100 responses so that I can test the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 From noreply@sourceforge.net Thu May 2 18:29:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 10:29:00 -0700 Subject: [Patches] [ python-Patches-551093 ] Cygwin forced --enable-shared patch Message-ID: Patches item #551093, was opened at 2002-05-01 19:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 Category: Build Group: None Status: Open >Resolution: Rejected Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: Cygwin forced --enable-shared patch Initial Comment: This patch forces the configure --enable-shared option under Cygwin even if not specified by the user. Cygwin, like Win32, requires a shared python library. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 19:28 Message: Logged In: YES user_id=21627 Given that cygwin has indeed the same requirements as the VC++ build, I think it is fine to let enable-shared *default* to shared. However, it is not good style to force it: it is perfectly sensible to build a python.exe/libpython.a, as the requirement for a shared python.dll only comes up when you want to load modules dynamically. In cases where you can statically link alll modules that you will ever need (in particular for frozen applications), it would be unfortunate if you are forced to use a python dll (since it would not allow for stand-alone binaries). Hence, I'm rejecting the patch in its current form; feel free to resubmit it in a form where an explicit --disable-shared would override the default. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 16:08 Message: Logged In: YES user_id=6656 Martin, is this good style? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 From noreply@sourceforge.net Thu May 2 18:31:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 10:31:03 -0700 Subject: [Patches] [ python-Patches-551011 ] Cygwin pyexpat patch Message-ID: Patches item #551011, was opened at 2002-05-01 16:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551011&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Martin v. Löwis (loewis) Summary: Cygwin pyexpat patch Initial Comment: This patch enables the clean building of the pyexpat module under Cygwin. Note that this patch is a "cleaner" version of the one in following: http://mail.python.org/pipermail/xml-sig/2002-January/006943.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551011&group_id=5470 From noreply@sourceforge.net Thu May 2 18:33:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 10:33:48 -0700 Subject: [Patches] [ python-Patches-551009 ] Cygwin array patch Message-ID: Patches item #551009, was opened at 2002-05-01 16:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551009&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin array patch Initial Comment: This patch re-enables the clean building of the array module under Cygwin. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 19:33 Message: Logged In: YES user_id=21627 Can you please explain why this is necessary? It looks like a bug in cygwin to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551009&group_id=5470 From noreply@sourceforge.net Thu May 2 18:39:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 10:39:56 -0700 Subject: [Patches] [ python-Patches-550804 ] Make os.environ.copy() return a copy Message-ID: Patches item #550804, was opened at 2002-04-30 23:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550804&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Make os.environ.copy() return a copy Initial Comment: As reported by Jeff Epler in python-list: """ Under Python2.1 and earlier (back to 1.5.2): >>> import os >>> os.environ.copy()['COPY_HUH'] = "not really" >>> print os.environ['COPY_HUH'] not really Under even 2.3a0 (CVS): >>> import os >>> os.environ.copy()['COPY_HUH'] = "not really" >>> os.system("echo $COPY_HUH") not really 0 """ This patch fixes this behavior, by returning a real dictionary from the copy() operation. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 19:39 Message: Logged In: YES user_id=21627 Thanks for the patch; applied as os.py 1.56. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550804&group_id=5470 From noreply@sourceforge.net Thu May 2 18:45:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 10:45:13 -0700 Subject: [Patches] [ python-Patches-549975 ] block support for builtin iter() Message-ID: Patches item #549975, was opened at 2002-04-29 03:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549975&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: block support for builtin iter() Initial Comment: >>> import xiter >>> for i in xiter.iter(range(40), blocksize=12): ... print i ... [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11] [12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23] [24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35] [36, 37, 38, 39] (attached simple patch as extension module with unittest and demonstration script) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 19:45 Message: Logged In: YES user_id=21627 As this is already a distutils package, I suggest that you distribute the code to users first, before suggesting it to be included into Python. It might be best to put it on your home page, and add a link in the Vaults of Parnassus. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549975&group_id=5470 From noreply@sourceforge.net Thu May 2 20:43:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 12:43:59 -0700 Subject: [Patches] [ python-Patches-551009 ] Cygwin array patch Message-ID: Patches item #551009, was opened at 2002-05-01 06:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551009&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin array patch Initial Comment: This patch re-enables the clean building of the array module under Cygwin. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-02 11:43 Message: Logged In: YES user_id=86216 I'm getting errors like the following: .../arraymodule.c:1700: initializer element is not constant .../arraymodule.c:1700: (near initialization for `Arraytype.tp_getattro') So I just used the following to solve this problem: http://www.python.org/doc/FAQ.html#3.24 Besides, we already have the following in Modules/socketmodule.c: PySocketSock_Type.tp_getattro = PyObject_GenericGetAttr; PySocketSock_Type.tp_alloc = PyType_GenericAlloc; PySocketSock_Type.tp_free = PyObject_Del; Is the above explanation satisfactory? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 09:33 Message: Logged In: YES user_id=21627 Can you please explain why this is necessary? It looks like a bug in cygwin to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551009&group_id=5470 From noreply@sourceforge.net Thu May 2 21:09:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 13:09:09 -0700 Subject: [Patches] [ python-Patches-551093 ] Cygwin forced --enable-shared patch Message-ID: Patches item #551093, was opened at 2002-05-01 09:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 Category: Build Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: Cygwin forced --enable-shared patch Initial Comment: This patch forces the configure --enable-shared option under Cygwin even if not specified by the user. Cygwin, like Win32, requires a shared python library. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-02 12:09 Message: Logged In: YES user_id=86216 Is the attached any better? BTW, can one build Win32 Python statically? Note that currently, Cygwin Python cannot be built statically. To do so would require additional work... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 09:28 Message: Logged In: YES user_id=21627 Given that cygwin has indeed the same requirements as the VC++ build, I think it is fine to let enable-shared *default* to shared. However, it is not good style to force it: it is perfectly sensible to build a python.exe/libpython.a, as the requirement for a shared python.dll only comes up when you want to load modules dynamically. In cases where you can statically link alll modules that you will ever need (in particular for frozen applications), it would be unfortunate if you are forced to use a python dll (since it would not allow for stand-alone binaries). Hence, I'm rejecting the patch in its current form; feel free to resubmit it in a form where an explicit --disable-shared would override the default. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 06:08 Message: Logged In: YES user_id=6656 Martin, is this good style? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 From noreply@sourceforge.net Thu May 2 21:12:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 13:12:29 -0700 Subject: [Patches] [ python-Patches-551009 ] Cygwin array patch Message-ID: Patches item #551009, was opened at 2002-05-01 16:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551009&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin array patch Initial Comment: This patch re-enables the clean building of the array module under Cygwin. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:12 Message: Logged In: YES user_id=21627 Thanks for the patch; this is committed as arraymodule.c 2.71. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-02 21:43 Message: Logged In: YES user_id=86216 I'm getting errors like the following: .../arraymodule.c:1700: initializer element is not constant .../arraymodule.c:1700: (near initialization for `Arraytype.tp_getattro') So I just used the following to solve this problem: http://www.python.org/doc/FAQ.html#3.24 Besides, we already have the following in Modules/socketmodule.c: PySocketSock_Type.tp_getattro = PyObject_GenericGetAttr; PySocketSock_Type.tp_alloc = PyType_GenericAlloc; PySocketSock_Type.tp_free = PyObject_Del; Is the above explanation satisfactory? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 19:33 Message: Logged In: YES user_id=21627 Can you please explain why this is necessary? It looks like a bug in cygwin to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551009&group_id=5470 From noreply@sourceforge.net Thu May 2 21:18:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 13:18:10 -0700 Subject: [Patches] [ python-Patches-551410 ] xrange() optimization Message-ID: Patches item #551410, was opened at 2002-05-02 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() optimization Initial Comment: Performance improvement for xrange() when used in loops or list(xrange()). Does NOT change external interface or restart characteristics. Fills the tp_iter and tp_iternext slots to provide faster looping than access via sq_item wrapped by an iterobject. Times about 25% faster than the original. Brings the performance to within 5 to 7% of range(). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:18 Message: Logged In: YES user_id=21627 Can you please update this patch to the current CVS (rangeobject.c 2.35)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 From noreply@sourceforge.net Thu May 2 21:19:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 13:19:31 -0700 Subject: [Patches] [ python-Patches-551250 ] Fix for httplib bug with 100 Continue Message-ID: Patches item #551250, was opened at 2002-05-02 05:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551250&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for httplib bug with 100 Continue Initial Comment: This patch fixes a problem with httplib, which gets stuck when it encounters a response code of 100 ("Continue"). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:19 Message: Logged In: YES user_id=21627 Duplicate of 551273. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551250&group_id=5470 From noreply@sourceforge.net Thu May 2 21:20:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 13:20:57 -0700 Subject: [Patches] [ python-Patches-498149 ] httplib.py screws up on 100 response Message-ID: Patches item #498149, was opened at 2001-12-31 20:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498149&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jens B. Jorgensen (jensbjorgensen) Assigned to: Greg Stein (gstein) Summary: httplib.py screws up on 100 response Initial Comment: Bug 227361 details a problem where httplib.py behaves poorly when a server returns an HTTP 100 response code. This is pretty annoying since Microsoft IIS ASP pages are notorious for first returning a 100 code and then returning the "real" response. What is worse, httplib.py sets the self.__state to a value which prevents you from trying to get the next response so you can get the value. Once you get the 100 response code your object is stuck and you have no way of getting the response. I needed to solve this problem and did so. I found that a bug had been logged and that the assignee (and maintainer?) indicated a preference for a solution where the HTTPResponse object would transparently consume the 100 responses in the begin() method. My simple change adopts this philosophy and does just that. It will loop, consuming 100 responses until a non-100 response is return. For the curious, yes, servers can be observed returning more than one 100 response. All header information returned in the 100 responses is overwritten and lost. I don't think this will be much of a concern for anyone. I also concur that transparently consuming the 100 responses is the most appropriate thing to do. It's clean, doesn't seem to have any obvious gothchas (haven't thought about how it could affect proxies or the like) and will prevent everyone from having to, say, write their own loops to chew through the 100 responses on their own. I've really only added 4 lines even though the patch is bigger. I just did one quick test with the change to the CVS version since that's not the version that I'm using but the changes are really slight so I'm not too worried. And finally, I'm using: TALLAN2$ python ActivePython 2.1, build 211 (ActiveState) based on Python 2.1 (#15, Jun 18 2001, 21:42:28) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:20 Message: Logged In: YES user_id=21627 How does this patch relate to 551273? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=498149&group_id=5470 From noreply@sourceforge.net Thu May 2 21:21:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 13:21:01 -0700 Subject: [Patches] [ python-Patches-551273 ] Fix for httplib bug with 100 Continue Message-ID: Patches item #551273, was opened at 2002-05-02 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: Jeremy Hylton (jhylton) Summary: Fix for httplib bug with 100 Continue Initial Comment: This patch fixes a problem with httplib, which gets stuck when it encounters a response code of 100 ("Continue"). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:21 Message: Logged In: YES user_id=21627 How does this patch relate to 498149? ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2002-05-02 19:25 Message: Logged In: YES user_id=291529 Yes. Email me privately and I'll send you a python script which establishes a connection to such a server. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-05-02 16:49 Message: Logged In: YES user_id=31392 Do you have some URLs that generate 100 responses so that I can test the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 From noreply@sourceforge.net Thu May 2 21:23:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 13:23:55 -0700 Subject: [Patches] [ python-Patches-551008 ] Cygwin operator and cPickle patch Message-ID: Patches item #551008, was opened at 2002-05-01 16:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551008&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin operator and cPickle patch Initial Comment: This patch re-enables the clean building of the operator and cPickle modules under Cygwin. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:23 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as boolobject.h 1.3. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-02 17:05 Message: Logged In: YES user_id=86216 No, the patch file is correct: .../operator.c:65: undefined reference to `PyBool_FromLong' and .../cPickle.c:2640: undefined reference to `PyBool_FromLong' Sorry, for not being more obvious. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 16:06 Message: Logged In: YES user_id=6656 The file is called boolobject.h.diff and patches boolobject.h. I'm guessing that's not the file you meant to attach to this report? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551008&group_id=5470 From noreply@sourceforge.net Thu May 2 21:47:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 13:47:56 -0700 Subject: [Patches] [ python-Patches-538395 ] ae* modules: handle type inheritance Message-ID: Patches item #538395, was opened at 2002-04-02 10:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=538395&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Preston (dsposx) Assigned to: Jack Jansen (jackjansen) Summary: ae* modules: handle type inheritance Initial Comment: The gensuitemodule script creates Python classes out of AppleScript types. It keeps track of properties in _propdict and elements in _elemdict. However, gensuitemodule does not accurately replicate the AppleScript inheritance heirarchy, and __getattr__ only looks in self._propdict and self._elemdict, therefore not finding elements and properties defined in superclasses. Attached is a patch which: 1) Correctly identifies an AppleScript type's superclasses, and defines the Python classes with these superclasses. Since not all names may be defined by the time a new class is defined, this is accomplished by setting a new class' __bases__ after all names are defined. 2) Changes __getattr__ to recurse superclasses while looking through _propdict and _elemdict. It also contains small usability enhancements which will automatically look for a .want or .which property when you are creating specifiers. ---------------------------------------------------------------------- >Comment By: Donovan Preston (dsposx) Date: 2002-05-02 12:47 Message: Logged In: YES user_id=111050 Hi Jack, I finally got around to reimplementing the functionality of the patch given your suggestions. I think it should be fairly bulletproof. Due to circular imports I ended up having to do more work in the package's __init__.py. The upshot of flattening the lookup dicts is that it gets done once, and then after that name lookups are lightning fast. In our production environment the speedup was impressive :-) Thanks for the suggestions. Donovan ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-03 12:16 Message: Logged In: YES user_id=45365 Donovan, two comments-on-your-comments: - You're absolutely right about the module names. Pickle also uses names, and it's probably the only way to do it. - You're also absolutely right about how to update the _elemdict and _propdict. Or, as Jean-Luc Picard would say: "Make it so!" :-) Oh yes, on the production code/merging problem: aside from Martin's comments here's another tip: make a copy of the subtree that contains the conflict section (why not the whole Mac subtree in your case) and make sure you keep the CVS directories. Start hacking in this copy. Once you're satisfied do a commit from there. As long as you keep the CVS directory with the files there's little that can go wrong. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-03 00:29 Message: Logged In: YES user_id=21627 cvs update will keep a copy of the original file (the one you edited) if it has to merge changes; it will name it .#.. So in no case cvs will destroy your changes. Normally, merging works quite well. If it finds a conflict, it will print a 'C' on update, and put a conflict marker in the file. The stuff above the ===== is your code, the one below is the CVS code. If you want to find out what cvs would do, use 'cvs status'. If you don't want cvs to do merging, the following procedure will work cvs diff -u >patches patch -p0 -R 1.22 by hand without doing a cvs update? I think a cvs update (plus some manual work;-) should solve this. Third: the passing of modules by name (to the decoding routines) seems error prone and not too elegant. Can't you pass the modules themselves in stead of their names? It would also save extra imports in the decoders. Fourth: assigning to __bases__ seems like rather a big hack. Can't we generate the classes with a helper class, similarly to the event helper class in the __init__.py modules: FooApp/Foo_Suite.py would contain the class foo sketched above, and FooApp.__init__.py would contain import othersuite.superfoo import Foo_Suite.foo class foo(Foo_Suite.foo, othersuite.superfoo): pass Fifth, and least important: you're manually iterating over the base classes for lookup. Couldn't we statically combine the _propdict and _elemdict's of the base classes during class declaration, so that at lookup time we'd need only a single dictionary lookup? The "class foo" body in __init__.py would then become something like _propdict = aetools.flatten_dicts( foosuite.foo._propdict, othersuite.superfoo._propdict) and similar for elemdict. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=538395&group_id=5470 From noreply@sourceforge.net Thu May 2 23:12:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 15:12:57 -0700 Subject: [Patches] [ python-Patches-539487 ] build info docs from tex sources Message-ID: Patches item #539487, was opened at 2002-04-04 22:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=539487&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: Rejected Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: build info docs from tex sources Initial Comment: This patch adds Milan Zamazals conversion script and modifies the mkinfo script to build the info doc files from the latex sources. Currently, the mac, doc and inst tex files are not handled. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-05-02 22:12 Message: Logged In: YES user_id=60903 reset the resolution to None ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-04-28 14:39 Message: Logged In: YES user_id=60903 Find below the updated patch, which explicitely checks for GNU Emacs 21. So this is more robust than the previous one. Having the choice of building no info docs with the current version, building the info docs with a specific tool is a better solution. > Until then, I'm glad to publish contributed GNU info > versions provided by community members. give them a tool for fishing, not fishes ... ;-) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-09 14:17 Message: Logged In: YES user_id=3066 I just installed emacs 20.7 'cause those are the RPMs that came with the distro I have on this box (RedHat 7.2), and that produced a similar error. I'll have to ask that a more robust patch be available before I can spend more time on it; this one will be marked as rejected. Until then, I'm glad to publish contributed GNU info versions provided by community members. For the record, here's the specific error output I got and the FSF Emacs version info: grendel(.../r22-maint/Doc); make info cd info && make make[1]: Entering directory `/home/fdrake/projects/python/r22-maint/Doc/info' ../tools/mkinfo ../api/api.tex python-api.info emacs -batch -q --no-site-file -l /home/fdrake/projects/python/r22-maint/Doc/tools/py2texi.el --eval (setq py2texi-dirs '("./" "../texinputs/" "/home/fdrake/projects/python/r22-maint/Doc/api")) --eval (py2texi "/home/fdrake/projects/python/r22-maint/Doc/api/api.tex") -f kill-emacs Mark set Args out of range: 27914, 27916 make[1]: *** [python-api.info] Error 255 make[1]: Leaving directory `/home/fdrake/projects/python/r22-maint/Doc/info' make: *** [info] Error 2 [2] grendel(.../r22-maint/Doc); emacs --version GNU Emacs 20.7.1 Copyright (C) 1999 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-04-09 08:05 Message: Logged In: YES user_id=60903 Yes, forget to mention that Milan said, it only works for emacs. I built the info docs using emacs-21.2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-08 21:24 Message: Logged In: YES user_id=3066 For the record, here's the specific errors I get when using XEmacs with this patch on the current release22-maint branch (hopefully SF won't munge them too badly): grendel(.../r22-maint/Doc); make EMACS=xemacs info cd info && make make[1]: Entering directory `/home/fdrake/projects/python/r22-maint/Doc/info' ../tools/mkinfo ../api/api.tex python-api.info xemacs -batch -q --no-site-file -l /home/fdrake/projects/python/r22-maint/Doc/tools/py2texi.el --eval (setq py2texi-dirs '("./" "../texinputs/" "/home/fdrake/projects/python/r22-maint/Doc/api")) --eval (py2texi "/home/fdrake/projects/python/r22-maint/Doc/api/api.tex") -f kill-emacs Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/aspell-init.el... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/mew-init.el... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/psgml-init.el... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/xemacs-po-mode-init.el... Mark set Args out of range: 72, 132 xemacs exiting. make[1]: *** [python-api.info] Error 255 make[1]: Leaving directory `/home/fdrake/projects/python/r22-maint/Doc/info' make: *** [info] Error 2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-08 21:19 Message: Logged In: YES user_id=3066 I'll add a note here just in case: This patch applies to the 2.3 development as well as 2.2 maintenance tree. This still seems to suffer the problems that all versions of this conversion have suffered; it isn't portable between FSF Emacs and XEmacs. I'll see about installing FSF Emacs to see if it'll work for me there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=539487&group_id=5470 From noreply@sourceforge.net Thu May 2 23:29:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 15:29:00 -0700 Subject: [Patches] [ python-Patches-551273 ] Fix for httplib bug with 100 Continue Message-ID: Patches item #551273, was opened at 2002-05-02 01:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Bob Kline (bkline) Assigned to: Jeremy Hylton (jhylton) Summary: Fix for httplib bug with 100 Continue Initial Comment: This patch fixes a problem with httplib, which gets stuck when it encounters a response code of 100 ("Continue"). ---------------------------------------------------------------------- >Comment By: Bob Kline (bkline) Date: 2002-05-02 18:29 Message: Logged In: YES user_id=291529 They both address the same bug. The one submitted by Jens appears to have been ignored. Hopefully one of our patches will be applied; it makes no difference to me which one. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 16:21 Message: Logged In: YES user_id=21627 How does this patch relate to 498149? ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2002-05-02 13:25 Message: Logged In: YES user_id=291529 Yes. Email me privately and I'll send you a python script which establishes a connection to such a server. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-05-02 10:49 Message: Logged In: YES user_id=31392 Do you have some URLs that generate 100 responses so that I can test the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551273&group_id=5470 From noreply@sourceforge.net Fri May 3 05:55:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 21:55:41 -0700 Subject: [Patches] [ python-Patches-539487 ] build info docs from tex sources Message-ID: Patches item #539487, was opened at 2002-04-04 17:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=539487&group_id=5470 Category: Documentation Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: build info docs from tex sources Initial Comment: This patch adds Milan Zamazals conversion script and modifies the mkinfo script to build the info doc files from the latex sources. Currently, the mac, doc and inst tex files are not handled. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-03 00:55 Message: Logged In: YES user_id=3066 Accepted for both the 2.2 maintenance branch and the trunk. (It still doesn't work for me, but reasonably reports that it can't run the expected version of Emacs.) Checked in as: Makefile 1.242, 1.235.2.1.2.9 info/Makefile 1.8, 1.7.16.1 info/python.dir 1.4, 1.2.30.2 tools/mkinfo 1.3, 1.2.30.1 tools/py2texi.el 1.1, 1.1.2.1 ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-05-02 18:12 Message: Logged In: YES user_id=60903 reset the resolution to None ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-04-28 10:39 Message: Logged In: YES user_id=60903 Find below the updated patch, which explicitely checks for GNU Emacs 21. So this is more robust than the previous one. Having the choice of building no info docs with the current version, building the info docs with a specific tool is a better solution. > Until then, I'm glad to publish contributed GNU info > versions provided by community members. give them a tool for fishing, not fishes ... ;-) ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-09 10:17 Message: Logged In: YES user_id=3066 I just installed emacs 20.7 'cause those are the RPMs that came with the distro I have on this box (RedHat 7.2), and that produced a similar error. I'll have to ask that a more robust patch be available before I can spend more time on it; this one will be marked as rejected. Until then, I'm glad to publish contributed GNU info versions provided by community members. For the record, here's the specific error output I got and the FSF Emacs version info: grendel(.../r22-maint/Doc); make info cd info && make make[1]: Entering directory `/home/fdrake/projects/python/r22-maint/Doc/info' ../tools/mkinfo ../api/api.tex python-api.info emacs -batch -q --no-site-file -l /home/fdrake/projects/python/r22-maint/Doc/tools/py2texi.el --eval (setq py2texi-dirs '("./" "../texinputs/" "/home/fdrake/projects/python/r22-maint/Doc/api")) --eval (py2texi "/home/fdrake/projects/python/r22-maint/Doc/api/api.tex") -f kill-emacs Mark set Args out of range: 27914, 27916 make[1]: *** [python-api.info] Error 255 make[1]: Leaving directory `/home/fdrake/projects/python/r22-maint/Doc/info' make: *** [info] Error 2 [2] grendel(.../r22-maint/Doc); emacs --version GNU Emacs 20.7.1 Copyright (C) 1999 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-04-09 04:05 Message: Logged In: YES user_id=60903 Yes, forget to mention that Milan said, it only works for emacs. I built the info docs using emacs-21.2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-08 17:24 Message: Logged In: YES user_id=3066 For the record, here's the specific errors I get when using XEmacs with this patch on the current release22-maint branch (hopefully SF won't munge them too badly): grendel(.../r22-maint/Doc); make EMACS=xemacs info cd info && make make[1]: Entering directory `/home/fdrake/projects/python/r22-maint/Doc/info' ../tools/mkinfo ../api/api.tex python-api.info xemacs -batch -q --no-site-file -l /home/fdrake/projects/python/r22-maint/Doc/tools/py2texi.el --eval (setq py2texi-dirs '("./" "../texinputs/" "/home/fdrake/projects/python/r22-maint/Doc/api")) --eval (py2texi "/home/fdrake/projects/python/r22-maint/Doc/api/api.tex") -f kill-emacs Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/aspell-init.el... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/mew-init.el... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/psgml-init.el... Loading /usr/lib/xemacs/xemacs-packages/lisp/site-start.d/xemacs-po-mode-init.el... Mark set Args out of range: 72, 132 xemacs exiting. make[1]: *** [python-api.info] Error 255 make[1]: Leaving directory `/home/fdrake/projects/python/r22-maint/Doc/info' make: *** [info] Error 2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-08 17:19 Message: Logged In: YES user_id=3066 I'll add a note here just in case: This patch applies to the 2.3 development as well as 2.2 maintenance tree. This still seems to suffer the problems that all versions of this conversion have suffered; it isn't portable between FSF Emacs and XEmacs. I'll see about installing FSF Emacs to see if it'll work for me there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=539487&group_id=5470 From noreply@sourceforge.net Fri May 3 06:54:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 22:54:40 -0700 Subject: [Patches] [ python-Patches-551093 ] Cygwin forced --enable-shared patch Message-ID: Patches item #551093, was opened at 2002-05-01 19:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: Cygwin forced --enable-shared patch Initial Comment: This patch forces the configure --enable-shared option under Cygwin even if not specified by the user. Cygwin, like Win32, requires a shared python library. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-03 07:54 Message: Logged In: YES user_id=21627 That patch looks fine, applied as configure.in 1.314, configure 1.304. As for building Python statically: the MSVC project files certainly don't support it. I haven't tried, but I can see no reason why this configuration couldn't work. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-02 22:09 Message: Logged In: YES user_id=86216 Is the attached any better? BTW, can one build Win32 Python statically? Note that currently, Cygwin Python cannot be built statically. To do so would require additional work... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 19:28 Message: Logged In: YES user_id=21627 Given that cygwin has indeed the same requirements as the VC++ build, I think it is fine to let enable-shared *default* to shared. However, it is not good style to force it: it is perfectly sensible to build a python.exe/libpython.a, as the requirement for a shared python.dll only comes up when you want to load modules dynamically. In cases where you can statically link alll modules that you will ever need (in particular for frozen applications), it would be unfortunate if you are forced to use a python dll (since it would not allow for stand-alone binaries). Hence, I'm rejecting the patch in its current form; feel free to resubmit it in a form where an explicit --disable-shared would override the default. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 16:08 Message: Logged In: YES user_id=6656 Martin, is this good style? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 From noreply@sourceforge.net Fri May 3 07:04:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 May 2002 23:04:08 -0700 Subject: [Patches] [ python-Patches-550192 ] Set softspace to 0 in raw_input() Message-ID: Patches item #550192, was opened at 2002-04-29 16:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550192&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Set softspace to 0 in raw_input() Initial Comment: Setting softspace to 0 in raw_input() makes it behave as expected when a "print 'something'," precedes the raw_input() call, with or without a prompt argument. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-03 08:04 Message: Logged In: YES user_id=21627 The checking logic for a lost stdout appears to be broken: it should already check for an exception right when verifying whether stdout isatty. Can you incorporate such cleanup in your patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550192&group_id=5470 From noreply@sourceforge.net Fri May 3 09:28:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 01:28:04 -0700 Subject: [Patches] [ python-Patches-550551 ] Read/Write buffers from buffer() Message-ID: Patches item #550551, was opened at 2002-04-30 09:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550551&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: Scott Gilbert (xscott) Assigned to: Nobody/Anonymous (nobody) Summary: Read/Write buffers from buffer() Initial Comment: The buffer() builtin does not currently allow the creation of read-write buffers. So there is no way from pure Python code to manipulate objects which support getting a writable pointer via their PyBufferProcs. This patch tries to create a read- write buffer first, and if that fails it will return a read-only buffer object as before. It's tempting to check if the PyBufferProcs has the bf_getwritebuffer pointer and simply return PyBuffer_FromReadWriteObject(...) in this case. This ends up being incorrect for PyStrings since they do have the bf_getwritebuffer pointer, but that always sets an exception. ---------------------------------------------------------------------- >Comment By: Scott Gilbert (xscott) Date: 2002-05-03 08:28 Message: Logged In: YES user_id=38318 This patch should not be accepted until another one fixing a bug in PyBufferObjects is accepter. So please back burner this one until further notice. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550551&group_id=5470 From noreply@sourceforge.net Fri May 3 16:23:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 08:23:33 -0700 Subject: [Patches] [ python-Patches-551093 ] Cygwin forced --enable-shared patch Message-ID: Patches item #551093, was opened at 2002-05-01 09:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 Category: Build Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: Cygwin forced --enable-shared patch Initial Comment: This patch forces the configure --enable-shared option under Cygwin even if not specified by the user. Cygwin, like Win32, requires a shared python library. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-03 07:23 Message: Logged In: YES user_id=86216 I just tried Cygwin and its possible albeit painful. One must edit their Modules/Setup file to make "all" standard modules static too. Otherwise, when the interpretter loads a standard module it goes bang! I presume that Win32 would have similar problems. BTW, thanks for accepting my patch take 2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 21:54 Message: Logged In: YES user_id=21627 That patch looks fine, applied as configure.in 1.314, configure 1.304. As for building Python statically: the MSVC project files certainly don't support it. I haven't tried, but I can see no reason why this configuration couldn't work. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-02 12:09 Message: Logged In: YES user_id=86216 Is the attached any better? BTW, can one build Win32 Python statically? Note that currently, Cygwin Python cannot be built statically. To do so would require additional work... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 09:28 Message: Logged In: YES user_id=21627 Given that cygwin has indeed the same requirements as the VC++ build, I think it is fine to let enable-shared *default* to shared. However, it is not good style to force it: it is perfectly sensible to build a python.exe/libpython.a, as the requirement for a shared python.dll only comes up when you want to load modules dynamically. In cases where you can statically link alll modules that you will ever need (in particular for frozen applications), it would be unfortunate if you are forced to use a python dll (since it would not allow for stand-alone binaries). Hence, I'm rejecting the patch in its current form; feel free to resubmit it in a form where an explicit --disable-shared would override the default. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 06:08 Message: Logged In: YES user_id=6656 Martin, is this good style? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 From noreply@sourceforge.net Fri May 3 16:46:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 08:46:27 -0700 Subject: [Patches] [ python-Patches-551093 ] Cygwin forced --enable-shared patch Message-ID: Patches item #551093, was opened at 2002-05-01 19:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 Category: Build Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: Cygwin forced --enable-shared patch Initial Comment: This patch forces the configure --enable-shared option under Cygwin even if not specified by the user. Cygwin, like Win32, requires a shared python library. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-03 17:46 Message: Logged In: YES user_id=21627 That you have to edit Modules/Setup to get modules linked statically is the standard procedure on Unix; this is what it always was. With MSVC, you would normally create a project to incorporate all source code, since the Modules/Setup mechanism is not available. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-03 17:23 Message: Logged In: YES user_id=86216 I just tried Cygwin and its possible albeit painful. One must edit their Modules/Setup file to make "all" standard modules static too. Otherwise, when the interpretter loads a standard module it goes bang! I presume that Win32 would have similar problems. BTW, thanks for accepting my patch take 2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-03 07:54 Message: Logged In: YES user_id=21627 That patch looks fine, applied as configure.in 1.314, configure 1.304. As for building Python statically: the MSVC project files certainly don't support it. I haven't tried, but I can see no reason why this configuration couldn't work. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-02 22:09 Message: Logged In: YES user_id=86216 Is the attached any better? BTW, can one build Win32 Python statically? Note that currently, Cygwin Python cannot be built statically. To do so would require additional work... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 19:28 Message: Logged In: YES user_id=21627 Given that cygwin has indeed the same requirements as the VC++ build, I think it is fine to let enable-shared *default* to shared. However, it is not good style to force it: it is perfectly sensible to build a python.exe/libpython.a, as the requirement for a shared python.dll only comes up when you want to load modules dynamically. In cases where you can statically link alll modules that you will ever need (in particular for frozen applications), it would be unfortunate if you are forced to use a python dll (since it would not allow for stand-alone binaries). Hence, I'm rejecting the patch in its current form; feel free to resubmit it in a form where an explicit --disable-shared would override the default. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 16:08 Message: Logged In: YES user_id=6656 Martin, is this good style? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 From noreply@sourceforge.net Fri May 3 17:21:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 09:21:10 -0700 Subject: [Patches] [ python-Patches-551911 ] test_commands.py using . incorrectly Message-ID: Patches item #551911, was opened at 2002-05-03 16:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551911&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: test_commands.py using . incorrectly Initial Comment: test_commands.py was revised recently to look at the root directory (/.) rather than the file (/bin/ls). A regular expression comparison against /bin/ls was also changed to refer to "/.". But that means "/" followed by anything, not "/" followed by "." It should have been changed to "/\.", as per this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551911&group_id=5470 From noreply@sourceforge.net Fri May 3 17:24:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 09:24:09 -0700 Subject: [Patches] [ python-Patches-551915 ] GC collection frequency bug Message-ID: Patches item #551915, was opened at 2002-05-03 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551915&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Dunbar (danieldunbar) Assigned to: Nobody/Anonymous (nobody) Summary: GC collection frequency bug Initial Comment: - bug fix, garbage collection frequency was incorrect in the presence of empty generations. The generational cycle collection algorithm skipped calling collect() on empty generations, however collect() has the side effect of resetting the 'allocated' global, on which the collection frequency is based. The result was that in pathological cases every call to PyObject_GC_Malloc could trigger a collection, for an extended number of calls to _GC_Malloc. Note that this bug only has a noticable effect when many calls to _GC_Malloc are made without tracking any of the returned objects. It also raises the question of whether allocated should be tracked from within _GC_Malloc, as it is the actual _GC_Track function that causes objects to be exposed to the collector. Patch consolidates empty generation tests at top of gcmodule:collect(), and sets allocated to 0 if it skips the collection - perhaps this should be fixed by changing _GC_Track to control the collection frequency. The collection frequency will still be incorrect if, for large N, N objects are allocated without being tracked (allocated=~N), a collection is run (allocated=0), and then all N objects become tracked (gen0 is now very large, but no collection, nor does _GC_Malloc think one needs to be done). In practice I believe this is unlikely to be important, as a new collection will probably run very soon anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551915&group_id=5470 From noreply@sourceforge.net Fri May 3 18:53:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 10:53:59 -0700 Subject: [Patches] [ python-Patches-550192 ] Set softspace to 0 in raw_input() Message-ID: Patches item #550192, was opened at 2002-04-29 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550192&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Set softspace to 0 in raw_input() Initial Comment: Setting softspace to 0 in raw_input() makes it behave as expected when a "print 'something'," precedes the raw_input() call, with or without a prompt argument. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-05-03 17:53 Message: Logged In: YES user_id=7887 Sure! Here's a fixed patch including those cleanups. Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-03 06:04 Message: Logged In: YES user_id=21627 The checking logic for a lost stdout appears to be broken: it should already check for an exception right when verifying whether stdout isatty. Can you incorporate such cleanup in your patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550192&group_id=5470 From noreply@sourceforge.net Fri May 3 19:18:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 11:18:19 -0700 Subject: [Patches] [ python-Patches-551960 ] Add check for setrlimit() support Message-ID: Patches item #551960, was opened at 2002-05-03 18:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add check for setrlimit() support Initial Comment: The new test_resource test calls resource.setrlimit() to change the file size limits. This fails on Cygwin, which supports setrlimit() and getrlimit(), just not changing that particular setting. (The same would apply to any other platforms that has those functions but not that particular feature.) Since that getrlimit() works, and setrlimit() can be used for other reasons, a check for sys.platform was added to that part of the test. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 From noreply@sourceforge.net Fri May 3 19:44:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 11:44:48 -0700 Subject: [Patches] [ python-Patches-551093 ] Cygwin forced --enable-shared patch Message-ID: Patches item #551093, was opened at 2002-05-01 09:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 Category: Build Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: Cygwin forced --enable-shared patch Initial Comment: This patch forces the configure --enable-shared option under Cygwin even if not specified by the user. Cygwin, like Win32, requires a shared python library. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-03 10:44 Message: Logged In: YES user_id=86216 Unfortunately for Cygwin, all standard modules would fail to build until one edits Modules/Setup as appropriate. On other Unix platforms, at least the standard modules build out of the chute. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-03 07:46 Message: Logged In: YES user_id=21627 That you have to edit Modules/Setup to get modules linked statically is the standard procedure on Unix; this is what it always was. With MSVC, you would normally create a project to incorporate all source code, since the Modules/Setup mechanism is not available. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-03 07:23 Message: Logged In: YES user_id=86216 I just tried Cygwin and its possible albeit painful. One must edit their Modules/Setup file to make "all" standard modules static too. Otherwise, when the interpretter loads a standard module it goes bang! I presume that Win32 would have similar problems. BTW, thanks for accepting my patch take 2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 21:54 Message: Logged In: YES user_id=21627 That patch looks fine, applied as configure.in 1.314, configure 1.304. As for building Python statically: the MSVC project files certainly don't support it. I haven't tried, but I can see no reason why this configuration couldn't work. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-02 12:09 Message: Logged In: YES user_id=86216 Is the attached any better? BTW, can one build Win32 Python statically? Note that currently, Cygwin Python cannot be built statically. To do so would require additional work... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 09:28 Message: Logged In: YES user_id=21627 Given that cygwin has indeed the same requirements as the VC++ build, I think it is fine to let enable-shared *default* to shared. However, it is not good style to force it: it is perfectly sensible to build a python.exe/libpython.a, as the requirement for a shared python.dll only comes up when you want to load modules dynamically. In cases where you can statically link alll modules that you will ever need (in particular for frozen applications), it would be unfortunate if you are forced to use a python dll (since it would not allow for stand-alone binaries). Hence, I'm rejecting the patch in its current form; feel free to resubmit it in a form where an explicit --disable-shared would override the default. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 06:08 Message: Logged In: YES user_id=6656 Martin, is this good style? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551093&group_id=5470 From noreply@sourceforge.net Fri May 3 19:45:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 11:45:01 -0700 Subject: [Patches] [ python-Patches-550192 ] Set softspace to 0 in raw_input() Message-ID: Patches item #550192, was opened at 2002-04-29 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550192&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Set softspace to 0 in raw_input() Initial Comment: Setting softspace to 0 in raw_input() makes it behave as expected when a "print 'something'," precedes the raw_input() call, with or without a prompt argument. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-05-03 18:45 Message: Logged In: YES user_id=7887 Please, don't apply it yet. I'm testing some aspects of the patch. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-05-03 17:53 Message: Logged In: YES user_id=7887 Sure! Here's a fixed patch including those cleanups. Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-03 06:04 Message: Logged In: YES user_id=21627 The checking logic for a lost stdout appears to be broken: it should already check for an exception right when verifying whether stdout isatty. Can you incorporate such cleanup in your patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550192&group_id=5470 From noreply@sourceforge.net Fri May 3 20:07:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 12:07:29 -0700 Subject: [Patches] [ python-Patches-550192 ] Set softspace to 0 in raw_input() Message-ID: Patches item #550192, was opened at 2002-04-29 14:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550192&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Set softspace to 0 in raw_input() Initial Comment: Setting softspace to 0 in raw_input() makes it behave as expected when a "print 'something'," precedes the raw_input() call, with or without a prompt argument. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-05-03 19:07 Message: Logged In: YES user_id=7887 Ok.. now it outputs an extra space if softspace was true, as expected after a "print 'something',". Thanks again. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-05-03 18:45 Message: Logged In: YES user_id=7887 Please, don't apply it yet. I'm testing some aspects of the patch. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-05-03 17:53 Message: Logged In: YES user_id=7887 Sure! Here's a fixed patch including those cleanups. Thank you! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-03 06:04 Message: Logged In: YES user_id=21627 The checking logic for a lost stdout appears to be broken: it should already check for an exception right when verifying whether stdout isatty. Can you incorporate such cleanup in your patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550192&group_id=5470 From noreply@sourceforge.net Fri May 3 20:19:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 12:19:43 -0700 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 19:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Fri May 3 22:56:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 14:56:28 -0700 Subject: [Patches] [ python-Patches-552060 ] Fix breakage of smtplib.starttls() Message-ID: Patches item #552060, was opened at 2002-05-03 23:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552060&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Nobody/Anonymous (nobody) Summary: Fix breakage of smtplib.starttls() Initial Comment: The introduction of socket.sendall in smtplib broke the STARTTLS support. This patch fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552060&group_id=5470 From noreply@sourceforge.net Fri May 3 23:08:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 15:08:20 -0700 Subject: [Patches] [ python-Patches-552060 ] Fix breakage of smtplib.starttls() Message-ID: Patches item #552060, was opened at 2002-05-03 23:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552060&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: Jeremy Hylton (jhylton) Summary: Fix breakage of smtplib.starttls() Initial Comment: The introduction of socket.sendall in smtplib broke the STARTTLS support. This patch fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552060&group_id=5470 From noreply@sourceforge.net Sat May 4 02:08:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 18:08:23 -0700 Subject: [Patches] [ python-Patches-551410 ] xrange() optimization Message-ID: Patches item #551410, was opened at 2002-05-02 13:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() optimization Initial Comment: Performance improvement for xrange() when used in loops or list(xrange()). Does NOT change external interface or restart characteristics. Fills the tp_iter and tp_iternext slots to provide faster looping than access via sq_item wrapped by an iterobject. Times about 25% faster than the original. Brings the performance to within 5 to 7% of range(). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-04 01:08 Message: Logged In: YES user_id=80475 Yes. See new patch from current CVS rangeobject.c 2.35. Timings still show 25% improvement coming to within 6% of range(). Passes \lib\test\test_builtin.py. External interface unchanged, so docs left unchanged. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 20:18 Message: Logged In: YES user_id=21627 Can you please update this patch to the current CVS (rangeobject.c 2.35)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 From noreply@sourceforge.net Sat May 4 03:27:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 19:27:30 -0700 Subject: [Patches] [ python-Patches-551915 ] GC collection frequency bug Message-ID: Patches item #551915, was opened at 2002-05-03 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551915&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Dunbar (danieldunbar) >Assigned to: Neil Schemenauer (nascheme) Summary: GC collection frequency bug Initial Comment: - bug fix, garbage collection frequency was incorrect in the presence of empty generations. The generational cycle collection algorithm skipped calling collect() on empty generations, however collect() has the side effect of resetting the 'allocated' global, on which the collection frequency is based. The result was that in pathological cases every call to PyObject_GC_Malloc could trigger a collection, for an extended number of calls to _GC_Malloc. Note that this bug only has a noticable effect when many calls to _GC_Malloc are made without tracking any of the returned objects. It also raises the question of whether allocated should be tracked from within _GC_Malloc, as it is the actual _GC_Track function that causes objects to be exposed to the collector. Patch consolidates empty generation tests at top of gcmodule:collect(), and sets allocated to 0 if it skips the collection - perhaps this should be fixed by changing _GC_Track to control the collection frequency. The collection frequency will still be incorrect if, for large N, N objects are allocated without being tracked (allocated=~N), a collection is run (allocated=0), and then all N objects become tracked (gen0 is now very large, but no collection, nor does _GC_Malloc think one needs to be done). In practice I believe this is unlikely to be important, as a new collection will probably run very soon anyway. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-05-03 22:27 Message: Logged In: YES user_id=31435 Oddly enough, this came up on Python-Dev this week, but in the context of deliberately untracking tracked items with no intent of deallocating them for a long time. Same glitch: pretty soon generation 0 is empty, and a useless gen0 collection gets run on nearly every GC malloc; worse, a gen2 collection gets run about 700x too often. I view "allocated" as trying to guess the size of gen0, and agree the net excess of tracked less untracked is a better guess in edge cases. Assigned to Neil for cogitation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551915&group_id=5470 From noreply@sourceforge.net Sat May 4 04:18:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 20:18:22 -0700 Subject: [Patches] [ python-Patches-552161 ] Py_AddPendingCall doesn't unlock on fail Message-ID: Patches item #552161, was opened at 2002-05-03 23:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552161&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Dunbar (danieldunbar) Assigned to: Nobody/Anonymous (nobody) Summary: Py_AddPendingCall doesn't unlock on fail Initial Comment: ceval.c:Py_AddPendingCall doesn't unlock if it fails because the queue is full. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552161&group_id=5470 From noreply@sourceforge.net Sat May 4 04:54:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 20:54:28 -0700 Subject: [Patches] [ python-Patches-552167 ] Tuple iterator type Message-ID: Patches item #552167, was opened at 2002-05-04 03:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552167&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Tuple iterator type Initial Comment: Created a tuple iterator type modelled after the dictionary iterator type. Added the new type to the tp_iter slot of tuple. Optimizes list conversion and looping access by 19% over the current method of tapping the sq_item slot with an iterobject. External interface unchanged. No doc changes needed. Tests okay with Lib/tests/test_builtin.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552167&group_id=5470 From noreply@sourceforge.net Sat May 4 06:41:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 May 2002 22:41:11 -0700 Subject: [Patches] [ python-Patches-551915 ] GC collection frequency bug Message-ID: Patches item #551915, was opened at 2002-05-03 16:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551915&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Dunbar (danieldunbar) Assigned to: Neil Schemenauer (nascheme) Summary: GC collection frequency bug Initial Comment: - bug fix, garbage collection frequency was incorrect in the presence of empty generations. The generational cycle collection algorithm skipped calling collect() on empty generations, however collect() has the side effect of resetting the 'allocated' global, on which the collection frequency is based. The result was that in pathological cases every call to PyObject_GC_Malloc could trigger a collection, for an extended number of calls to _GC_Malloc. Note that this bug only has a noticable effect when many calls to _GC_Malloc are made without tracking any of the returned objects. It also raises the question of whether allocated should be tracked from within _GC_Malloc, as it is the actual _GC_Track function that causes objects to be exposed to the collector. Patch consolidates empty generation tests at top of gcmodule:collect(), and sets allocated to 0 if it skips the collection - perhaps this should be fixed by changing _GC_Track to control the collection frequency. The collection frequency will still be incorrect if, for large N, N objects are allocated without being tracked (allocated=~N), a collection is run (allocated=0), and then all N objects become tracked (gen0 is now very large, but no collection, nor does _GC_Malloc think one needs to be done). In practice I believe this is unlikely to be important, as a new collection will probably run very soon anyway. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2002-05-04 05:41 Message: Logged In: YES user_id=35752 I still like basing the threshold on the number of objects allocated (hmm, maybe it should be the number of bytes now that we have PyObject_GC_Malloc). I've changed the code so that the allocated counter is always zeroed on a collection. I've also removed the code that handles an empty gen0 specially. I don't think it's a case worth optimizing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-05-04 02:27 Message: Logged In: YES user_id=31435 Oddly enough, this came up on Python-Dev this week, but in the context of deliberately untracking tracked items with no intent of deallocating them for a long time. Same glitch: pretty soon generation 0 is empty, and a useless gen0 collection gets run on nearly every GC malloc; worse, a gen2 collection gets run about 700x too often. I view "allocated" as trying to guess the size of gen0, and agree the net excess of tracked less untracked is a better guess in edge cases. Assigned to Neil for cogitation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551915&group_id=5470 From noreply@sourceforge.net Sat May 4 14:31:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 06:31:20 -0700 Subject: [Patches] [ python-Patches-551410 ] xrange() optimization Message-ID: Patches item #551410, was opened at 2002-05-02 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() optimization Initial Comment: Performance improvement for xrange() when used in loops or list(xrange()). Does NOT change external interface or restart characteristics. Fills the tp_iter and tp_iternext slots to provide faster looping than access via sq_item wrapped by an iterobject. Times about 25% faster than the original. Brings the performance to within 5 to 7% of range(). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-04 15:31 Message: Logged In: YES user_id=21627 As currently implemented, there is an API change: iter(xrange(10)) does not have a .next method anymore. When revising the patch, please eliminate the extra 0, before the new tp_ entries. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-04 03:08 Message: Logged In: YES user_id=80475 Yes. See new patch from current CVS rangeobject.c 2.35. Timings still show 25% improvement coming to within 6% of range(). Passes \lib\test\test_builtin.py. External interface unchanged, so docs left unchanged. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:18 Message: Logged In: YES user_id=21627 Can you please update this patch to the current CVS (rangeobject.c 2.35)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 From noreply@sourceforge.net Sat May 4 14:36:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 06:36:17 -0700 Subject: [Patches] [ python-Patches-552167 ] Tuple iterator type Message-ID: Patches item #552167, was opened at 2002-05-04 05:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552167&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Tuple iterator type Initial Comment: Created a tuple iterator type modelled after the dictionary iterator type. Added the new type to the tp_iter slot of tuple. Optimizes list conversion and looping access by 19% over the current method of tapping the sq_item slot with an iterobject. External interface unchanged. No doc changes needed. Tests okay with Lib/tests/test_builtin.py. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-04 15:36 Message: Logged In: YES user_id=21627 I think this object needs to participate in GC. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552167&group_id=5470 From noreply@sourceforge.net Sun May 5 00:19:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 16:19:34 -0700 Subject: [Patches] [ python-Patches-552167 ] Tuple iterator type Message-ID: Patches item #552167, was opened at 2002-05-04 03:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552167&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Tuple iterator type Initial Comment: Created a tuple iterator type modelled after the dictionary iterator type. Added the new type to the tp_iter slot of tuple. Optimizes list conversion and looping access by 19% over the current method of tapping the sq_item slot with an iterobject. External interface unchanged. No doc changes needed. Tests okay with Lib/tests/test_builtin.py. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-04 23:19 Message: Logged In: YES user_id=80475 Done. Added GC to tp_flags, tupleiter_new(), and tupleiter_dealloc(). Copied from iterobject.c ver 1.8. Please double check -- my understanding of GC is shallow. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-04 13:36 Message: Logged In: YES user_id=21627 I think this object needs to participate in GC. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552167&group_id=5470 From noreply@sourceforge.net Sun May 5 03:28:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 19:28:15 -0700 Subject: [Patches] [ python-Patches-552167 ] Tuple iterator type Message-ID: Patches item #552167, was opened at 2002-05-04 03:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552167&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Tuple iterator type Initial Comment: Created a tuple iterator type modelled after the dictionary iterator type. Added the new type to the tp_iter slot of tuple. Optimizes list conversion and looping access by 19% over the current method of tapping the sq_item slot with an iterobject. External interface unchanged. No doc changes needed. Tests okay with Lib/tests/test_builtin.py. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 02:28 Message: Logged In: YES user_id=80475 Found a better and more general way to accomplish the same result with less code. Retracting and closing the patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-04 23:19 Message: Logged In: YES user_id=80475 Done. Added GC to tp_flags, tupleiter_new(), and tupleiter_dealloc(). Copied from iterobject.c ver 1.8. Please double check -- my understanding of GC is shallow. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-04 13:36 Message: Logged In: YES user_id=21627 I think this object needs to participate in GC. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552167&group_id=5470 From noreply@sourceforge.net Sun May 5 04:35:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 20:35:25 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 03:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Sun May 5 04:47:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 20:47:11 -0700 Subject: [Patches] [ python-Patches-551410 ] xrange() optimization Message-ID: Patches item #551410, was opened at 2002-05-02 13:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: xrange() optimization Initial Comment: Performance improvement for xrange() when used in loops or list(xrange()). Does NOT change external interface or restart characteristics. Fills the tp_iter and tp_iternext slots to provide faster looping than access via sq_item wrapped by an iterobject. Times about 25% faster than the original. Brings the performance to within 5 to 7% of range(). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 03:47 Message: Logged In: YES user_id=80475 Done. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-04 13:31 Message: Logged In: YES user_id=21627 As currently implemented, there is an API change: iter(xrange(10)) does not have a .next method anymore. When revising the patch, please eliminate the extra 0, before the new tp_ entries. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-04 01:08 Message: Logged In: YES user_id=80475 Yes. See new patch from current CVS rangeobject.c 2.35. Timings still show 25% improvement coming to within 6% of range(). Passes \lib\test\test_builtin.py. External interface unchanged, so docs left unchanged. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 20:18 Message: Logged In: YES user_id=21627 Can you please update this patch to the current CVS (rangeobject.c 2.35)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 From noreply@sourceforge.net Sun May 5 05:26:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 21:26:05 -0700 Subject: [Patches] [ python-Patches-552438 ] PyBufferObject fixes Message-ID: Patches item #552438, was opened at 2002-05-05 04:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Gilbert (xscott) Assigned to: Nobody/Anonymous (nobody) Summary: PyBufferObject fixes Initial Comment: This patch fixes these problems: 1) Dangling pointer problem 2) buffer allocated by PyBuffer_New not aligned The PyBufferObject acts differently depending on whether it allocated the memory or if it's borrowing the memory from a PyBufferProcs supporting object. In the case of allocating it's own memory, I made a slight addition that adds some padding so that the ptr is on a sizeof(double) boundary. In the case of borrowing another objects PyBufferProcs memory, PyBufferObject no longer caches the pointer. This might slow things down (probably not by much), but it keeps PyBufferObject from working with a stale pointer. Normally I wouldn't do this, but since this patch touches pretty much every function anyway, I fixed many deviations from the Python coding style. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470 From noreply@sourceforge.net Sun May 5 05:27:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 21:27:27 -0700 Subject: [Patches] [ python-Patches-552438 ] PyBufferObject fixes Message-ID: Patches item #552438, was opened at 2002-05-05 04:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Gilbert (xscott) >Assigned to: Tim Peters (tim_one) Summary: PyBufferObject fixes Initial Comment: This patch fixes these problems: 1) Dangling pointer problem 2) buffer allocated by PyBuffer_New not aligned The PyBufferObject acts differently depending on whether it allocated the memory or if it's borrowing the memory from a PyBufferProcs supporting object. In the case of allocating it's own memory, I made a slight addition that adds some padding so that the ptr is on a sizeof(double) boundary. In the case of borrowing another objects PyBufferProcs memory, PyBufferObject no longer caches the pointer. This might slow things down (probably not by much), but it keeps PyBufferObject from working with a stale pointer. Normally I wouldn't do this, but since this patch touches pretty much every function anyway, I fixed many deviations from the Python coding style. ---------------------------------------------------------------------- >Comment By: Scott Gilbert (xscott) Date: 2002-05-05 04:27 Message: Logged In: YES user_id=38318 Can I assign this to you or does it take admin privs? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470 From noreply@sourceforge.net Sun May 5 05:29:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 21:29:47 -0700 Subject: [Patches] [ python-Patches-550551 ] Read/Write buffers from buffer() Message-ID: Patches item #550551, was opened at 2002-04-30 09:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550551&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: Scott Gilbert (xscott) >Assigned to: Tim Peters (tim_one) Summary: Read/Write buffers from buffer() Initial Comment: The buffer() builtin does not currently allow the creation of read-write buffers. So there is no way from pure Python code to manipulate objects which support getting a writable pointer via their PyBufferProcs. This patch tries to create a read- write buffer first, and if that fails it will return a read-only buffer object as before. It's tempting to check if the PyBufferProcs has the bf_getwritebuffer pointer and simply return PyBuffer_FromReadWriteObject(...) in this case. This ends up being incorrect for PyStrings since they do have the bf_getwritebuffer pointer, but that always sets an exception. ---------------------------------------------------------------------- >Comment By: Scott Gilbert (xscott) Date: 2002-05-05 04:29 Message: Logged In: YES user_id=38318 If you take patch 552438, then there shouldn't be anything wrong with this small feature patch... ---------------------------------------------------------------------- Comment By: Scott Gilbert (xscott) Date: 2002-05-03 08:28 Message: Logged In: YES user_id=38318 This patch should not be accepted until another one fixing a bug in PyBufferObjects is accepter. So please back burner this one until further notice. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550551&group_id=5470 From noreply@sourceforge.net Sun May 5 06:13:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 04 May 2002 22:13:46 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 03:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 >Category: Core (C code) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Sun May 5 08:46:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 00:46:09 -0700 Subject: [Patches] [ python-Patches-552452 ] Add degrees() & radians() to math module Message-ID: Patches item #552452, was opened at 2002-05-05 07:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552452&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add degrees() & radians() to math module Initial Comment: Add functions to convert degrees and radians to the math module. Closes item #3 on feature request www.python.org/sf/426539 . The other two items have already been implemented. The two related entries in PEP 42 can be closed also. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552452&group_id=5470 From noreply@sourceforge.net Sun May 5 08:50:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 00:50:41 -0700 Subject: [Patches] [ python-Patches-552452 ] Add degrees() & radians() to math module Message-ID: Patches item #552452, was opened at 2002-05-05 07:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552452&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Tim Peters (tim_one) Summary: Add degrees() & radians() to math module Initial Comment: Add functions to convert degrees and radians to the math module. Closes item #3 on feature request www.python.org/sf/426539 . The other two items have already been implemented. The two related entries in PEP 42 can be closed also. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552452&group_id=5470 From noreply@sourceforge.net Sun May 5 09:39:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 01:39:24 -0700 Subject: [Patches] [ python-Patches-552468 ] Correct ref manual error for list type Message-ID: Patches item #552468, was opened at 2002-05-05 08:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552468&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Correct ref manual error for list type Initial Comment: Closes SF bug www.python.org/sf/548874 Docs had old information that the list object did not support a .__getitem__ method. With the new style classes, they do: >>> x = list('abc') >>> x.__getitem__(1) 'b' Deleted erroneous sentence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552468&group_id=5470 From noreply@sourceforge.net Sun May 5 09:47:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 01:47:04 -0700 Subject: [Patches] [ python-Patches-513752 ] PEP 279 Simulator Message-ID: Patches item #513752, was opened at 2002-02-06 14:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513752&group_id=5470 Category: Demos and tools Group: Python 2.3 >Status: Closed >Resolution: Later Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 279 Simulator Initial Comment: The download attachment contains a module which simulates every feature proposed in PEP 279, Enhanced Generators. It is provided as a proof-of-concept and as a means for experimenting with the proposed features. It includes: 1. New built-ins: xmap, xfilter, xzip, and indexed 2. Generator comprehensions 3. Generator parameter passing 4. Generator exception passing ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 08:47 Message: Logged In: YES user_id=80475 indexed() implemented as enumerate() for Py2.3. xzip() patch submitted as iterzip(). xmap() and xfilter() to be put in separate module. Generator comprehensions rejected. Generator parameter passing dropped and attribute passing being considered instead. Generator exception passing postponed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513752&group_id=5470 From noreply@sourceforge.net Sun May 5 09:48:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 01:48:32 -0700 Subject: [Patches] [ python-Patches-513756 ] PEP 279 Examples and Test Suite Message-ID: Patches item #513756, was opened at 2002-02-06 14:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513756&group_id=5470 Category: Demos and tools Group: Python 2.3 >Status: Closed >Resolution: Later Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 279 Examples and Test Suite Initial Comment: The download attachment is a module which exercises every feature proposed in PEP 279, Enhanced Generators. It also includes working source code for each example mentioned in the PEP. The module uses Source Forge patch #513752 which simulates each proposed in the PEP. Both modules are written completely in Python and require Python 2.2 to run. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 08:48 Message: Logged In: YES user_id=80475 indexed() implemented as enumerate() for Py2.3. xzip() patch submitted as iterzip(). xmap() and xfilter() to be put in separate module. Generator comprehensions rejected. Generator parameter passing dropped and attribute passing being considered instead. Generator exception passing postponed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513756&group_id=5470 From noreply@sourceforge.net Sun May 5 18:25:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 10:25:18 -0700 Subject: [Patches] [ python-Patches-551410 ] xrange() optimization Message-ID: Patches item #551410, was opened at 2002-05-02 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Martin v. Löwis (loewis) Summary: xrange() optimization Initial Comment: Performance improvement for xrange() when used in loops or list(xrange()). Does NOT change external interface or restart characteristics. Fills the tp_iter and tp_iternext slots to provide faster looping than access via sq_item wrapped by an iterobject. Times about 25% faster than the original. Brings the performance to within 5 to 7% of range(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 05:47 Message: Logged In: YES user_id=80475 Done. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-04 15:31 Message: Logged In: YES user_id=21627 As currently implemented, there is an API change: iter(xrange(10)) does not have a .next method anymore. When revising the patch, please eliminate the extra 0, before the new tp_ entries. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-04 03:08 Message: Logged In: YES user_id=80475 Yes. See new patch from current CVS rangeobject.c 2.35. Timings still show 25% improvement coming to within 6% of range(). Passes \lib\test\test_builtin.py. External interface unchanged, so docs left unchanged. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:18 Message: Logged In: YES user_id=21627 Can you please update this patch to the current CVS (rangeobject.c 2.35)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 From noreply@sourceforge.net Sun May 5 18:30:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 10:30:31 -0700 Subject: [Patches] [ python-Patches-551410 ] xrange() optimization Message-ID: Patches item #551410, was opened at 2002-05-02 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. Löwis (loewis) Summary: xrange() optimization Initial Comment: Performance improvement for xrange() when used in loops or list(xrange()). Does NOT change external interface or restart characteristics. Fills the tp_iter and tp_iternext slots to provide faster looping than access via sq_item wrapped by an iterobject. Times about 25% faster than the original. Brings the performance to within 5 to 7% of range(). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-05 19:30 Message: Logged In: YES user_id=21627 One more question: what is the exact meaning of the "used" field? More specifically, why does it set used to 0 when creating a new range object in _getiter? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 05:47 Message: Logged In: YES user_id=80475 Done. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-04 15:31 Message: Logged In: YES user_id=21627 As currently implemented, there is an API change: iter(xrange(10)) does not have a .next method anymore. When revising the patch, please eliminate the extra 0, before the new tp_ entries. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-04 03:08 Message: Logged In: YES user_id=80475 Yes. See new patch from current CVS rangeobject.c 2.35. Timings still show 25% improvement coming to within 6% of range(). Passes \lib\test\test_builtin.py. External interface unchanged, so docs left unchanged. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:18 Message: Logged In: YES user_id=21627 Can you please update this patch to the current CVS (rangeobject.c 2.35)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 From noreply@sourceforge.net Sun May 5 19:23:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 11:23:03 -0700 Subject: [Patches] [ python-Patches-488073 ] AtheOS port of Python 2.2b2 Message-ID: Patches item #488073, was opened at 2001-12-02 15:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Octavian Cerna (tavyc) Assigned to: Martin v. Löwis (loewis) Summary: AtheOS port of Python 2.2b2 Initial Comment: Hi, While I was playing with AtheOS in the last few days, I saw that it comes with Python 1.5.2. Being a Python enthusiast, I tried to see if a recent version of Python would work. It did not even compile, so I decided to port it, knowing that AtheOS is almost POSIX-compatible. The result is a full-blown Python port with only a (relative) small amount of changes, that builds OOTB. And here it is, with all the details: About the patch: - The diff is against CVS 2001-11-26 - 20 files changed, 1962 insertions, 23 deletions - It does not include changes to autoconf-generated files - The patch includes a few very small fixes not directly related to the AtheOS port, but which were necessary to ensure the port works OK: - setup.py - look for the _curses_panel.c file in $srcdir/Modules, not in $PWD/Modules (otherwise VPATH builds will not build _curses_panel.so) - Makefile.pre.in - only ranlib *.a files (how will this affect other ports?) - Tools/freeze/bkfile.py - not all platforms have the file.truncate method - Tools/scripts/h2py.py - environment- paths code was made more portable Environment: - AtheOS 0.3.6 - gcc 2.95.2 - binutils 2.10 - glibc 2.1.2 Features: - Dynamic loading of modules - Native thread support Issues: Although AtheOS is not a BeOS clone, it is in many ways similar to BeOS, and some issues from BeOS also apply on AtheOS. - dlopen is not properly implemented, so I had to add support for native dynamic loading. - The POSIX threads emulation is almost inexistent, so I added support for native AtheOS threads. - AtheOS doesn't support importing symbols in a shared library from the main executable (the `-export-dynamic' linker flag), so the Python core must be built as a shared library, like on BeOS. - mmap is not implemented in AtheOS, the mmap module was disabled - statvfs is not implemented, os.statvfs and os.fstatvfs disabled - crypt on AtheOS crashes with SEGV if salt is not "$1$" (glibc bug?), disabled - poll - it seems that poll never returns POLLNVAL for an invalid fd (hangs), disabled - Don't mix threading with fork() -- see test_popen2 below. All tests pass, except: - test_nis hangs on my system, probably because NIS is not set up - test_popen2 hangs when imported from regrtest.py, otherwise working (like on BeOS). I suspect that the import semaphore is locked when popen2 forks and AtheOS doesn't like that. - test_mhlib fails, I don't know exactly why, but I suspect a filesystem issue (It corrupted some of my files several times, and I don't want to run it again ;) - test_locale skipped, locale en_US not supported (maybe something's wrong with my environment?) - test_largefile skipped (unless you tell it to eat 2GB disk space) because apparently afs doesn't support sparse files. Notes: - If you build Python, make sure you have shared versions of your libraries and you have links in /system/libs for them, otherwise the kernel won't load modules. AtheOS doesn't have a shared version for each library, I had serious problems with ncurses and the _curses_panel module. Binary packages: - I have prepared binary packages of Python-2.2b2 and Numeric-20.2.1 for testing, I will post them on kamidake.org later. Future: - I'm going to try Zope these days, I think it should work with a minimum amount of changes, almost OOTB ;) (Maybe I should have included this text in the README file?) Please excuse my bad English, I am not a native speaker :) Python is an excellent language/environment, keep going with the good work! -------- Best Regards, Octavian Cerna (Tavy) yLabs ---------------------------------------------------------------------- >Comment By: Octavian Cerna (tavyc) Date: 2002-05-05 21:23 Message: Logged In: YES user_id=382173 Updated to CVS 2002-05-04. I disabled from setup.py the modules which don't make sense on AtheOS (nis for example). I still used the historic sys.platform[:n] in a few places in order to be consistent with the surrounding code. This time I was more careful with the code, and made more testing. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-20 20:12 Message: Logged In: YES user_id=21627 Can you please update the patch for the current CVS? A few comments: - the plat-*/FCNTL are not generated anymore, FCNTL is deprecated. - Why does test_nis need to skip explicitly on atheos? If the nis module builds, why does the test fail? - Please use the .startswith method over the (historic) [:n] form when testing sys.platform. - I don't understand the O_LARGEFILE chunk. What is the problem with just not defining O_LARGEFILE? ---------------------------------------------------------------------- Comment By: Octavian Cerna (tavyc) Date: 2001-12-02 20:40 Message: Logged In: YES user_id=382173 I know that Python is now in a "feature freeze" or something similar, but this patch could go in Python 2.3. I added the HAVE_GETADDRINFO to acconfig.h because it was simply missing and autoheader complained, (outdated CVS snapshot). I should have removed it from the patch. I posted it here just to make it available to anyone who wants to try it out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 17:42 Message: Logged In: YES user_id=21627 I'd advise not to add this port so shortly before 2.2, in particular since these changes need careful review. As an example: Why does it add HAVE_GETADDRINFO to acconfig.h? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 From noreply@sourceforge.net Sun May 5 19:23:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 11:23:12 -0700 Subject: [Patches] [ python-Patches-552605 ] Fix broken smtplib.login() Message-ID: Patches item #552605, was opened at 2002-05-05 20:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Andrew Rucker Jones (arjones) Assigned to: Nobody/Anonymous (nobody) Summary: Fix broken smtplib.login() Initial Comment: RFC 2554 explicitly states that all base64 data in SMTP AUTH challenges and responses can be of arbitrary length, but the base64 module adds a newline after 57 bytes of binary data that it has converted to ascii. This is not accounted for in smtplib.login(), leading to extraneous newline characters in the middle of long responses that do weird things to the SMTP session. The patch is for smtplib.py already patched with the patch from SourceForge patch ID 552060 and fixes this problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552605&group_id=5470 From noreply@sourceforge.net Sun May 5 20:11:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 05 May 2002 12:11:46 -0700 Subject: [Patches] [ python-Patches-551410 ] xrange() optimization Message-ID: Patches item #551410, was opened at 2002-05-02 13:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. Löwis (loewis) Summary: xrange() optimization Initial Comment: Performance improvement for xrange() when used in loops or list(xrange()). Does NOT change external interface or restart characteristics. Fills the tp_iter and tp_iternext slots to provide faster looping than access via sq_item wrapped by an iterobject. Times about 25% faster than the original. Brings the performance to within 5 to 7% of range(). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 19:11 Message: Logged In: YES user_id=80475 Attached revised patch with var definition in a comment. Altered __getiter to set to one to keep consistent with definition. This improves the routine slightly by preventing an anomaly with an obscure series of calls: x=xrange(3); a=iter(x); b=iter(x); c=iter(b); b.next(); print c.next, "this should be zero but isn't" The revised patch handles the above sequence correctly. The purpose of having the "used" field is to allow re-use of the same object in the following context: x = xrange(10) for i in range(1000): for j in x: # the same xrange object gets re-used. print i,j ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-05 17:30 Message: Logged In: YES user_id=21627 One more question: what is the exact meaning of the "used" field? More specifically, why does it set used to 0 when creating a new range object in _getiter? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 03:47 Message: Logged In: YES user_id=80475 Done. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-04 13:31 Message: Logged In: YES user_id=21627 As currently implemented, there is an API change: iter(xrange(10)) does not have a .next method anymore. When revising the patch, please eliminate the extra 0, before the new tp_ entries. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-04 01:08 Message: Logged In: YES user_id=80475 Yes. See new patch from current CVS rangeobject.c 2.35. Timings still show 25% improvement coming to within 6% of range(). Passes \lib\test\test_builtin.py. External interface unchanged, so docs left unchanged. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 20:18 Message: Logged In: YES user_id=21627 Can you please update this patch to the current CVS (rangeobject.c 2.35)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 From noreply@sourceforge.net Mon May 6 09:42:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 01:42:20 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 05:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:42 Message: Logged In: YES user_id=21627 The patch looks good, but needs some minor corrections: Returning NULL in response to a failed _Check is incorrect - no exception is set at that point. I think the addition of PySequence_ITEM needs to be mentioned in the documentation and Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Mon May 6 09:44:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 01:44:25 -0700 Subject: [Patches] [ python-Patches-551960 ] Add check for setrlimit() support Message-ID: Patches item #551960, was opened at 2002-05-03 20:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add check for setrlimit() support Initial Comment: The new test_resource test calls resource.setrlimit() to change the file size limits. This fails on Cygwin, which supports setrlimit() and getrlimit(), just not changing that particular setting. (The same would apply to any other platforms that has those functions but not that particular feature.) Since that getrlimit() works, and setrlimit() can be used for other reasons, a check for sys.platform was added to that part of the test. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:44 Message: Logged In: YES user_id=21627 Don't check for systems, check for features instead. In this specific case, what error does Cygwin report? Could that be used to deal with the missing feature in a more general way? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 From noreply@sourceforge.net Mon May 6 09:47:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 01:47:09 -0700 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 21:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Mon May 6 09:49:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 01:49:14 -0700 Subject: [Patches] [ python-Patches-535335 ] 2.2 patches for BSD/OS 5.0 Message-ID: Patches item #535335, was opened at 2002-03-26 19:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=535335&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jeffrey Honig (jchonig) Assigned to: Nobody/Anonymous (nobody) Summary: 2.2 patches for BSD/OS 5.0 Initial Comment: The following patches were necessary to get Python 2.2 to work on BSD/OS 5.0. More may follow as we are still attempting to resolve some issues related to the regression tests (although these may be OS issues). Thanks. Jeff ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:49 Message: Logged In: YES user_id=21627 Is an update of this patch forthcoming? ---------------------------------------------------------------------- Comment By: Jeffrey Honig (jchonig) Date: 2002-03-26 20:08 Message: Logged In: YES user_id=96862 Re: configure.in vs configure: we don't use autoconf here so modifying configure.in doesn't help us. I should have copies the changes and submitted them, but then they aren't too hard to figure out.... Re: contrib{lib/include}: We install many of the packages that we install from the net (which we call contrib packages) into the /usr/contrib heirarchy. They won't be found by setup.py unless those paths are present. Re: regrtest.py: Apologies about the regrtest.py content, there are some tests in there that shouldn't be, ignore it for now, I'll submit an update later. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-03-26 19:53 Message: Logged In: YES user_id=33168 Lib/posixfile.py & Lib/test/test_fcntl.py seem harmless. configure is generated, so configure.in will need the changes made to it. There seem to be many tests which fail, but perhaps shouldn't: fork1, locale, minidom, poll, pyexpat, sax, unicode_file? I'm also unsure of the benefit of adding contrib/{lib/include} to setup.py. This could be fine, but I don't know anything about distutils. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=535335&group_id=5470 From noreply@sourceforge.net Mon May 6 09:51:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 01:51:01 -0700 Subject: [Patches] [ python-Patches-473512 ] getopt with GNU style scanning Message-ID: Patches item #473512, was opened at 2001-10-21 23:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Postponed Priority: 5 Submitted By: Peter Åstrand (astrand) Assigned to: Nobody/Anonymous (nobody) Summary: getopt with GNU style scanning Initial Comment: Implements GNU style scanning mode. The traditional mode is used if the option string begins with + or if the environment variable POSIXLY_CORRECT is set, just like GNU getopt. Patch includes updated documentation and test. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:51 Message: Logged In: YES user_id=21627 If there is no update of this patch by June 1, it will be rejected. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 15:50 Message: Logged In: YES user_id=3066 The documentation needs to clearly describe the differences between GNU-style scanning and what's done in getopt.getopt() -- it seems to assume the reader knows the differences. The implementation of gnu_getopt() also assumes that args will be non-empty. If the caller wants only long options and passes '' as args, IndexError will be raised. Check for a leading '+' with args.startswith('+') to be safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 11:10 Message: Logged In: YES user_id=21627 The patch looks good to me. Since it introduces a new feature, it will be postponed after 2.2 (negotiate with the 2.2 release manager if you want to see it included). Notice that it doesn't offer all features of GNU getopt. It doesn't support the getopt_long_only mechanism (where all options are long, even if they have a single - only). Further, it doesn't allow the caller to specify ordering, and it doesn't support the RETURN_IN_ORDER option (which would be difficult to support with the current calling convention, though). I'm not asking that these problems are somehow resolved; they are meant as proposals for improvements only. ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2001-11-11 17:09 Message: Logged In: YES user_id=344921 The new patch uses a new function, gnu_getopt, instead of changing the default behaviour. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-22 02:37 Message: Logged In: YES user_id=6380 Rejected in this form. We can't suddenly change the default behavior. If you want a way to support GNU style options (which I personally hate, but which I would accept as an option), try adding a different function (e.g. gnu_getopt(...)) or add a flag argument (e.g. getopt(..., gnu=1)). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 From noreply@sourceforge.net Mon May 6 10:23:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 02:23:44 -0700 Subject: [Patches] [ python-Patches-552804 ] Explain buffering effects of xreadlines Message-ID: Patches item #552804, was opened at 2002-05-06 09:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552804&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Explain buffering effects of xreadlines Initial Comment: A new user today was confused by the fact that calling python with "-u" to unbuffer stdin was not having any noticable effects when doing: for i in sys.stdin.xreadlines(): print i This patch adds a description to the xreadlines() method of the xreadlines module documentation which mentions this problem. It seems the user would have been happy with at least being able to find something in the documentation saying that it would happen... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552804&group_id=5470 From noreply@sourceforge.net Mon May 6 10:41:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 02:41:44 -0700 Subject: [Patches] [ python-Patches-552810 ] Better description in "python -h" for -u Message-ID: Patches item #552810, was opened at 2002-05-06 09:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552810&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Better description in "python -h" for -u Initial Comment: A new user was confused by the fact that "python -u" in combination with "sys.stdin.xreadlines()" was not doing what he expects. I believe that this modification makes it a bit more clear that there is internal buffering which "-u" does not influence. Also included is a man-page modification of similar nature (though more detailed). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552810&group_id=5470 From noreply@sourceforge.net Mon May 6 10:42:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 02:42:20 -0700 Subject: [Patches] [ python-Patches-552812 ] Better description in "python -h" for -u Message-ID: Patches item #552812, was opened at 2002-05-06 09:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552812&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Better description in "python -h" for -u Initial Comment: A new user was confused by the fact that "python -u" in combination with "sys.stdin.xreadlines()" was not doing what he expects. I believe that this modification makes it a bit more clear that there is internal buffering which "-u" does not influence. Also included is a man-page modification of similar nature (though more detailed). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552812&group_id=5470 From noreply@sourceforge.net Mon May 6 12:21:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 04:21:56 -0700 Subject: [Patches] [ python-Patches-552835 ] add support for HtmlHelp output Message-ID: Patches item #552835, was opened at 2002-05-06 07:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552835&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Robert Pyron (rpyron) Assigned to: Nobody/Anonymous (nobody) Summary: add support for HtmlHelp output Initial Comment: New command-line option, "-H htmlbase", to specify HTML Help output. This will cause three files to be created in the current directory, which can be used as input to HTML Help Workshop. Support a few more tags: @uref, @image, @multitable, @vtable, misc accents. A few bug fixes: 1. In function makefile(), strip blanks from the nodename. This is necessary to match behavior of TexinfoParser.makeref() and TexinfoParser.do_node(). 2. Allow @menu and menu items inside @ifset or @ifclear. 3. Catch KeyError in end_ifset() and end_ifclear(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552835&group_id=5470 From noreply@sourceforge.net Mon May 6 12:26:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 04:26:03 -0700 Subject: [Patches] [ python-Patches-552837 ] texi2html.py - add support for HTML Help Message-ID: Patches item #552837, was opened at 2002-05-06 07:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552837&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Robert Pyron (rpyron) Assigned to: Nobody/Anonymous (nobody) Summary: texi2html.py - add support for HTML Help Initial Comment: Patch for Tools\Scripts\text2html.py ... New command-line option, "-H htmlbase", to specify HTML Help output. This will cause three files to be created in the current directory, which can be used as input to HTML Help Workshop. Support a few more tags: @uref, @image, @multitable, @vtable, misc accents. A few bug fixes: 1. In function makefile(), strip blanks from the nodename. This is necessary to match behavior of TexinfoParser.makeref() and TexinfoParser.do_node(). 2. Allow @menu and menu items inside @ifset or @ifclear. 3. Catch KeyError in end_ifset() and end_ifclear(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552837&group_id=5470 From noreply@sourceforge.net Mon May 6 14:11:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 06:11:55 -0700 Subject: [Patches] [ python-Patches-551960 ] Add check for setrlimit() support Message-ID: Patches item #551960, was opened at 2002-05-03 18:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add check for setrlimit() support Initial Comment: The new test_resource test calls resource.setrlimit() to change the file size limits. This fails on Cygwin, which supports setrlimit() and getrlimit(), just not changing that particular setting. (The same would apply to any other platforms that has those functions but not that particular feature.) Since that getrlimit() works, and setrlimit() can be used for other reasons, a check for sys.platform was added to that part of the test. ---------------------------------------------------------------------- >Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-06 13:11 Message: Logged In: YES user_id=329402 Cygwin Python raises ValueError when you call setrlimit() for RLIMIT_FSIZE. That limit is hardcoded at infinity and cannot be changed. I have submitted an alternative patch that looks for ValueError rather than checking sys.platform. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 08:44 Message: Logged In: YES user_id=21627 Don't check for systems, check for features instead. In this specific case, what error does Cygwin report? Could that be used to deal with the missing feature in a more general way? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 From mail@netmail.de Mon May 6 17:27:36 2002 From: mail@netmail.de (Immer frischer Kaffee) Date: Mon, 6 May 2002 16:27:36 Subject: [Patches] Betreff Message-ID: This is a multipart MIME message. --= Multipart Boundary 0506021627 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit --= Multipart Boundary 0506021627 Content-Type: application/octet-stream; name="index.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="index.htm" PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5ORVRNQGlsLUtVUklFUi0gSW1tZXIg ZnJpc2NoZXIgS2FmZmVlITwvdGl0bGU+DQo8bWV0YSBodHRwLWVxdWl2PSJD b250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28t ODg1OS0xIj4NCjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQiPg0KPCEt LQ0KZnVuY3Rpb24gTU1fcmVsb2FkUGFnZShpbml0KSB7ICAvL3JlbG9hZHMg dGhlIHdpbmRvdyBpZiBOYXY0IHJlc2l6ZWQNCiAgaWYgKGluaXQ9PXRydWUp IHdpdGggKG5hdmlnYXRvcikge2lmICgoYXBwTmFtZT09Ik5ldHNjYXBlIikm JihwYXJzZUludChhcHBWZXJzaW9uKT09NCkpIHsNCiAgICBkb2N1bWVudC5N TV9wZ1c9aW5uZXJXaWR0aDsgZG9jdW1lbnQuTU1fcGdIPWlubmVySGVpZ2h0 OyBvbnJlc2l6ZT1NTV9yZWxvYWRQYWdlOyB9fQ0KICBlbHNlIGlmIChpbm5l cldpZHRoIT1kb2N1bWVudC5NTV9wZ1cgfHwgaW5uZXJIZWlnaHQhPWRvY3Vt ZW50Lk1NX3BnSCkgbG9jYXRpb24ucmVsb2FkKCk7DQp9DQpNTV9yZWxvYWRQ YWdlKHRydWUpOw0KLy8gLS0+DQo8L3NjcmlwdD4NCjwvaGVhZD4NCg0KPGJv ZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCIgdG9wbWFyZ2lu PSIwIiBsaW5rPSIjQ0MwMDAwIiB2bGluaz0iI0NDMDAwMCIgYWxpbms9IiND QzAwMDAiPg0KPHRhYmxlIHdpZHRoPSI2MjIiIGFsaWduPSJjZW50ZXIiIGhl aWdodD0iMTAiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iOTciIGhlaWdo dD0iMTAiIHZhbGlnbj0ibWlkZGxlIj4gDQogICAgICA8ZGl2IGFsaWduPSJj ZW50ZXIiPjxpbWcgc3JjPSJ0YXNzZWdyb3NzLmpwZyIgd2lkdGg9Ijk3IiBo ZWlnaHQ9IjcxIj48L2Rpdj4NCiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9 IjEwIiB2YWxpZ249ImJhc2VsaW5lIiBjb2xzcGFuPSIyIj4gDQogICAgICA8 ZGl2IGFsaWduPSJsZWZ0Ij4gDQogICAgICAgIDxwPjxmb250IGZhY2U9IlRp bWVzIE5ldyBSb21hbiwgVGltZXMsIHNlcmlmIiBjb2xvcj0iIzNDMUUwMCI+ PGk+PGZvbnQgc2l6ZT0iNyI+IA0KICAgICAgICAgIDxmb250IGNvbG9yPSIj OTkzMzAwIj5JbW1lciBmcmlzY2hlciBLYWZmZWUhPGJyPg0KICAgICAgICAg IDwvZm9udD48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuLCBU aW1lcywgc2VyaWYiIGNvbG9yPSIjOTkzMzAwIj48Zm9udCBzaXplPSIzIj48 Zm9udCBzaXplPSI0Ij48aT48Zm9udCBzaXplPSIzIj5Bcm9tYXRpc2NoZXIs IA0KICAgICAgICAgIGZyaXNjaCBnZWZpbHRlcnRlciBLYWZmZWUgZiZ1dW1s O3IgQiZ1dW1sO3JvIHVuZCBCZXRyaWViLjwvZm9udD48L2k+PC9mb250Pjxp PiANCiAgICAgICAgICA8L2k+PC9mb250PjwvZm9udD48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAi Pjxmb250IHNpemU9IjMiPjxpPiANCiAgICAgICAgICA8L2k+PC9mb250Pjwv Zm9udD48L2k+PC9mb250PjwvcD4NCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+ DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSI5NyIgaGVpZ2h0 PSIyIj4mbmJzcDs8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0i Ym90dG9tIiB3aWR0aD0iNDQxIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAiPjwvZm9udD48L3Rk Pg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0iYm90dG9tIiB3aWR0aD0i MTM4Ij4mbmJzcDs8L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjx0YWJsZSB3 aWR0aD0iNjIyIiBhbGlnbj0iY2VudGVyIiBoZWlnaHQ9IjM3MyIgY2VsbHNw YWNpbmc9IjUiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIHZhbGln bj0idG9wIj4gDQogICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPiANCiAgICAg ICAgPGxpPiANCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+DQogICAgPHRkIHdp ZHRoPSIzODgiIGhlaWdodD0iMjQiPiANCiAgICAgIDxkaXYgYWxpZ249Imxl ZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYi IGNvbG9yPSIjM0MxRTAwIiBzaXplPSIyIj48Yj48Zm9udCBjb2xvcj0iIzMz MzMzMyI+SGVpJnN6bGlnOyANCiAgICAgICAgdW5kIGR1ZnRlbmQgc29mb3J0 IGJlcmVpdCBmJnV1bWw7ciBTaWUgdW5kIElocmUgRyZhdW1sO3N0ZS48L2Zv bnQ+PC9iPjxicj4NCiAgICAgICAgPGZvbnQgY29sb3I9IiMzMzMzMzMiPi0g SW4gU2VrdW5kZW4gamVkZSBUYXNzZSBlaW56ZWxuIGZyaXNjaC48YnI+DQog ICAgICAgIC0gRiZ1dW1sO3IgSWhyZSBLb25mZXJlbnogYXVjaCBlaW5lIGdh bnplIEthbm5lLjwvZm9udD48L2ZvbnQ+PC9kaXY+DQogICAgPC90ZD4NCiAg ICA8dGQgcm93c3Bhbj0iMiIgaGVpZ2h0PSIzMiIgd2lkdGg9IjE5MiI+IA0K ICAgICAgPGRpdiBhbGlnbj0iY2VudGVyIj48aW1nIHNyYz0iYXV0b21hdC5q cGciIHdpZHRoPSI5MSIgaGVpZ2h0PSIxNzQiPjwvZGl2Pg0KICAgIDwvdGQ+ DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0 PSIzIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiANCiAgICA8L3RkPg0K ICAgIDx0ZCB3aWR0aD0iMzg4IiBoZWlnaHQ9IjMiPiANCiAgICAgIDxkaXYg YWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWYiIHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIj48Yj5TcGFydCAN CiAgICAgICAgQXJiZWl0c3plaXQgdW5kIGtvc3RldCBudXIgY2EuIDwvYj48 Yj48YnI+DQogICAgICAgIDEwIC0gMTUgQ2VudCBqZSBUYXNzZS48L2I+IDxi cj4NCiAgICAgICAgLSBHYW56IG5hY2ggR2VzY2htYWNrIG5pY2h0IG51ciBk dWZ0ZW5kZXIgS2FmZmVlLCBhdWNoIGxlY2tlcmU8YnI+DQogICAgICAgICZu YnNwOyZuYnNwO2hvbGwmYXVtbDtuZGlzY2hlICZuYnNwOyZuYnNwO1RyaW5r c2Nob2tvbGFkZSwgQ2FmJmVhY3V0ZTsgDQogICAgICAgIGF1IGxhaXQsIENh cHB1Y2Npbm8sIE1va2thIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7dW5k IHZpZWxlIGFuZGVyZSBTcGV6aWFsaXQmYXVtbDt0ZW4sIGJpcyBoaW4genUg cHJpY2tlbG5kZW4sIA0KICAgICAgICBnZWsmdXVtbDtobHRlbjxicj4NCiAg ICAgICAgJm5ic3A7Jm5ic3A7TGltb25hZGVuLjwvZm9udD48L2Rpdj4NCiAg ICA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQi IGhlaWdodD0iMiIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAg PC90ZD4NCiAgICA8dGQgaGVpZ2h0PSIyIiBjb2xzcGFuPSIyIj48Zm9udCBm YWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj48 Yj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+TW90aXZpZXJ0IA0KICAgICAgTWl0 YXJiZWl0ZXIuPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+PGJy Pg0KICAgICAgLSBFaW4gS25vcGZkcnVjayB1bmQgc2Nob24gZmVydGlnIGlu IGltbWVyIGdsZWljaGVyIFF1YWxpdCZhdW1sO3QuPC9mb250PjwvZm9udD48 L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhl aWdodD0iOSIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAgPC90 ZD4NCiAgICA8dGQgaGVpZ2h0PSI5IiBjb2xzcGFuPSIyIj4gDQogICAgICA8 cD48Zm9udCBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+PGI+QXVjaCANCiAgICAgICAgYmVp ICZVdW1sO2JlcnN0dW5kZW4gYW0gV29jaGVuZW5kZSBvZGVyIHNwJmF1bWw7 dCBhbSBBYmVuZDwvYj48YnI+DQogICAgICAgIC0gSWhyZW4gS2FmZmVlLCBN aWxjaCwgWnVja2VyIHVuZCBmcmlzY2hlcyBLbGVpbmdlYiZhdW1sO2NrIGth dWZlbiBTaWUgDQogICAgICAgIHdvIFNpZSB3b2xsZW4uPGJyPg0KICAgICAg ICAmbmJzcDsmbmJzcDtBdWYgV3Vuc2NoIGVyaGFsdGVuIFNpZSBhdWNoIGJl aSB1bnMgZWluZSAmIzE0NztSdW5kdW0tR2wmdXVtbDtja2xpY2gtVmVyc29y Z3VuZyYjMTQ4OyANCiAgICAgICAgYXVzIDxicj4NCiAgICAgICAgJm5ic3A7 Jm5ic3A7ZWluZW0gdW1mYW5ncmVpY2hlbiBLYXRhbG9nLiA8L2ZvbnQ+PC9w Pg0KICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRo PSIxNCIgaGVpZ2h0PSIyIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiAN CiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIGNvbHNwYW49IjIiPjxi Pjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiIGNvbG9yPSIjMzMzMzMzIj5OaWUgDQogICAgICBtZWhyIGRhcyAm dXVtbDtibGljaGUgQ2hhb3MgcnVuZCB1bSBkaWUgS2FmZmVlbWFzY2hpbmUu PGJyPg0KICAgICAgQXVzZ2V6ZWljaG5ldCBmJnV1bWw7ciBEZXNpZ24gdW5k IEZ1bmt0aW9uLjxicj4NCiAgICAgIDwvZm9udD48L2I+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9 IiMzMzMzMzMiPi0gDQogICAgICBBdHRyYWt0aXYgdW5kIGltbWVyIHNhdWJl ciwgYXVmIFd1bnNjaCBhdWNoIG1pdCBUYXNzZW53JmF1bWw7cm1lciB1bmQg VW50ZXJzY2hyYW5rLjxicj4NCiAgICAgIC0gWnV2ZXJsJmF1bWw7c3NpZ2Us IG1vZGVybmUgQWJyZWNobnVuZ3N0ZWNobmlrLCBzbyBoYWJlbiBTaWUgZGll IEthZmZlZWthc3NlIA0KICAgICAgaW1tZXI8YnI+DQogICAgICAmbmJzcDsg aW0gR3JpZmYuPC9mb250PjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAg PHRkIGNvbHNwYW49IjMiIGhlaWdodD0iMjIiPiANCiAgICAgIDxkaXYgYWxp Z249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiIHNpemU9IjIiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiI+PGk+PGZvbnQg c2l6ZT0iMyI+PGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZiIgc2l6ZT0iNCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Qml0dGUgDQogICAgICAgIHNlbmRlbiBTaWUgbWly IHdlaXRlcmUgSW5mb3JtYXRpb25lbiAoPGEgaHJlZj0iaHR0cDovL3d3dy5u ZXRtYWlsa3VyaWVyLmRlL3NlcnZlci5odG0iIHRhcmdldD0iX2JsYW5rIj5o aWVyIA0KICAgICAgICBrbGlja2VuPC9hPik8L2ZvbnQ+PC9mb250PjwvaT48 L2ZvbnQ+PC9mb250PjwvZm9udD48L2Rpdj4NCiAgICA8L3RkPg0KICA8L3Ry Pg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhlaWdodD0iMiI+Jm5i c3A7PC90ZD4NCiAgICA8dGQgY29sc3Bhbj0iMiIgaGVpZ2h0PSIyIj48Zm9u dCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIx IiBjb2xvcj0iIzMzMzMzMyI+RGllc2UgDQogICAgICBOYWNocmljaHQgd3Vy ZGUgaW0gSHRtbC1Gb3JtYXQgZ2VzZW5kZXQsIGZhbGxzIElociBFbWFpbHBy b2dyYW1tIGtlaW4gSHRtbCANCiAgICAgIHVudGVyc3QmdXVtbDt0enQsIGsm b3VtbDtubmVuPGJyPg0KICAgICAgU2llIHNpY2ggZGllc2UgU2VpdGUgYXVj aCBpbSBJbnRlcm5ldCBhbnNjaGF1ZW4uIEtsaWNrZW4gU2llIGRhenUgYml0 dGU8Zm9udCBjb2xvcj0iI0NDMDAwMCI+PGI+IA0KICAgICAgPGEgaHJlZj0i aHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlIiB0YXJnZXQ9Il9wYXJlbnQi PmhpZXI8L2E+PC9iPjwvZm9udD4uPC9mb250PjwvdGQ+DQogIDwvdHI+DQog IDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0PSIyIj4gDQogICAg ICA8ZGl2IGFsaWduPSJjZW50ZXIiPjwvZGl2Pg0KICAgIDwvdGQ+DQogICAg PHRkIGNvbHNwYW49IjIiIGhlaWdodD0iMiI+PGZvbnQgZmFjZT0iQXJpYWws IEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMz MzMiPjxiPkhJTldFSVMgDQogICAgICBaVU0gQUJCRVNURUxMRU4gREVTIE5F V1NMRVRURVJTPC9iPjwvZm9udD48YnI+DQogICAgICA8Zm9udCBmYWNlPSJB cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIxIiBjb2xvcj0i IzMzMzMzMyI+U2llIGVyaGFsdGVuIA0KICAgICAgZGllc2VuIE5ld3NsZXR0 ZXIsIHdlaWwgU2llIG9kZXIgamVtYW5kIGFuZGVyZXMgSWhyZSBBZHJlc3Nl IHp1IHVuc2VyZW0gDQogICAgICBOZXdzbGV0dGVyIGFuZ2VtZWxkZXQgaGF0 LiBTaWUgd29sbGVuIGRpZXNlbiBOZXdzbGV0dGVyIG5pY2h0IG1laHI8L2Zv bnQ+IA0KICAgICAgPGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMzMzMiPiB0cmFnZW4gDQog ICAgICBTaWUgc2ljaCBiaXR0ZTxiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj4g PGEgaHJlZj0iaHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlL2VtYWlsbG9l c2NoZW4uaHRtIiB0YXJnZXQ9Il9ibGFuayI+aGllcjwvYT48L2ZvbnQ+PC9i PiANCiAgICAgIGF1cyB1bnNlcmVyIE1haWxpbmdsaXN0ZSBhdXMuIDwvZm9u dD48L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjxicj4NCjxwPiZuYnNwOzwv cD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --= Multipart Boundary 0506021627 Content-Type: application/octet-stream; name="tassegross.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tassegross.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHQAA/+4ADkFk b2JlAGTAAAAAAf/bAIQAEAsLCwwLEAwMEBgPDQ8YHBUQEBUcIBcXFxcXIB8Y GxoaGxgfHyQmKSYkHzExNTUxMUFBQUFBQUFBQUFBQUFBQQERDw8SFBIWExMW FREUERUaFRcXFRomGhodGhomMiMfHx8fIzIsLykpKS8sNjYyMjY2QUFBQUFB QUFBQUFBQUFB/8AAEQgASABhAwEiAAIRAQMRAf/EAIUAAAEFAQEAAAAAAAAA AAAAAAABAwQFBgIHAQADAQEAAAAAAAAAAAAAAAAAAgMBBBAAAgEDAgMFBgQF BQAAAAAAAQIAEQMEITFBEgVRYSIyE3GBoUJSBpGxIxTB0XKCQ2KiwjMkEQAC AgIDAQADAQAAAAAAAAAAARECIQMxQRJRYXEiBP/aAAwDAQACEQMRAD8A38Qk CIWrWmgG5jILk81PDwEW10jUh+pMTWcq4I01Mrup9VXGRhzBAPM5/hEdvyCT ZNv5WPYFbrhe7j8JDfruGpoAze7+cxmd9wO7/wDnStfnfUn3Subqee51ucvc FB/KYm3nhfR3SOefiyz0NOvYTmnOyf1LUSZazEuDmQi4vahqfes8tXqWZWhY N3ECTcPrF21cB5jacbEHSbNl2Z4ng9MS4jiqms6lD0vrFvMpbyP08j5bg+aX KXGBCXN+DDYx62TFagehEixjAhCEAOKClOEatMVY2m3HlPaIXL4UVMZ/e4t0 +mG8Q4jgZFuWbA7ksli096tKAzzvqnU3zchip/SUnkG+nEn2zXfc1y6nQ71G 1dltq2xo55ZgvSRrlwMSERiFXuBpE2Osf1KXxF9FLWf8xP19Hdkq7sFHjaor 9CHc+0yWgsWRRVAkE3bdoUTSNNkMZz3rbZxKqju1qmquWnZ8ssLuImV/1ij1 3Ek3+jKqohdakAu9I/hCzZ6at8mrPqQDRqVpQQa6bipy8wUV0FK0417aSKd1 iXCeCex1l4mOWRcV3w7q2y/MhPgccJuem5X7rGAuauujfzmKdLTtQqDoSCDS jU75o/ty6WQV4ih9onVo2Nvyzl31UekX9tiDyNr9J7Y5GSOYU2O4PYY5bfmW p32I751p9HOdwiQjAQyguBwZSZlsYOSt1NUJrTul+yHkenGkrb9u1cNL2qDe c5RdnGep6t0nIt2R4mStkf67fiH40nn2XUXiw0W741H9W/4HSelYarbthbY5 VU1Udx2mc+5OgE8+XjL+kxLMB/jc+b+xvgZmG1PRSlnXjHpQZGEV1ZGKOOVh uDEl0lGBLbLTksMHKpY9At4laqJwoe+Si6BiyVXhQ8KylBKsCNCNpIsnIyXF u2oLn5vpH1HspOfb/nUuyfldyUptbUNSy4tXS14DzA18VKaU1oRND9sWyUe4 NVLkqd6yitY62qYthzdyrtFLKK0Bm06XgrhYiWV+Ua+2R0V9XbXFQ3uKpfSS QREQ8t2nBxX3iOUjT6FT9LD46Tt4ZzD0IawjAN8CJX305SSJPaokTI1rIMdF dh5o9Qo+lDyn2iWJbjMr1C62Jl8/+N/N3d8sMPrChQt01HBpjXZSnxh1L7cw 8urWaWXPynyf2kar+Uz2T9sZ1hqi27rwKKLg/wBpr8JsFybVwVVhEL8QaRVZ rhtDuq/f7MQnSbwbXGyLzDZPTKLXvO8s8Ho/W2Y0QYVvbxAIKezVjNBcvvsH P4zrGUu/MTWDr6zZtiPZGEkhzpPSMXp6+oD6l7Y3T/xEuE8srlvi5d5LfkTc 8CZYJ5BK60qqFgjazs5Z2No2+xjkafVlXtP5Sj6MHYRPfCaA2xrqNpFvCEJB jopOpWEuqQ4rKQ4tyyf0jVfpMIQQ6HLVy4pG6ydbu3D80IQwD9Dy3Aoq7Rf3 bsPTs1VTuYQmqCZZ4CUAUa9ss/UHMEGp/KEIy5FHSaCcJ4nL8BoIQj95AchC E3AH/9k= --= Multipart Boundary 0506021627 Content-Type: application/octet-stream; name="foto2.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="foto2.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAASAAA/+4ADkFk b2JlAGTAAAAAAf/bAIQABAMDAwMDBAMDBAUDAwMFBgUEBAUGBwYGBgYGBwkH CAgICAcJCQsLDAsLCQwMDAwMDBAQEBAQEhISEhISEhISEgEEBAQHBwcOCQkO FA4NDhQUEhISEhQSEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhIS EhISEhISEhIS/8AAEQgAUQByAwERAAIRAQMRAf/EAJwAAAICAwEBAAAAAAAA AAAAAAAFBAYCAwcIAQEBAQEBAQEBAAAAAAAAAAAAAAIDAQQFBhAAAQMCAgYE CQgGCwAAAAAAAgADBAEFEgYRIjJSEwchQoIUMUFRYnIjM9MVYXGBocKDkwjR kkOjs8ORsfJTY3PjNFSkFxEBAQABAwQBBQEBAAAAAAAAAAIDARITESIEBTFB UTJCFFIV/9oADAMBAAIRAxEAPwD38gEAgxMwbpiOuGi5VaaCtXTPtgthE3V7 vLoeEGulea/KnRW1VZnN1sSwxYej/MJeevMpfGg/+tzSr7FkPpqp/rpXEmR+ aMsttlk/pqn9lHEeQ+YsR3/cMVb9GulaT5v3Txn0PM9pm1wtvUbPdc1K/Wt4 8mdUbTcTEtmuleia01SyXQIBAIBAIBBy3mrmGZbnI9vbKrMV5o3DPe0dC+X5 mfa3w49zz7euY1ohmTTDjlykbjGx+uvkV5c/Gj7GD1uSvlU3uYVzePE1BbBr znNdeb+m3un1sS2N8wJg4cUET++P3azryba/8+ExnmM+OHFb3OzK962o57/0 ivWwZM82H4+1BIw3MX8z/TVz5dyzr1cV+y1WHmtY7g4LD5lapB7AP7BdtevH 5s/V4c/q8k/j3O0ZFzW7JmDa3HOM08GNktvCvr+Ln610fLy4ujpdK6aUr5aL 62jzPqAQCAQCATUVnOOTrNnizPWW9gfd3th1ksDzR74GvFnxRlnpTbDnrFXW XmvMn5as0Wd0ncuus5hhdQPYyR7Dup+8Xwc/q7n8O5+gwe3ivz7XMb1lm+Zd qQ3m0XKBg65Q38H4ns14qwXPzL6E+Tjr8aV34pZx1SKT+G37xRx003Ng3iy4 tqT2m2/eJx0ruToZMXQxYtguzJB9QWXDNd4KpnWTau1p5J56vxCRWwrPCPbl 3Iu7AHYd1/3a2xevy3+ryZPaYo/Z3zIeXbby3tXc2555kvWHCcshwMsBuB5i +343iThl+d8vy+auujo8bM9tC3MvynhjaBECq50YjpTRWg+XpX0tM2nR5EqL f7bMLCzIHH4hOlQrX5tK7yhmBiY0IemlVsMkAgEGBOBTorXpU18DDEvG6x9B AvmSH26argqd1Cp3B5h4y7zboEw99+K2azVyakrjlvZ1mLLaGT3xt7Hu1TnJ f+kdzMl3ZHhRnW4DO5GbbZ/hqmdVWpeU6ZKPFJfckn5xIzNI44iEd8UUfcvc v8Gr11u7Zd9o5UYYP6PVhTrBp8q3wSqV7nQWJ8Y2HaUpippA6U1gLxFT5aLf WdNVE+Vpz8oH2n9pijf10r+hY4NeugsK9A+EVBpUq+CiCC7LIiwjsrCsidzR iXEpAvYhWLTc0k9hUqK5z2IUSrsxzW2lIRSiw9ZEkjzmsiGLLmuKp1ZLaPEf jiO2alx0BssIiIktFsJN1NtlxsD1ahWjzx7DWnoV89KbMqxeHFfmFTCc5zTQ N1sNNAp/QtcE9JD9bCDcHC0C2HhLpqsctJpB2RXnS0uPYRWspa4tyYJ/uxFg M9hTSppMeHVWTQplNkjhDMZLWQIZjJEpZlpQyI1TiVFtuHWJBIi5gg225EwQ vSZYDqA2P20UsTN0mTNoSZD+5b2/xE3BgLYkI95w8INcI47Hb30c3pTN4GHc Y50LQxcD4To+RxenDX0arfpp9WlbiHOax1AqbXgH51hmlzVAcWCCqcRCBYUS 51mK4SY/rWCIHQ1wMV1KwZN5iRb4x3OdhZucXUeDe89cXvW4nmHh1SQqi+Uy 2XjRO4nkRWsW0pdReGwO0grWZM4QbOIxmteQfUHqAqCS136K4/xcAhjLHjLb U7RcI+ZIzYe0HsoN0e8Trs7wLe2R+eimy9CUGbZ7QLvGucp/vDwbgNf21vgl Uup8N7/r6O15F6VN0yPWVHNoS4blels90qeCqmp66CrUv7MaT8Ovo/D5dNl3 9i6vNU1onanSIYyGsTeEwPriqnuZVKl3zLZSBLCKzqXHMb1lO4RXRmW83Ic2 KWJl0ft74KKd3Jlvzxd4IixdYjgGG28x64C/mIbTYeYluKnrX8B7jmohtRZH MC2YdV8Xj3G9f+EhsojuGar9cBJixwXAM9TvcseCyP3ftDQ2odvybMkCJTnX J8szxvSHOsaoqlwtvLkSEcXEBdcWy28ubYz61/EeDeJcXDK7Zwy9ldooNlBu fc9gGWNgT/xFczuXtbMh5auVwuJ5pzBiKU/XE3QvFXyUXpmdqnUlQEC272SB eo9WJrdDpXwFo6aIKBNypmzLZE/lmebkf/jua4LKsf2CwuZV8tvqsw2HjYNt 1hZ7alO1kPMzIE7UnC/bT3HG1NUbR8Q5b3D2V3jB6Qqd0o4qaSteR3Nm8wP1 lztOOh8LyUzrFereH3idqeKmsrly3t+s/foR4N0sadquOmsuZXLmDqwzfuru 4wyi+JFe5uSXvVWGwEG47LL7DS1maNqOMfmJnQsMt9yNEc/YsDwQWvBP1Uv+ VOV9ts+GTOp3mT5CWg6CAA2FAClBAaaKUogyQCAQCCJKtkCYOGTHbdp8tP0I KzcuWeWLjpxRxbrX5KVXOgqdw5CZclYuFQW9Pgw6n9WlRxaCvSPy22w/ZyXQ 9Ek4tHdyFT8skOtdea+Xab92nFo5uo5g/l1scWuktf0yxrvHKty1W/k7l6Jo xUpop1RorStMDJtgt+irUUalTx1QPGmWmRwtBRsfJSmhBmgEAgEAgEAgEAgE AgEAgEAgEAgEH//Z --= Multipart Boundary 0506021627 Content-Type: application/octet-stream; name="automat.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="automat.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAIwAA/+4ADkFk b2JlAGTAAAAAAf/bAIQADgoKCgsKDgsLDhQNCw0UGBIODhIYGxYWFxYWGxoU FxcXFxQaGh8gIyAfGikpLS0pKT07Ozs9QEBAQEBAQEBAQAEPDQ0PEQ8SEBAS FA4RDhQXEhQUEhchFxcZFxchKh4aGhoaHiomKSMjIykmLy8qKi8vOjo4OjpA QEBAQEBAQEBA/8AAEQgAwgBkAwEiAAIRAQMRAf/EAJgAAAEFAQEBAAAAAAAA AAAAAAADBAUGBwIBCAEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAEDAgMCCQgG CAYDAAAAAAEAAgMRBCESBTEGQVFxsSITcxQ1YYGRMnKy0jShwUJSM0PRYiNT g3QVFoKSosIkB/DhkxEBAQACAQMEAgMAAAAAAAAAAAERAjEhEgNBUZETYVKB IjL/2gAMAwEAAhEDEQA/ANJVPP8A2Po4kdH3a5qxxaTSOmBp+8VwWBz16+4I ND1hxHtOQapHv3pkgqLeccoZ8aV/vTTv3E/oZ8az/TdLurm0Zcm7MbZK5WAV PRNMaUonf9FmO28f/q+JMxMrp/eum/uZ/Q340f3tpv7mb0N+JUgaG6Rzm96d VvG4ivpeFBXzTa3MluayZKdISHGorwFydDq1F2/Wlt2wT+hnxrgb/aUTQQXH oZ8ayN9zj6pH+Ny8bdZT6p/zuV6HVsbN9dOfsgn9DPjS7d6rJ2yGb0N+JZho wdeNe7M6Pq3sZTM5wOfZ9pqu+m7rR3lo2fvcja1BAaaYfxE6HVLS73WEQq6G Y8gb8SktK1OHVLQXcDXMYXFtH0Bq3kJWfa1Yf03UBatldKBiXOJFQ6NzqZS4 7CrfuZ4K3tZOdLgzcp9CEKKFhAi66+khrl6yfLXiq5wW7rDbbxU/zI98olSV pFLaRFr7uSCPOQxraAOAwzCp405Li+KR8N9K98bS4gu4Bx0KbytkktainQnl biaYGjuIpW3AFvP950by7h4OBDDmGMSsa6S9dGXirjmwB4jwqH1AmK4pC9t4 0k1eGPDhQ06ReOZTVpm6plLQTdE4GnS/W+8oPVfmelF3F1T0QJRmx29M0w8i pEjHpmkSaLcXst41moRupFa0YMwFKDKemc1TiMAoljGZgMoxI4ArLa95/tS+ DdNZJCXkuvCWhzaZekGu6ZyeQ0xVbZtVguMWjaCw0Zdt8z4v0L2ZxtZOps7l 7oKAgtkwqdvqUCbHSJ7e0sJpLYs7wCTJmBz16batqcvRSty2NszzEzqoXGsc dcxa3iqp+GTS8ke+WNz3Oe7MRmc7Mfw3faV43M8Fb2r+dUS49aL2z7j1e9zP BW9rJzpVnKfQhCjQWG23ip/mB75W5LDbbxU/zA98olTNwC2B7GCp64uoMTjg k7Z2aOUcBik+hpKXvZI3xsMMbm5MzJjStZQ5zq+dpCZWDJ2C4MmLXslc0H7I yO/8opvr/bM9+F9Di27v3dhffGF4+wAOjyYVUTfRW7y9/eTcTNJLGOikIPkz l1BU+SimrHvBtmhlmycU2k48uCg9QZJ1crpLEW7A4ZpxG8FpcQW0c5/2uRVI lbV9kN271j9SkhuC6rLEEBj/AFaAspmdn4SDwYqDj2hWOwOof2pqDIrOGS1L iXzucA+gawucGUJdkFCDUbVXIfWxWoLJp971rYY765uHQwNpFG0D9nUYhpc9 2HmTu5NsXg2z5HsLekZaZgfNgubfR76CCxkfBC8X9GQZiSczyHsL8RTo/Qlt QtJbO7kglaxj20OWKuShGGWuKdERlxti9s+49XvczwUdq/nCodz+V7Z9x6ve 5fgje1fzhKTlYEIQstBYZb+Kn+YHvrc1g75HRXk0rMHslLm8ocShVk1Bw6vG gPWOpQ7RThHGkICeqlHB1UnuOT3d6TUtQikl62EEH8yMOP0OaAnd1YalLG+M yQgO6Li1gaeIjGRLzlFejt9VdCHQNk6k+rTZt4POo2a2nzOMlvKSekXGN5HH WtKKdmtdSs2iMXZYweq1tCB/lcoUxajIZWMccraFwM+QEPGYdFzgNnArkha2 s9al0q6ntes/pjDW5a14DXFoDiclelQUJoEwiJBqNqdQP1plrLZQv6u1lc4T RddGAS2jXbTXlptTCSSS2kMcjBnbicrw4Y+VlQmRa9Fnt5BAzVZrjq4QcjIz VrOEdX0iR6FJai6xfOH2T5pGubWR85JcXcpx2KH0S2N1IGyua1rXZT1TmyP2 AgtbhUYq0/0O0jEmaS5d1T2xnLE3Eu4RtTMTqrFz+X7Z9x6vW5fgje1fzhUz VbdttcmFpLmskcATgT0ZArnuV4I3tZOcK0nKwIQhZaCwWUVurhuysjsf8RW9 LBZPnJu0d7xQSen96gaRBcviDvWDaivoKdOkvT611IfT8Sb2nqhOCqwa1llG bvMlMeDi86ZyWNsSS5xLjiTlbt9Kcwn9lj953OkpCrhcmhsrUHa4/wCFqUis rao2+hv6EEpaFMLeD/T2COZwt3mN8VBnaMpqR+rRTbRdPb0rqQ+c/W4qC00n vt2OJzPpYrDH6isZRl1BlOZ0jn5SSAabaEY4eVXTcrwRvayc4VQvTWqt+5Xg g7WTnClWcrChCFloLBpPnJu0d7xW8rBZPnJu0d7xRKlbT1U4cU3tfVS7lWTG I/sj7TklIUpF+GfackZCqsJE4paA4psTil4DikWpHTR/zLryuj9xWFnqKvWH zc/lye6rBGasVjJhecKuO5Xgg7WTnCp17QVVx3J8EHayc4U2WcrChCFloLBZ PnJu0d7xW9LBZPm5u0dzlEqUtTgnDtia2mxOH7FayYR/hn23JGUpWP8ADPtu SEpVWEScUvb7U34U4g2pFqTsfm5uRnuqeiPQUBYn/lzckfuqdjPRVjJjfO2q 57keBt7WTnCpd5wq6bj+BN7WTnClWcrEhCFloLBJPm5u0d7xW9rBZPm5u0d7 xQqRtTQJw44JvbbEu84KuZgw/s3e25ISFKsqGur976aCqReq3CXCl4dqQO1L QnEJCpSy+bl8oZzKbjPRUFZhwuXk8IB5QfV9Cmoz0cVWTW82FXTcfwIdtJzh Ui9mjDTV4HKQrtuNX+hCu3rpOdSrOVjQhCy0FgV7UCdwNCJziPKSt9WBX5o2 ccc55ygRmmlYyAxyOaTGC6hOJqUn368H5zvOapNz84aPujKFwhgoby5GHWH6 F4Lm5eaAlx8gB+pIu2rUtKt7eCxtpNMit2mSNrg+VhJdmGOZzQTtVnVnbbtx 05ZoXXm0tePLl/8AS47zOPtkLVm2e8Erjnu7IRHa1sT3GnEK0UHvTu1by92k juLa1kcSx8sp6oSONMrQGgjzphmeTr1nwpztRmfbRRAZJIy7NO1zg94Oxrsd jeBIGaZ3rSPdyuJ+tFzazWdzLa3Dcs0Lix4rXEeVchR0egft2+01bVuT4Ke3 l51i5+Zb7TfqWz7j+CHt5edX0FjQhCgFgGpbZO2ct/WA6ltl8kzvrQMG8a8X WWgafvCv0p6zTJHtDhICDxCqlsnLWnj23uNZnCPyPd6rSeRXvdC+kmsO6SVE tocAdpidsPmOCq3dpbZpY1pe5+OamwbNg2qQ0e7h0+4NyHPEpaWO61ji1wPB Ruxa1s5yx5fHtM63W5jRo+sc3i8gVT3m1Pd2SW3fPK69msi7LZRfhOeT+bJw YjEBOHb2sMRbE+KIkUz0eXDgqA4UVPfBZQukIm66riQQ12I5KJ8OWmlz1m3w ZXl5LfXUt1NTrpnl76Cgx4AOIJEKSZaRXZOUlgZ5Mu3l2pC8tI7UhucmQ0OU 02HGuCz3TOHp+rfs78Y1NWn9s0+ULatx/BD28vOsVqOtafKFte5Hgh7eXnWv RhYkIQoBYDqX53bHnK35fP8AqD8z5gMQJTX0lAzc6rWjiFF62edjcjJHNZ90 EgLyNnWODK5SdleEpY2MnGFLj1a1m3Ouf4IGWU7XuPnK5qeMpx3N/C5ddxP3 kzDt3vua1PGvKlP2acHEAuI5EpLpcbBUPcTyBO6NfVv7IypRVPDYHgf9C4ls zEwvc7AbMNpTMZum3sbg9IHyhbbuR4J/Gk51iQBqFtW4crJdAD2GreukFfOF WVlQhCAWC3NtE+6mqD+I7YfKVvSzm9/671MSyS2tzDM1znODX5o3UOP6w+lB Sm6bC7Y97fQf0J02ItaAXhxH2i3Hz0cpt+5+8UJA7mZMK1Y+M/7gmz9C1pta 2FxhtpG4j6AlkvJrvvr/AJuEU5jhskYOVhP+9cEyD85g/hH4k+k07UW+taTj ljf8KRdpmpbe5z0PD1T6enKnbr7Nfb5P2psJJmnCdv8A8v0lddbO/bOD/Cb8 SVGl6i40FpOT2T/hTiHQ9ZeehYXDv4T/ANCduvtF+3yftt8kYYHP9aX0RgfW nB0q1mIMzpJMuwAtYP8AS1SNpu5rrsRYygD7wDPfLVKQbq628AugEdcOm9uH LlJVxrOJGL5PJel2titO06wi9S3FeNxLveK0XchoboTQAGjrZMAKDaFGR7j3 cn49zHHtqGNL+TbkVm0jS49KsxaRyOlaHF2ZwANXciWsyXJ+hCFGghCEAhCE AhCEAhCEAhCEAhCEAhCEH//Z --= Multipart Boundary 0506021627-- From noreply@sourceforge.net Mon May 6 17:07:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 09:07:50 -0700 Subject: [Patches] [ python-Patches-552804 ] Explain buffering effects of xreadlines Message-ID: Patches item #552804, was opened at 2002-05-06 05:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552804&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Explain buffering effects of xreadlines Initial Comment: A new user today was confused by the fact that calling python with "-u" to unbuffer stdin was not having any noticable effects when doing: for i in sys.stdin.xreadlines(): print i This patch adds a description to the xreadlines() method of the xreadlines module documentation which mentions this problem. It seems the user would have been happy with at least being able to find something in the documentation saying that it would happen... ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-06 12:07 Message: Logged In: YES user_id=3066 Checked in patch as Doc/lib/libxreadlines.tex revisions 1.3, 1.2.22.1, and 1.2.4.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552804&group_id=5470 From noreply@sourceforge.net Mon May 6 17:27:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 09:27:38 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 03:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 16:27 Message: Logged In: YES user_id=80475 Done. Added news and docs. Instead of raising an exception, converted PySequence_Check to an assertion because it is a pre-condition of the function and has already been checked by PyObject_GetIter. The only way for the assertion to fail is if an extension writer by-passes _GetIter and directly calls PySeqIter_New with a non-sequence argument. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 08:42 Message: Logged In: YES user_id=21627 The patch looks good, but needs some minor corrections: Returning NULL in response to a failed _Check is incorrect - no exception is set at that point. I think the addition of PySequence_ITEM needs to be mentioned in the documentation and Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Mon May 6 17:56:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 09:56:13 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 05:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 18:56 Message: Logged In: YES user_id=21627 I'm not sure what the convention for assertions is; the alternative is to raise BadInternalCall. If I would have to define a convention, it would go like this: If this can be called incorrectly by extension modules, it's a bad internal call; if the only callers would be the core, it's an assert. It is also an assert if you can prove that it can never occur with the current code base. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 18:27 Message: Logged In: YES user_id=80475 Done. Added news and docs. Instead of raising an exception, converted PySequence_Check to an assertion because it is a pre-condition of the function and has already been checked by PyObject_GetIter. The only way for the assertion to fail is if an extension writer by-passes _GetIter and directly calls PySeqIter_New with a non-sequence argument. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:42 Message: Logged In: YES user_id=21627 The patch looks good, but needs some minor corrections: Returning NULL in response to a failed _Check is incorrect - no exception is set at that point. I think the addition of PySequence_ITEM needs to be mentioned in the documentation and Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Mon May 6 18:29:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 10:29:15 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 03:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 17:29 Message: Logged In: YES user_id=80475 Agreed. Replaced assertion with BadInternalCall. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 16:56 Message: Logged In: YES user_id=21627 I'm not sure what the convention for assertions is; the alternative is to raise BadInternalCall. If I would have to define a convention, it would go like this: If this can be called incorrectly by extension modules, it's a bad internal call; if the only callers would be the core, it's an assert. It is also an assert if you can prove that it can never occur with the current code base. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 16:27 Message: Logged In: YES user_id=80475 Done. Added news and docs. Instead of raising an exception, converted PySequence_Check to an assertion because it is a pre-condition of the function and has already been checked by PyObject_GetIter. The only way for the assertion to fail is if an extension writer by-passes _GetIter and directly calls PySeqIter_New with a non-sequence argument. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 08:42 Message: Logged In: YES user_id=21627 The patch looks good, but needs some minor corrections: Returning NULL in response to a failed _Check is incorrect - no exception is set at that point. I think the addition of PySequence_ITEM needs to be mentioned in the documentation and Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Tue May 7 04:46:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 06 May 2002 20:46:04 -0700 Subject: [Patches] [ python-Patches-553108 ] Deprecate bsddb Message-ID: Patches item #553108, was opened at 2002-05-07 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Nobody/Anonymous (nobody) Summary: Deprecate bsddb Initial Comment: Large numbers of inserts break bsddb, as first discovered in Python 1.5 (bug 408271). According to Barry Warsaw, "trying to get the bsddb module that comes with Python to work is a hopeless cause." If it's broken, let's discourage people from using it. In particular, let's ensure that people importing shelve or anydbm don't end up using it by default. The submitted patch adds a DeprecationWarning to the bsddb module and removes bsddb from the list of db module candidates in anydbm. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 From noreply@sourceforge.net Tue May 7 09:13:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 01:13:04 -0700 Subject: [Patches] [ python-Patches-553171 ] optionally make shelve less surprising Message-ID: Patches item #553171, was opened at 2002-05-07 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: optionally make shelve less surprising Initial Comment: shelve has highly surprising behavior wrt modifiable values: s = shelve.open('she.dat','c') s['ciao'] = range(3) s['ciao'].append(4) # doesn't "TAKE"! Explaining to beginners that s['ciao'] is returning a temporary object and the modification is done on the temporary thus "silently ignored" is hard indeed. It also makes shelve far less convenient than it could be (whenever modifiable values must be shelved). Having s keep track of all values it has returned may perhaps break some existing program (due to extra memory consumption and/or to lack of "implicit copy"/"snapshot" behavior) so I've made the 'caching' change optional and by default off. However it's now at least possible to obtain nonsurprising behavior: s = shelve.open('she.dat','c',smart=1) s['ciao'] = range(3) s['ciao'].append(4) # no surprises any more I suspect the 'smart=1' should be made the default, but, if we at least put it in now, then perhaps we can migrate to having it as the default very slowly and gradually. Alex ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 From noreply@sourceforge.net Tue May 7 13:00:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 05:00:07 -0700 Subject: [Patches] [ python-Patches-553230 ] altbininstall patch Message-ID: Patches item #553230, was opened at 2002-05-07 04:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553230&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: altbininstall patch Initial Comment: This patch resolves the following make install error by creating $(LIBDIR): Creating directory /tmp/python-shared/usr/bin /usr/bin/install -c python /tmp/python-shared/usr/bin/python2.3 if test -f libpython2.3.so; then \ /usr/bin/install -c -m 555 libpython2.3.so /tmp/python-shared/usr/lib/libpython2.3.so.1.0; \ else true; \ fi /usr/bin/install: cannot create regular file `/tmp/python-shared/usr/lib/libpython2.3.so.1.0': No such file or directory make: *** [altbininstall] Error 1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553230&group_id=5470 From noreply@sourceforge.net Tue May 7 13:30:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 05:30:16 -0700 Subject: [Patches] [ python-Patches-549901 ] use readline in pydoc.help if available Message-ID: Patches item #549901, was opened at 2002-04-28 17:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549901&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Yallop (yallop) Assigned to: Nobody/Anonymous (nobody) Summary: use readline in pydoc.help if available Initial Comment: Interactive help (via pydoc.interact in 2.1 onwards) doesn't use GNU readline. This is easily amended by using raw_input() instead of input.readline(). The patch assumes that Helper.input is sys.stdin when Helper.interact() is called but can be fixed trivially if this assumption is invalid.. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:30 Message: Logged In: YES user_id=6380 I like the idea, but not the execution. It should only use raw_input when self.input is sys.stdin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549901&group_id=5470 From noreply@sourceforge.net Tue May 7 13:31:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 05:31:44 -0700 Subject: [Patches] [ python-Patches-549975 ] block support for builtin iter() Message-ID: Patches item #549975, was opened at 2002-04-28 21:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549975&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: block support for builtin iter() Initial Comment: >>> import xiter >>> for i in xiter.iter(range(40), blocksize=12): ... print i ... [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11] [12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23] [24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35] [36, 37, 38, 39] (attached simple patch as extension module with unittest and demonstration script) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:31 Message: Logged In: YES user_id=6380 I'm rejecting this idea for now; it seems to esoteric and arbitrary for the standard library. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 13:45 Message: Logged In: YES user_id=21627 As this is already a distutils package, I suggest that you distribute the code to users first, before suggesting it to be included into Python. It might be best to put it on your home page, and add a link in the Vaults of Parnassus. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549975&group_id=5470 From noreply@sourceforge.net Tue May 7 13:34:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 05:34:25 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 13:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 04:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Tue May 7 13:35:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 05:35:36 -0700 Subject: [Patches] [ python-Patches-550551 ] Read/Write buffers from buffer() Message-ID: Patches item #550551, was opened at 2002-04-30 05:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550551&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: Scott Gilbert (xscott) >Assigned to: Nobody/Anonymous (nobody) Summary: Read/Write buffers from buffer() Initial Comment: The buffer() builtin does not currently allow the creation of read-write buffers. So there is no way from pure Python code to manipulate objects which support getting a writable pointer via their PyBufferProcs. This patch tries to create a read- write buffer first, and if that fails it will return a read-only buffer object as before. It's tempting to check if the PyBufferProcs has the bf_getwritebuffer pointer and simply return PyBuffer_FromReadWriteObject(...) in this case. This ends up being incorrect for PyStrings since they do have the bf_getwritebuffer pointer, but that always sets an exception. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:35 Message: Logged In: YES user_id=6380 Please don't assign patches to random developers. ---------------------------------------------------------------------- Comment By: Scott Gilbert (xscott) Date: 2002-05-05 00:29 Message: Logged In: YES user_id=38318 If you take patch 552438, then there shouldn't be anything wrong with this small feature patch... ---------------------------------------------------------------------- Comment By: Scott Gilbert (xscott) Date: 2002-05-03 04:28 Message: Logged In: YES user_id=38318 This patch should not be accepted until another one fixing a bug in PyBufferObjects is accepter. So please back burner this one until further notice. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550551&group_id=5470 From noreply@sourceforge.net Tue May 7 13:37:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 05:37:20 -0700 Subject: [Patches] [ python-Patches-550732 ] PyArg_VaParseTupleAndKeywords Message-ID: Patches item #550732, was opened at 2002-04-30 14:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550732&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyArg_VaParseTupleAndKeywords Initial Comment: I need a Va version of PyArg_ParseTupleAndKeywords for some generic code where the number of expected arguments isn't known until runtime. Attached is a patch which adds a PyArg_VaParseTupleAndKeywords to getargs.c. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:37 Message: Logged In: YES user_id=6380 Looks like a good idea to me. Needs a small API doc patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550732&group_id=5470 From noreply@sourceforge.net Tue May 7 13:55:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 05:55:18 -0700 Subject: [Patches] [ python-Patches-552438 ] PyBufferObject fixes Message-ID: Patches item #552438, was opened at 2002-05-05 04:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Gilbert (xscott) >Assigned to: Nobody/Anonymous (nobody) Summary: PyBufferObject fixes Initial Comment: This patch fixes these problems: 1) Dangling pointer problem 2) buffer allocated by PyBuffer_New not aligned The PyBufferObject acts differently depending on whether it allocated the memory or if it's borrowing the memory from a PyBufferProcs supporting object. In the case of allocating it's own memory, I made a slight addition that adds some padding so that the ptr is on a sizeof(double) boundary. In the case of borrowing another objects PyBufferProcs memory, PyBufferObject no longer caches the pointer. This might slow things down (probably not by much), but it keeps PyBufferObject from working with a stale pointer. Normally I wouldn't do this, but since this patch touches pretty much every function anyway, I fixed many deviations from the Python coding style. ---------------------------------------------------------------------- >Comment By: Scott Gilbert (xscott) Date: 2002-05-07 12:55 Message: Logged In: YES user_id=38318 Apparently assigning a patch is poor form. My bad. ---------------------------------------------------------------------- Comment By: Scott Gilbert (xscott) Date: 2002-05-05 04:27 Message: Logged In: YES user_id=38318 Can I assign this to you or does it take admin privs? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470 From noreply@sourceforge.net Tue May 7 14:21:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 06:21:05 -0700 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 19:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-07 13:21 Message: Logged In: YES user_id=329402 test_email_codecs is skipped unless the optional Japanese codecs are installed (this is also in the exceptions list for win32 and linux2). Cygwin does not currently support large files, locales, or unicode file system semantics (test_unicode_file is also in the exceptions list for all but win32, test_locale is in most of them, and test_largefile is in *all* of them). test_winreg is a stickier one. This is clearly specific to Windows, and the goal of Cygwin is to present a UNIX-like interface, not a Windows-like interface. There are patches that will enable this support under Cygwin Python, although they pull in quite a bit of the Windows-specific code and would create maintenance issues for Python's codebase. At present this is considered unsupported in Cygwin Python. There are three additional tests that are in all or almost all of the exception lists: test_curses test_socket_ssl test_socketserver These are disabled unless "-u" is used to specifically enable them. It appears that these should also be added to the list. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 08:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Tue May 7 15:02:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 07:02:56 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 16:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Tue May 7 17:23:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 09:23:27 -0700 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 21:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 18:23 Message: Logged In: YES user_id=21627 I'm quite unhappy with the entire _expectations mechanism. E.g. the fact that test_email_codecs is skipped has *nothing* to do with the distribution being build on Windows, or with Cygwin; I'd rather see the expected fails to take into account available resources (e.g. absence of the Japanese codecs is a good reason for skipping the tests). ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-07 15:21 Message: Logged In: YES user_id=329402 test_email_codecs is skipped unless the optional Japanese codecs are installed (this is also in the exceptions list for win32 and linux2). Cygwin does not currently support large files, locales, or unicode file system semantics (test_unicode_file is also in the exceptions list for all but win32, test_locale is in most of them, and test_largefile is in *all* of them). test_winreg is a stickier one. This is clearly specific to Windows, and the goal of Cygwin is to present a UNIX-like interface, not a Windows-like interface. There are patches that will enable this support under Cygwin Python, although they pull in quite a bit of the Windows-specific code and would create maintenance issues for Python's codebase. At present this is considered unsupported in Cygwin Python. There are three additional tests that are in all or almost all of the exception lists: test_curses test_socket_ssl test_socketserver These are disabled unless "-u" is used to specifically enable them. It appears that these should also be added to the list. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Tue May 7 17:38:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 09:38:00 -0700 Subject: [Patches] [ python-Patches-553171 ] optionally make shelve less surprising Message-ID: Patches item #553171, was opened at 2002-05-07 10:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: optionally make shelve less surprising Initial Comment: shelve has highly surprising behavior wrt modifiable values: s = shelve.open('she.dat','c') s['ciao'] = range(3) s['ciao'].append(4) # doesn't "TAKE"! Explaining to beginners that s['ciao'] is returning a temporary object and the modification is done on the temporary thus "silently ignored" is hard indeed. It also makes shelve far less convenient than it could be (whenever modifiable values must be shelved). Having s keep track of all values it has returned may perhaps break some existing program (due to extra memory consumption and/or to lack of "implicit copy"/"snapshot" behavior) so I've made the 'caching' change optional and by default off. However it's now at least possible to obtain nonsurprising behavior: s = shelve.open('she.dat','c',smart=1) s['ciao'] = range(3) s['ciao'].append(4) # no surprises any more I suspect the 'smart=1' should be made the default, but, if we at least put it in now, then perhaps we can migrate to having it as the default very slowly and gradually. Alex ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 18:38 Message: Logged In: YES user_id=21627 Even more important than the backwards compatibility might be the issue that it writes back all accessed objects on close, which might be expensive if there have been many read-only accesses. So I think the option name could be also 'slow'; although 'writeback' might be more technical. Also, I wonder whether write-back should be attempted if the shelve was opened read-only. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 From noreply@sourceforge.net Tue May 7 18:06:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 10:06:25 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 19:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-07 19:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 14:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Tue May 7 18:08:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 10:08:09 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 19:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-07 19:08 Message: Logged In: YES user_id=11105 Or maybe add a __doc__ tp_member (or whatever) which always returns None? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 19:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 14:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Tue May 7 19:01:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 11:01:00 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 05:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Martin v. Löwis (loewis) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 19:29 Message: Logged In: YES user_id=80475 Agreed. Replaced assertion with BadInternalCall. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 18:56 Message: Logged In: YES user_id=21627 I'm not sure what the convention for assertions is; the alternative is to raise BadInternalCall. If I would have to define a convention, it would go like this: If this can be called incorrectly by extension modules, it's a bad internal call; if the only callers would be the core, it's an assert. It is also an assert if you can prove that it can never occur with the current code base. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 18:27 Message: Logged In: YES user_id=80475 Done. Added news and docs. Instead of raising an exception, converted PySequence_Check to an assertion because it is a pre-condition of the function and has already been checked by PyObject_GetIter. The only way for the assertion to fail is if an extension writer by-passes _GetIter and directly calls PySeqIter_New with a non-sequence argument. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:42 Message: Logged In: YES user_id=21627 The patch looks good, but needs some minor corrections: Returning NULL in response to a failed _Check is incorrect - no exception is set at that point. I think the addition of PySequence_ITEM needs to be mentioned in the documentation and Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Tue May 7 19:02:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 11:02:40 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 05:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. Löwis (loewis) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 20:02 Message: Logged In: YES user_id=21627 It appears that this code might still return NULL without setting an exception, if it_index is larger then the size. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 19:29 Message: Logged In: YES user_id=80475 Agreed. Replaced assertion with BadInternalCall. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 18:56 Message: Logged In: YES user_id=21627 I'm not sure what the convention for assertions is; the alternative is to raise BadInternalCall. If I would have to define a convention, it would go like this: If this can be called incorrectly by extension modules, it's a bad internal call; if the only callers would be the core, it's an assert. It is also an assert if you can prove that it can never occur with the current code base. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 18:27 Message: Logged In: YES user_id=80475 Done. Added news and docs. Instead of raising an exception, converted PySequence_Check to an assertion because it is a pre-condition of the function and has already been checked by PyObject_GetIter. The only way for the assertion to fail is if an extension writer by-passes _GetIter and directly calls PySeqIter_New with a non-sequence argument. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:42 Message: Logged In: YES user_id=21627 The patch looks good, but needs some minor corrections: Returning NULL in response to a failed _Check is incorrect - no exception is set at that point. I think the addition of PySequence_ITEM needs to be mentioned in the documentation and Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Tue May 7 19:51:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 11:51:18 -0700 Subject: [Patches] [ python-Patches-552438 ] PyBufferObject fixes Message-ID: Patches item #552438, was opened at 2002-05-05 00:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Scott Gilbert (xscott) Assigned to: Nobody/Anonymous (nobody) Summary: PyBufferObject fixes Initial Comment: This patch fixes these problems: 1) Dangling pointer problem 2) buffer allocated by PyBuffer_New not aligned The PyBufferObject acts differently depending on whether it allocated the memory or if it's borrowing the memory from a PyBufferProcs supporting object. In the case of allocating it's own memory, I made a slight addition that adds some padding so that the ptr is on a sizeof(double) boundary. In the case of borrowing another objects PyBufferProcs memory, PyBufferObject no longer caches the pointer. This might slow things down (probably not by much), but it keeps PyBufferObject from working with a stale pointer. Normally I wouldn't do this, but since this patch touches pretty much every function anyway, I fixed many deviations from the Python coding style. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-05-07 14:51 Message: Logged In: YES user_id=31435 Na, assigning a bug is fine by me -- it helps to have *someone* feel guilty . Assigning it doesn't mean it goes to the top of the assignee's heap, though. I can't make time to look at it this week, so it's just as well that it got unassigned. ---------------------------------------------------------------------- Comment By: Scott Gilbert (xscott) Date: 2002-05-07 08:55 Message: Logged In: YES user_id=38318 Apparently assigning a patch is poor form. My bad. ---------------------------------------------------------------------- Comment By: Scott Gilbert (xscott) Date: 2002-05-05 00:27 Message: Logged In: YES user_id=38318 Can I assign this to you or does it take admin privs? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552438&group_id=5470 From noreply@sourceforge.net Tue May 7 20:20:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 12:20:20 -0700 Subject: [Patches] [ python-Patches-553403 ] configure.in INSTSONAME typo patch Message-ID: Patches item #553403, was opened at 2002-05-07 11:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553403&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: configure.in INSTSONAME typo patch Initial Comment: This patch fixes a minor typo in configure.in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553403&group_id=5470 From noreply@sourceforge.net Tue May 7 21:23:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 13:23:46 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 03:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. Löwis (loewis) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-07 20:23 Message: Logged In: YES user_id=80475 This is the current and documented behavior of the next routine for iterobjects. From the docs, "If the object is an iterator, this retrieves the next value from the iteration, and returns NULL with no exception set if there are no remaining items". Also, note the existing special case for lists has identical coding and behavior. Also, compare to the code fragment below it, for the general case, which explicitly calls PyErr_Clear() and then returns NULL. IOW, I believe the code is correct as it stands and is ready to be loaded to CVS. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 18:02 Message: Logged In: YES user_id=21627 It appears that this code might still return NULL without setting an exception, if it_index is larger then the size. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 17:29 Message: Logged In: YES user_id=80475 Agreed. Replaced assertion with BadInternalCall. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 16:56 Message: Logged In: YES user_id=21627 I'm not sure what the convention for assertions is; the alternative is to raise BadInternalCall. If I would have to define a convention, it would go like this: If this can be called incorrectly by extension modules, it's a bad internal call; if the only callers would be the core, it's an assert. It is also an assert if you can prove that it can never occur with the current code base. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 16:27 Message: Logged In: YES user_id=80475 Done. Added news and docs. Instead of raising an exception, converted PySequence_Check to an assertion because it is a pre-condition of the function and has already been checked by PyObject_GetIter. The only way for the assertion to fail is if an extension writer by-passes _GetIter and directly calls PySeqIter_New with a non-sequence argument. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 08:42 Message: Logged In: YES user_id=21627 The patch looks good, but needs some minor corrections: Returning NULL in response to a failed _Check is incorrect - no exception is set at that point. I think the addition of PySequence_ITEM needs to be mentioned in the documentation and Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Tue May 7 21:59:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 13:59:30 -0700 Subject: [Patches] [ python-Patches-552468 ] Correct ref manual error for list type Message-ID: Patches item #552468, was opened at 2002-05-05 08:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552468&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Correct ref manual error for list type Initial Comment: Closes SF bug www.python.org/sf/548874 Docs had old information that the list object did not support a .__getitem__ method. With the new style classes, they do: >>> x = list('abc') >>> x.__getitem__(1) 'b' Deleted erroneous sentence. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552468&group_id=5470 From noreply@sourceforge.net Wed May 8 06:01:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 22:01:38 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 14:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 05:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Wed May 8 06:14:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 22:14:29 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 14:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 05:14 Message: Logged In: YES user_id=80475 One other thought. Consider changing the line to: if not callable(callback): callback = print_line This would eliminate the code breakage I outlined in the previous comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 05:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Wed May 8 07:14:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 07 May 2002 23:14:40 -0700 Subject: [Patches] [ python-Patches-483864 ] Pure python version of calendar.weekday Message-ID: Patches item #483864, was opened at 2001-11-20 17:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483864&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Pure python version of calendar.weekday Initial Comment: this version can handle past of 1970, and PURE. but this is not too slower than old one. NetBSD machine on Pentium 90MHz: $ python wday.py 1000 Time Module: 0.641623973846 Pure Python: 0.724056005478 $ python wday.py 10000 Time Module: 6.77021896839 Pure Python: 7.34891104698 Linux machine on Pentium III 800MHz: $ python wday.py 10000 Time Module: 0.611389994621 Pure Python: 0.833150982857 $ python wday.py 100000 Time Module: 6.12289500237 Pure Python: 8.36460494995 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 06:14 Message: Logged In: YES user_id=80475 Thanks for the patch. Here are a few suggestions: - Use diff -c for your patch - Update the patch to diff from the current version, 1.27. - Also change the library reference which specifies 1970. - Expand test_calendar.py to include your expanded range. - Add a range check to weekday() to raise an Error if date is before 1752 (this will be a common error if the century is omitted in a call). The current treat is to raise ValueError: year out of range. - Eliminate the comment # Importing add from operator - Change the multi-line style away from using \ which relies on there being no extra spaces at the end of a line. Instead write: sum = a + b - c - Revise the doc string to specify "Accurate for date from September 14, 1752". As specified now, it implies accuracy to the beginning of that year. - Create a special case for monthcalendar() to handle September 1752 - Submit a separate Python program that runs every possible monthcalendar from 1752 and compares the result to the Unix cal program. I checked your logic and it looks fine, but a comprehensive compare will be doubly persuasive. Some similar proof of daygap() would be helpful. - Either add daygap() to the docs or incorporate it directly inside weekday(). ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2001-11-20 17:51 Message: Logged In: YES user_id=55188 upper one of two patches is using if - if. another is using and - or. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=483864&group_id=5470 From noreply@sourceforge.net Wed May 8 08:17:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 00:17:04 -0700 Subject: [Patches] [ python-Patches-551011 ] Cygwin pyexpat patch Message-ID: Patches item #551011, was opened at 2002-05-01 16:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551011&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: Cygwin pyexpat patch Initial Comment: This patch enables the clean building of the pyexpat module under Cygwin. Note that this patch is a "cleaner" version of the one in following: http://mail.python.org/pipermail/xml-sig/2002-January/006943.html ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 09:17 Message: Logged In: YES user_id=21627 Thanks for the patch; applied as expat.h 1.3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551011&group_id=5470 From noreply@sourceforge.net Wed May 8 08:20:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 00:20:39 -0700 Subject: [Patches] [ python-Patches-472523 ] Reminder: 2.3 should check tp_compare Message-ID: Patches item #472523, was opened at 2001-10-18 19:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472523&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Reminder: 2.3 should check tp_compare Initial Comment: In 2.3, the outcome of tp_compare should be required to be -1, 0 or 1; other values should be considered *illegal*. (In 2.2, the docs were changed to stress this but for backwards compatibility this isn't enforced.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:20 Message: Logged In: YES user_id=80475 Here are a few thoughts from my review: Patch needs to diff from current version, 2.173 of object.c Patch compiles okay. Code passes regrtest.py without generating warnings. Code agrees with docs. Scanned remaining code base and found no other direct calls to tp_compare in other *.c or *.h files. If this were an error rather than a warning, convention would indicate a BadInternalCall since this can only be generated by an extension writer. I'm wondering if we are warning the wrong person. An old extension recompiled for Py2.3 will compile fine but then warn an end-user (not the extension writer) about a mysterious tp_compare that they can neither see, nor touch. In try_3way_compare, the warning is not given for instances. Are we exempting instances from the warnings? In try_3way_compare, the warning is given in the section, "v's comparison" but is omitted in "w's comparison" which follows. I think the priority should be raised on this patch because it needs to be in-place for Py2.3a so that we get the earliest possible notice if the warning clashes with use in one of the popular extensions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-09 11:54 Message: Logged In: YES user_id=21627 Attached is a patch that implements this test, producing a warning if tp_compare does not follow that restriction. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-09 11:54 Message: Logged In: YES user_id=21627 Attached is a patch that implements this test, producing a warning if tp_compare does not follow that restriction. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472523&group_id=5470 From noreply@sourceforge.net Wed May 8 08:46:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 00:46:47 -0700 Subject: [Patches] [ python-Patches-472523 ] Reminder: 2.3 should check tp_compare Message-ID: Patches item #472523, was opened at 2001-10-18 21:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472523&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Reminder: 2.3 should check tp_compare Initial Comment: In 2.3, the outcome of tp_compare should be required to be -1, 0 or 1; other values should be considered *illegal*. (In 2.2, the docs were changed to stress this but for backwards compatibility this isn't enforced.) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 09:46 Message: Logged In: YES user_id=21627 I think warning the user is the best thing we can offer; making it an error would break extensions - users can disable the warning if they want to. Hopefully, they will report the problem to the extension author, and hopefully, the extension author tests his code with the new Python release, to notice the problem before his users do. Instances are exempted from the warnings because they already use the "target result set": -1,0,1 for regular outcome; -2 for exceptions. The original rationale for this tightening of the result set is to let -2 indicate exceptions in future Python releases. Perhaps it should also check that, if an exception occured, that the result value is -2. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 09:20 Message: Logged In: YES user_id=80475 Here are a few thoughts from my review: Patch needs to diff from current version, 2.173 of object.c Patch compiles okay. Code passes regrtest.py without generating warnings. Code agrees with docs. Scanned remaining code base and found no other direct calls to tp_compare in other *.c or *.h files. If this were an error rather than a warning, convention would indicate a BadInternalCall since this can only be generated by an extension writer. I'm wondering if we are warning the wrong person. An old extension recompiled for Py2.3 will compile fine but then warn an end-user (not the extension writer) about a mysterious tp_compare that they can neither see, nor touch. In try_3way_compare, the warning is not given for instances. Are we exempting instances from the warnings? In try_3way_compare, the warning is given in the section, "v's comparison" but is omitted in "w's comparison" which follows. I think the priority should be raised on this patch because it needs to be in-place for Py2.3a so that we get the earliest possible notice if the warning clashes with use in one of the popular extensions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-09 12:54 Message: Logged In: YES user_id=21627 Attached is a patch that implements this test, producing a warning if tp_compare does not follow that restriction. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-09 12:54 Message: Logged In: YES user_id=21627 Attached is a patch that implements this test, producing a warning if tp_compare does not follow that restriction. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472523&group_id=5470 From noreply@sourceforge.net Wed May 8 08:54:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 00:54:12 -0700 Subject: [Patches] [ python-Patches-549662 ] iterzip() implementation Message-ID: Patches item #549662, was opened at 2002-04-28 01:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549662&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: iterzip() implementation Initial Comment: Fast, clean C implementation of iterzip(). def iterzip(*collections): iterables = map(iter, collections) while 1: yield tuple([i.next() for i in iterables]) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:54 Message: Logged In: YES user_id=80475 Closed due to lack of interest. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549662&group_id=5470 From noreply@sourceforge.net Wed May 8 09:02:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 01:02:44 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 16:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- >Comment By: Geert Jansen (geertj) Date: 2002-05-08 10:02 Message: Logged In: YES user_id=537938 Hi! Thanks for your comments. I uploaded a new version of the patch, relative to version 1.66 of ftplib.py, that uses the callable(callback) variant. I tested the patch and verified that it works as expected. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:14 Message: Logged In: YES user_id=80475 One other thought. Consider changing the line to: if not callable(callback): callback = print_line This would eliminate the code breakage I outlined in the previous comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Wed May 8 09:26:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 01:26:55 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 14:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 08:26 Message: Logged In: YES user_id=80475 That was quick! You have my sign-off. Will recommend to a developer for a commit. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2002-05-08 08:02 Message: Logged In: YES user_id=537938 Hi! Thanks for your comments. I uploaded a new version of the patch, relative to version 1.66 of ftplib.py, that uses the callable(callback) variant. I tested the patch and verified that it works as expected. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 05:14 Message: Logged In: YES user_id=80475 One other thought. Consider changing the line to: if not callable(callback): callback = print_line This would eliminate the code breakage I outlined in the previous comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 05:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Wed May 8 09:45:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 01:45:24 -0700 Subject: [Patches] [ python-Patches-552433 ] Looping Optimization Message-ID: Patches item #552433, was opened at 2002-05-05 05:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. Löwis (loewis) Summary: Looping Optimization Initial Comment: Optimized the inner loop for iterobjects resulting in a 19% speed-up for tuples and a 15% improvement for strings and xrange objects. Dictionaries and lists are unaffected (already handled as a special case or with their own iterators). 1. Replaced PyList_Check with PyList_CheckExact. Loses the special case handling for list subtypes but gains speed because PyList_Check called the slow function, PyType_IsSubtype. 2. Added special case handling for tuples. Identical to the existing special case for lists (calls ob_size and ob->item[i] directly). 3. Replaced the call to PySequence_GetItem function with a macro for direct access to the sequence's sq_item slot. Saves a function call, unnecessary (previously checked) checks for tp_as_sequence and sq_item, and an unnecessary check for negative indices (sq_item has its own checks). This small patch speeds-up looping throughout Python whether it is called through list(seq), a for-loop, or a functional. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 10:45 Message: Logged In: YES user_id=21627 Thanks for the patch; applied as iterobject.c 1.9 NEWS 1.404 abstract.h 2.44 abstract.tex 1.14 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-07 22:23 Message: Logged In: YES user_id=80475 This is the current and documented behavior of the next routine for iterobjects. From the docs, "If the object is an iterator, this retrieves the next value from the iteration, and returns NULL with no exception set if there are no remaining items". Also, note the existing special case for lists has identical coding and behavior. Also, compare to the code fragment below it, for the general case, which explicitly calls PyErr_Clear() and then returns NULL. IOW, I believe the code is correct as it stands and is ready to be loaded to CVS. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 20:02 Message: Logged In: YES user_id=21627 It appears that this code might still return NULL without setting an exception, if it_index is larger then the size. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 19:29 Message: Logged In: YES user_id=80475 Agreed. Replaced assertion with BadInternalCall. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 18:56 Message: Logged In: YES user_id=21627 I'm not sure what the convention for assertions is; the alternative is to raise BadInternalCall. If I would have to define a convention, it would go like this: If this can be called incorrectly by extension modules, it's a bad internal call; if the only callers would be the core, it's an assert. It is also an assert if you can prove that it can never occur with the current code base. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-06 18:27 Message: Logged In: YES user_id=80475 Done. Added news and docs. Instead of raising an exception, converted PySequence_Check to an assertion because it is a pre-condition of the function and has already been checked by PyObject_GetIter. The only way for the assertion to fail is if an extension writer by-passes _GetIter and directly calls PySeqIter_New with a non-sequence argument. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:42 Message: Logged In: YES user_id=21627 The patch looks good, but needs some minor corrections: Returning NULL in response to a failed _Check is incorrect - no exception is set at that point. I think the addition of PySequence_ITEM needs to be mentioned in the documentation and Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552433&group_id=5470 From noreply@sourceforge.net Wed May 8 09:49:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 01:49:52 -0700 Subject: [Patches] [ python-Patches-551410 ] xrange() optimization Message-ID: Patches item #551410, was opened at 2002-05-02 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. Löwis (loewis) Summary: xrange() optimization Initial Comment: Performance improvement for xrange() when used in loops or list(xrange()). Does NOT change external interface or restart characteristics. Fills the tp_iter and tp_iternext slots to provide faster looping than access via sq_item wrapped by an iterobject. Times about 25% faster than the original. Brings the performance to within 5 to 7% of range(). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 10:49 Message: Logged In: YES user_id=21627 Thanks for the patch; applied as rangeobject.c 2.36. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 21:11 Message: Logged In: YES user_id=80475 Attached revised patch with var definition in a comment. Altered __getiter to set to one to keep consistent with definition. This improves the routine slightly by preventing an anomaly with an obscure series of calls: x=xrange(3); a=iter(x); b=iter(x); c=iter(b); b.next(); print c.next, "this should be zero but isn't" The revised patch handles the above sequence correctly. The purpose of having the "used" field is to allow re-use of the same object in the following context: x = xrange(10) for i in range(1000): for j in x: # the same xrange object gets re-used. print i,j ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-05 19:30 Message: Logged In: YES user_id=21627 One more question: what is the exact meaning of the "used" field? More specifically, why does it set used to 0 when creating a new range object in _getiter? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-05 05:47 Message: Logged In: YES user_id=80475 Done. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-04 15:31 Message: Logged In: YES user_id=21627 As currently implemented, there is an API change: iter(xrange(10)) does not have a .next method anymore. When revising the patch, please eliminate the extra 0, before the new tp_ entries. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-04 03:08 Message: Logged In: YES user_id=80475 Yes. See new patch from current CVS rangeobject.c 2.35. Timings still show 25% improvement coming to within 6% of range(). Passes \lib\test\test_builtin.py. External interface unchanged, so docs left unchanged. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-02 22:18 Message: Logged In: YES user_id=21627 Can you please update this patch to the current CVS (rangeobject.c 2.35)? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551410&group_id=5470 From noreply@sourceforge.net Wed May 8 09:52:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 01:52:02 -0700 Subject: [Patches] [ python-Patches-553403 ] configure.in INSTSONAME typo patch Message-ID: Patches item #553403, was opened at 2002-05-07 21:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553403&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: configure.in INSTSONAME typo patch Initial Comment: This patch fixes a minor typo in configure.in. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 10:52 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as configure.in 1.315, configure 1.305. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553403&group_id=5470 From noreply@sourceforge.net Wed May 8 09:57:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 01:57:52 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 16:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 10:57 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as ftplib.py 1.67, ACKS 1.172. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 10:26 Message: Logged In: YES user_id=80475 That was quick! You have my sign-off. Will recommend to a developer for a commit. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2002-05-08 10:02 Message: Logged In: YES user_id=537938 Hi! Thanks for your comments. I uploaded a new version of the patch, relative to version 1.66 of ftplib.py, that uses the callable(callback) variant. I tested the patch and verified that it works as expected. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:14 Message: Logged In: YES user_id=80475 One other thought. Consider changing the line to: if not callable(callback): callback = print_line This would eliminate the code breakage I outlined in the previous comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Wed May 8 10:00:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 02:00:26 -0700 Subject: [Patches] [ python-Patches-553230 ] altbininstall patch Message-ID: Patches item #553230, was opened at 2002-05-07 14:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553230&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: altbininstall patch Initial Comment: This patch resolves the following make install error by creating $(LIBDIR): Creating directory /tmp/python-shared/usr/bin /usr/bin/install -c python /tmp/python-shared/usr/bin/python2.3 if test -f libpython2.3.so; then \ /usr/bin/install -c -m 555 libpython2.3.so /tmp/python-shared/usr/lib/libpython2.3.so.1.0; \ else true; \ fi /usr/bin/install: cannot create regular file `/tmp/python-shared/usr/lib/libpython2.3.so.1.0': No such file or directory make: *** [altbininstall] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 11:00 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as Makefile.pre.in 1.83. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553230&group_id=5470 From noreply@sourceforge.net Wed May 8 10:01:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 02:01:23 -0700 Subject: [Patches] [ python-Patches-553108 ] Deprecate bsddb Message-ID: Patches item #553108, was opened at 2002-05-07 05:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Nobody/Anonymous (nobody) Summary: Deprecate bsddb Initial Comment: Large numbers of inserts break bsddb, as first discovered in Python 1.5 (bug 408271). According to Barry Warsaw, "trying to get the bsddb module that comes with Python to work is a hopeless cause." If it's broken, let's discourage people from using it. In particular, let's ensure that people importing shelve or anydbm don't end up using it by default. The submitted patch adds a DeprecationWarning to the bsddb module and removes bsddb from the list of db module candidates in anydbm. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 11:01 Message: Logged In: YES user_id=21627 I'm in favour of this change, but I'd like simultaneously incorporate bsddb3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 From noreply@sourceforge.net Wed May 8 10:17:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 02:17:12 -0700 Subject: [Patches] [ python-Patches-552812 ] Better description in "python -h" for -u Message-ID: Patches item #552812, was opened at 2002-05-06 11:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552812&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) >Summary: Better description in "python -h" for -u Initial Comment: A new user was confused by the fact that "python -u" in combination with "sys.stdin.xreadlines()" was not doing what he expects. I believe that this modification makes it a bit more clear that there is internal buffering which "-u" does not influence. Also included is a man-page modification of similar nature (though more detailed). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 11:17 Message: Logged In: YES user_id=21627 I dislike the change to add many new lines to the -h output. Can you squeeze this into one less line, e.g. by referring to the documentation? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552812&group_id=5470 From noreply@sourceforge.net Wed May 8 10:17:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 02:17:49 -0700 Subject: [Patches] [ python-Patches-552810 ] Better description in "python -h" for -u Message-ID: Patches item #552810, was opened at 2002-05-06 11:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552810&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) >Summary: Better description in "python -h" for -u Initial Comment: A new user was confused by the fact that "python -u" in combination with "sys.stdin.xreadlines()" was not doing what he expects. I believe that this modification makes it a bit more clear that there is internal buffering which "-u" does not influence. Also included is a man-page modification of similar nature (though more detailed). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 11:17 Message: Logged In: YES user_id=21627 Duplicate of 552812. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552810&group_id=5470 From noreply@sourceforge.net Wed May 8 11:26:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 03:26:24 -0700 Subject: [Patches] [ python-Patches-552812 ] Better description in "python -h" for -u Message-ID: Patches item #552812, was opened at 2002-05-06 09:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552812&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) >Summary: Better description in "python -h" for -u Initial Comment: A new user was confused by the fact that "python -u" in combination with "sys.stdin.xreadlines()" was not doing what he expects. I believe that this modification makes it a bit more clear that there is internal buffering which "-u" does not influence. Also included is a man-page modification of similar nature (though more detailed). ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2002-05-08 10:26 Message: Logged In: YES user_id=81797 Ok, I've converted it to a single line note referencing the man-page. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 09:17 Message: Logged In: YES user_id=21627 I dislike the change to add many new lines to the -h output. Can you squeeze this into one less line, e.g. by referring to the documentation? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552812&group_id=5470 From noreply@sourceforge.net Wed May 8 12:30:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 04:30:16 -0700 Subject: [Patches] [ python-Patches-553678 ] Cygwin Makefile.pre.in vestige patch Message-ID: Patches item #553678, was opened at 2002-05-08 03:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553678&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin Makefile.pre.in vestige patch Initial Comment: This patch removes a vestige part of the Cygwin make rules that didn't quite make it over during the flattening of the Makefiles. In its current form, it creates a def file but incorrectly calls it libpython$(VERSION).dll.a which immediately gets overwritten by the next command. Obviously, this is useless. It appears, it was useless in the old nested Makefile structure too. :,) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553678&group_id=5470 From noreply@sourceforge.net Wed May 8 13:44:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 05:44:36 -0700 Subject: [Patches] [ python-Patches-553702 ] Cygwin make install patch Message-ID: Patches item #553702, was opened at 2002-05-08 04:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553702&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin make install patch Initial Comment: This patch fixes make install for Cygwin. Specifically, it reverts to the previous behavior: o install libpython$(VERSION)$(SO) in $(BINDIR) o install $(LDLIBRARY) in $(LIBPL) It also begins to remove Cygwin's dependency on $(DLLLIBRARY) which I hope to take advantage of when I attempt to make Cygwin as similar as possible to the other Unix platforms (in other patches). I tested this patch under Red Hat Linux 7.1 without any ill effects. BTW, I'm not the happiest using the following test for Cygwin: test "$(SO)" = .dll I'm willing to update the patch to use: case "$(MACHDEP)" in cygwin* instead, but IMO that will look uglier. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553702&group_id=5470 From noreply@sourceforge.net Wed May 8 14:20:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 06:20:57 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 10:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Closed Resolution: Accepted Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-08 09:20 Message: Logged In: YES user_id=6380 I think the "if callable():" test is wrong. Now if someone passes an unusable callback it will be ignored rather than raising an exception. I don't find that an improvement (the bug in the code will go undetected longer). I don't think that that the worry about people passing some other form of "false" is warranted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 04:57 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as ftplib.py 1.67, ACKS 1.172. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 04:26 Message: Logged In: YES user_id=80475 That was quick! You have my sign-off. Will recommend to a developer for a commit. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2002-05-08 04:02 Message: Logged In: YES user_id=537938 Hi! Thanks for your comments. I uploaded a new version of the patch, relative to version 1.66 of ftplib.py, that uses the callable(callback) variant. I tested the patch and verified that it works as expected. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 01:14 Message: Logged In: YES user_id=80475 One other thought. Consider changing the line to: if not callable(callback): callback = print_line This would eliminate the code breakage I outlined in the previous comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 01:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Wed May 8 14:49:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 06:49:12 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 16:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Open Resolution: Accepted Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 15:49 Message: Logged In: YES user_id=21627 How about we go back to the original patch, testing for None explicitly? I understand that the problem of a "false" value being ignored was real - Geert, can you confirm? I'd rather accept that calling an uncallable false value would now cause an exception; if there is concern that this may break code, that could be mentioned in Misc/NEWS. Anyway, reopening. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-08 15:20 Message: Logged In: YES user_id=6380 I think the "if callable():" test is wrong. Now if someone passes an unusable callback it will be ignored rather than raising an exception. I don't find that an improvement (the bug in the code will go undetected longer). I don't think that that the worry about people passing some other form of "false" is warranted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 10:57 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as ftplib.py 1.67, ACKS 1.172. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 10:26 Message: Logged In: YES user_id=80475 That was quick! You have my sign-off. Will recommend to a developer for a commit. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2002-05-08 10:02 Message: Logged In: YES user_id=537938 Hi! Thanks for your comments. I uploaded a new version of the patch, relative to version 1.66 of ftplib.py, that uses the callable(callback) variant. I tested the patch and verified that it works as expected. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:14 Message: Logged In: YES user_id=80475 One other thought. Consider changing the line to: if not callable(callback): callback = print_line This would eliminate the code breakage I outlined in the previous comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Wed May 8 14:55:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 06:55:18 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 10:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: Accepted Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-08 09:55 Message: Logged In: YES user_id=6380 Yes, the "false" test was wrong. This is something to watch out for in the standard library: testing for "false" where a test for None is used. This bit us in an internal coding project a few times too, where a database object could be false if the database was empty. "is None" should always be used when a test for "object or None" is required. Let's go back to the original patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 09:49 Message: Logged In: YES user_id=21627 How about we go back to the original patch, testing for None explicitly? I understand that the problem of a "false" value being ignored was real - Geert, can you confirm? I'd rather accept that calling an uncallable false value would now cause an exception; if there is concern that this may break code, that could be mentioned in Misc/NEWS. Anyway, reopening. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-08 09:20 Message: Logged In: YES user_id=6380 I think the "if callable():" test is wrong. Now if someone passes an unusable callback it will be ignored rather than raising an exception. I don't find that an improvement (the bug in the code will go undetected longer). I don't think that that the worry about people passing some other form of "false" is warranted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 04:57 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as ftplib.py 1.67, ACKS 1.172. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 04:26 Message: Logged In: YES user_id=80475 That was quick! You have my sign-off. Will recommend to a developer for a commit. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2002-05-08 04:02 Message: Logged In: YES user_id=537938 Hi! Thanks for your comments. I uploaded a new version of the patch, relative to version 1.66 of ftplib.py, that uses the callable(callback) variant. I tested the patch and verified that it works as expected. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 01:14 Message: Logged In: YES user_id=80475 One other thought. Consider changing the line to: if not callable(callback): callback = print_line This would eliminate the code breakage I outlined in the previous comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 01:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Wed May 8 15:07:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 07:07:14 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 16:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: Accepted Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- >Comment By: Geert Jansen (geertj) Date: 2002-05-08 16:07 Message: Logged In: YES user_id=537938 I can confirm that the too-broad false test was a real world problem. I use a callable container class as a callback to retrlines. The container adds a directory entry to itself when called. Initially, the container is empty, so the "if not calllable:" test was true. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-08 15:55 Message: Logged In: YES user_id=6380 Yes, the "false" test was wrong. This is something to watch out for in the standard library: testing for "false" where a test for None is used. This bit us in an internal coding project a few times too, where a database object could be false if the database was empty. "is None" should always be used when a test for "object or None" is required. Let's go back to the original patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 15:49 Message: Logged In: YES user_id=21627 How about we go back to the original patch, testing for None explicitly? I understand that the problem of a "false" value being ignored was real - Geert, can you confirm? I'd rather accept that calling an uncallable false value would now cause an exception; if there is concern that this may break code, that could be mentioned in Misc/NEWS. Anyway, reopening. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-08 15:20 Message: Logged In: YES user_id=6380 I think the "if callable():" test is wrong. Now if someone passes an unusable callback it will be ignored rather than raising an exception. I don't find that an improvement (the bug in the code will go undetected longer). I don't think that that the worry about people passing some other form of "false" is warranted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 10:57 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as ftplib.py 1.67, ACKS 1.172. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 10:26 Message: Logged In: YES user_id=80475 That was quick! You have my sign-off. Will recommend to a developer for a commit. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2002-05-08 10:02 Message: Logged In: YES user_id=537938 Hi! Thanks for your comments. I uploaded a new version of the patch, relative to version 1.66 of ftplib.py, that uses the callable(callback) variant. I tested the patch and verified that it works as expected. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:14 Message: Logged In: YES user_id=80475 One other thought. Consider changing the line to: if not callable(callback): callback = print_line This would eliminate the code breakage I outlined in the previous comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 07:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Wed May 8 19:32:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 11:32:30 -0700 Subject: [Patches] [ python-Patches-550732 ] PyArg_VaParseTupleAndKeywords Message-ID: Patches item #550732, was opened at 2002-04-30 10:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550732&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyArg_VaParseTupleAndKeywords Initial Comment: I need a Va version of PyArg_ParseTupleAndKeywords for some generic code where the number of expected arguments isn't known until runtime. Attached is a patch which adds a PyArg_VaParseTupleAndKeywords to getargs.c. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2002-05-08 10:32 Message: Logged In: YES user_id=86307 I'm attaching a very minimal (possibly inadequate) doc patch for api/utilities.tex. I was going to model it after the documentation for PyArg_VaParse, but that doesn't exist, so I've provided some documentation for both PyArg_VaParse and PyArg_VaParseTupleAndKeywords. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 04:37 Message: Logged In: YES user_id=6380 Looks like a good idea to me. Needs a small API doc patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550732&group_id=5470 From noreply@sourceforge.net Wed May 8 19:36:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 11:36:52 -0700 Subject: [Patches] [ python-Patches-550732 ] PyArg_VaParseTupleAndKeywords Message-ID: Patches item #550732, was opened at 2002-04-30 10:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550732&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: PyArg_VaParseTupleAndKeywords Initial Comment: I need a Va version of PyArg_ParseTupleAndKeywords for some generic code where the number of expected arguments isn't known until runtime. Attached is a patch which adds a PyArg_VaParseTupleAndKeywords to getargs.c. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2002-05-08 10:36 Message: Logged In: YES user_id=86307 I probably should have added that the patch is against the current CVS version of utilities.tex (1.4). I saved it from my web browser, so it has today's date rather than the date in the CVS. ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2002-05-08 10:32 Message: Logged In: YES user_id=86307 I'm attaching a very minimal (possibly inadequate) doc patch for api/utilities.tex. I was going to model it after the documentation for PyArg_VaParse, but that doesn't exist, so I've provided some documentation for both PyArg_VaParse and PyArg_VaParseTupleAndKeywords. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 04:37 Message: Logged In: YES user_id=6380 Looks like a good idea to me. Needs a small API doc patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550732&group_id=5470 From noreply@sourceforge.net Thu May 9 04:13:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 08 May 2002 20:13:11 -0700 Subject: [Patches] [ python-Patches-553108 ] Deprecate bsddb Message-ID: Patches item #553108, was opened at 2002-05-07 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 >Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Nobody/Anonymous (nobody) Summary: Deprecate bsddb Initial Comment: Large numbers of inserts break bsddb, as first discovered in Python 1.5 (bug 408271). According to Barry Warsaw, "trying to get the bsddb module that comes with Python to work is a hopeless cause." If it's broken, let's discourage people from using it. In particular, let's ensure that people importing shelve or anydbm don't end up using it by default. The submitted patch adds a DeprecationWarning to the bsddb module and removes bsddb from the list of db module candidates in anydbm. ---------------------------------------------------------------------- >Comment By: Garth T Kidd (gtk) Date: 2002-05-09 13:12 Message: Logged In: YES user_id=59803 Let's not turn a simple patch into something requiring a PEP, compulsory thrashing on comp.lang.python, SleepyCat being willing to change their distribution model, lawyers (to make sure the licences are compatible), and so on. I'd hate it if other people spent the kind of time I did trying to get shelve to work only to find that a known- broken bsddb was causing all the problems, and that a patch was there to gently guide them to gdbm, but it got jammed because of scope-creep. Let's get this one, very simple and necessary (bsddb IS broken) change out of the way, and THEN start negotiating, thrashing, and integrating. :) I firmly believe bsddb3 should be one of the included batteries. Let's do it, but let's guide people away from broken code first. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 19:01 Message: Logged In: YES user_id=21627 I'm in favour of this change, but I'd like simultaneously incorporate bsddb3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 From noreply@sourceforge.net Thu May 9 14:42:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 May 2002 06:42:54 -0700 Subject: [Patches] [ python-Patches-534304 ] PEP 263 Implementation Message-ID: Patches item #534304, was opened at 2002-03-24 14:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=534304&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: SUZUKI Hisao (suzuki_hisao) Assigned to: Nobody/Anonymous (nobody) >Summary: PEP 263 Implementation Initial Comment: This is a sample implementation of PEP 263 phase 2. This implementation behaves just as normal Python does if no other coding hints are given. Thus it does not hurt anyone who uses Python now. Note that it is strictly compatible with the PEP in that every program valid in the PEP is also valid in this implementation. This implementation also accepts files in UTF-16 with BOM. They are read as UTF-8 internally. Please try "utf16sample.py" included. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-09 15:42 Message: Logged In: YES user_id=21627 I have now updated this patch to the current CVS, and to be a complete PEP 263 implementation; it will issue warnings when it finds non-ASCII characters but no encoding declaration. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-26 21:41 Message: Logged In: YES user_id=21627 I've updated the PEP to describe how this approach should be used: Python 2.3 still should generate warnings only for using non-ASCII without declared encoding. I, too, hope that Mr Suzuki will update the patch to match the PEP, and for the CVS tree. As for supporting UTF-16: The stream reader currently has the .readline method disabled, since it won't work reliable for little-endian. So I think this should be an undocumented feature at the moment; I see no other technical problems with the approach taken in the patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-23 23:26 Message: Logged In: YES user_id=6380 I haven't looked at this very carefully, but it looks like it's well thought-out. Suzuki, can you prepare a patch relative to current CVS? I get several patch failures now. (Fortunately I have a checkout of 2.2 so I can still review and test the patch.) I don't know what the patch failures are about (haven't investigated) but imagine it might have to do with the PEP 279 (universal newlines) changes checked in by Jack Jansen, which replaces the tokenizer's fgets() calls with calls to Py_UniversalNewlineFgets(). Also, I can't read the README file (it's in Japanese :-). What is the expected output from the samples? For me, sjis_sample.py gives SyntaxError: 'unknown encoding' Martin, I'm unclear of how you intend to use this code. Do you intend to go straight to phase 2 of the PEP using this patch? Or do you intend to implement phase 1 of the PEP by modifying this code? Also, does the PEP describe the UTF-16 support as implemented by Suziki's patch? ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2002-03-31 18:16 Message: Logged In: YES user_id=495142 Thank you for your review. Now 1. and 3. are fixed, and 2. is improved. (4. is not true.) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-30 12:27 Message: Logged In: YES user_id=6656 Not going into 2.2.x. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-25 14:23 Message: Logged In: YES user_id=21627 The patch looks good, but needs a number of improvements. 1. I have problems building this code. When trying to build pgen, I get an error message of Parser/parsetok.c: In function `parsetok': Parser/parsetok.c:175: `encoding_decl' undeclared The problem here is that graminit.h hasn't been built yet, but parsetok refers to the symbol. 2. For some reason, error printing for incorrect encodings does not work - it appears that it prints the wrong line in the traceback. 3. The escape processing in Unicode literals is incorrect. For example, u"\" should denote only the non-ascii character. However, your implementation replaces the non-ASCII character with \u, resulting in \u, so the first backslash unescapes the second one. 4. I believe the escape processing in byte strings is also incorrect for encodings that allow \ in the second byte. Before processing escape characters, you convert back into the source encoding. If this produces a backslash character, escape processing will misinterpret that byte as an escape character. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=534304&group_id=5470 From noreply@sourceforge.net Thu May 9 15:14:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 May 2002 07:14:42 -0700 Subject: [Patches] [ python-Patches-549187 ] error about string formatting rewording? Message-ID: Patches item #549187, was opened at 2002-04-26 19:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: error about string formatting rewording? Initial Comment: The error message that occurs during string formatting, when one passes more arguments than necessary, is this: TypeError: not all arguments converted It might be good to mention that this conversion is taking place as a result of string formatting. My suggestions is to add a little more to this message: TypeError: not all arguments converted during string formatting The reason is because string formatting uses the same operation as the modulus command, and also can take in a single integer argument, like: ziffer = note % 10 Newcomers to the language often mix up string and numbers, and the error message above can be very cryptic if one doesn't know about string formatting yet. With the reworded error message, there's less of chance of confusion. See: http://mail.python.org/pipermail/tutor/2002-April/014110.html for more details on why this might be nice. Thanks! ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2002-04-28 05:39 Message: Logged In: YES user_id=49843 Ok, I wrote up a patch to add more to the error message. Here's what it does: >>> def isEven(n): return n % 2 == 0 ... >>> isEven(17) False >>> isEven("17") Traceback (most recent call last): File "", line 1, in ? File "", line 1, in isEven TypeError: not all arguments converted during string formatting ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 From noreply@sourceforge.net Thu May 9 18:31:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 May 2002 10:31:39 -0700 Subject: [Patches] [ python-Patches-554192 ] mimetypes: all extensions for a type Message-ID: Patches item #554192, was opened at 2002-05-09 19:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554192&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: mimetypes: all extensions for a type Initial Comment: This patch adds a function guess_all_extensions to mimetypes.py. This function returns all known extensions for a given type, not just the first one found in the types_map dictionary. guess_extension is still present and returns the first from the list. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554192&group_id=5470 From noreply@sourceforge.net Thu May 9 18:49:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 May 2002 10:49:05 -0700 Subject: [Patches] [ python-Patches-552468 ] Correct ref manual error for list type Message-ID: Patches item #552468, was opened at 2002-05-05 04:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552468&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 6 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Correct ref manual error for list type Initial Comment: Closes SF bug www.python.org/sf/548874 Docs had old information that the list object did not support a .__getitem__ method. With the new style classes, they do: >>> x = list('abc') >>> x.__getitem__(1) 'b' Deleted erroneous sentence. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-09 13:49 Message: Logged In: YES user_id=3066 Looks good -- check it in & close the patch & related bug report. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552468&group_id=5470 From noreply@sourceforge.net Thu May 9 19:43:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 May 2002 11:43:07 -0700 Subject: [Patches] [ python-Patches-553171 ] optionally make shelve less surprising Message-ID: Patches item #553171, was opened at 2002-05-07 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: optionally make shelve less surprising Initial Comment: shelve has highly surprising behavior wrt modifiable values: s = shelve.open('she.dat','c') s['ciao'] = range(3) s['ciao'].append(4) # doesn't "TAKE"! Explaining to beginners that s['ciao'] is returning a temporary object and the modification is done on the temporary thus "silently ignored" is hard indeed. It also makes shelve far less convenient than it could be (whenever modifiable values must be shelved). Having s keep track of all values it has returned may perhaps break some existing program (due to extra memory consumption and/or to lack of "implicit copy"/"snapshot" behavior) so I've made the 'caching' change optional and by default off. However it's now at least possible to obtain nonsurprising behavior: s = shelve.open('she.dat','c',smart=1) s['ciao'] = range(3) s['ciao'].append(4) # no surprises any more I suspect the 'smart=1' should be made the default, but, if we at least put it in now, then perhaps we can migrate to having it as the default very slowly and gradually. Alex ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 18:43 Message: Logged In: YES user_id=80475 Nicely done! The code is clean and runs in the smart mode without problems on my existing programs. I agree that the patch solves a real world problem. The solution is clean, but a little expensive. If there were a way to be able to tell if an entry had been altered, it would save the 100% writeback. Unfortunately, I can't think of a way. The docstring could read more smoothly and plainly. Also, it should be clear that the cost of setting smart=1 is that 100% of the entries get rewritten on close. Two microscopically minor thoughts on the coding (feel free to disregard). Can some of the try/except blocks be replaced by something akin to 'if self.smart:'? For the writeback loop, consider 'for k,v in cache.iteritems()' as it takes less memory and saves a lookup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 16:38 Message: Logged In: YES user_id=21627 Even more important than the backwards compatibility might be the issue that it writes back all accessed objects on close, which might be expensive if there have been many read-only accesses. So I think the option name could be also 'slow'; although 'writeback' might be more technical. Also, I wonder whether write-back should be attempted if the shelve was opened read-only. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 From noreply@sourceforge.net Thu May 9 21:55:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 May 2002 13:55:16 -0700 Subject: [Patches] [ python-Patches-553171 ] optionally make shelve less surprising Message-ID: Patches item #553171, was opened at 2002-05-07 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: optionally make shelve less surprising Initial Comment: shelve has highly surprising behavior wrt modifiable values: s = shelve.open('she.dat','c') s['ciao'] = range(3) s['ciao'].append(4) # doesn't "TAKE"! Explaining to beginners that s['ciao'] is returning a temporary object and the modification is done on the temporary thus "silently ignored" is hard indeed. It also makes shelve far less convenient than it could be (whenever modifiable values must be shelved). Having s keep track of all values it has returned may perhaps break some existing program (due to extra memory consumption and/or to lack of "implicit copy"/"snapshot" behavior) so I've made the 'caching' change optional and by default off. However it's now at least possible to obtain nonsurprising behavior: s = shelve.open('she.dat','c',smart=1) s['ciao'] = range(3) s['ciao'].append(4) # no surprises any more I suspect the 'smart=1' should be made the default, but, if we at least put it in now, then perhaps we can migrate to having it as the default very slowly and gradually. Alex ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 20:55 Message: Logged In: YES user_id=80475 A few more thoughts: Please change the "except:" lines to specify the exception being caught. Also, if GvR shows interest in the patch, we should update the library reference and add unittests. The docstring should also mention that the cache is kept in memory -- besides persistence, one of the forces for shelving is memory conservation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 18:43 Message: Logged In: YES user_id=80475 Nicely done! The code is clean and runs in the smart mode without problems on my existing programs. I agree that the patch solves a real world problem. The solution is clean, but a little expensive. If there were a way to be able to tell if an entry had been altered, it would save the 100% writeback. Unfortunately, I can't think of a way. The docstring could read more smoothly and plainly. Also, it should be clear that the cost of setting smart=1 is that 100% of the entries get rewritten on close. Two microscopically minor thoughts on the coding (feel free to disregard). Can some of the try/except blocks be replaced by something akin to 'if self.smart:'? For the writeback loop, consider 'for k,v in cache.iteritems()' as it takes less memory and saves a lookup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 16:38 Message: Logged In: YES user_id=21627 Even more important than the backwards compatibility might be the issue that it writes back all accessed objects on close, which might be expensive if there have been many read-only accesses. So I think the option name could be also 'slow'; although 'writeback' might be more technical. Also, I wonder whether write-back should be attempted if the shelve was opened read-only. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 From noreply@sourceforge.net Fri May 10 01:47:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 09 May 2002 17:47:40 -0700 Subject: [Patches] [ python-Patches-553171 ] optionally make shelve less surprising Message-ID: Patches item #553171, was opened at 2002-05-07 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: optionally make shelve less surprising Initial Comment: shelve has highly surprising behavior wrt modifiable values: s = shelve.open('she.dat','c') s['ciao'] = range(3) s['ciao'].append(4) # doesn't "TAKE"! Explaining to beginners that s['ciao'] is returning a temporary object and the modification is done on the temporary thus "silently ignored" is hard indeed. It also makes shelve far less convenient than it could be (whenever modifiable values must be shelved). Having s keep track of all values it has returned may perhaps break some existing program (due to extra memory consumption and/or to lack of "implicit copy"/"snapshot" behavior) so I've made the 'caching' change optional and by default off. However it's now at least possible to obtain nonsurprising behavior: s = shelve.open('she.dat','c',smart=1) s['ciao'] = range(3) s['ciao'].append(4) # no surprises any more I suspect the 'smart=1' should be made the default, but, if we at least put it in now, then perhaps we can migrate to having it as the default very slowly and gradually. Alex ---------------------------------------------------------------------- Comment By: H.P.K. (dannu) Date: 2002-05-10 00:47 Message: Logged In: YES user_id=83092 I'd suggest not changing shelve at all but providing a "cache-commit" dictionary (ccdict) which can wrap a shelf-instance (or any other simple dictish instance) and provides the 'non-surprising' behaviour. Some proof of concept code for the following properties is provided here http://home.trillke.net/~hpk/ccdict.py Current properties are: - ccdict wraps a dictionary-like object which in turn only needs to provide __getitem__, __setitem__, __delitem__,has_key - on first access of an element ccdict makes a lookup on the underlying dict and caches the item. - the next accesses work with the cached thing. Unsurprising dict-semantics are provided. - deleting an item is deferred and actually happens on commit() time. deleting an item and later on assigning to it works as expected (i.e. the assignment takes preference). - commit() transfers the items in the cache to the underlying dict and clears the cache.Prior to issuing commit no writeback to the underlying dict happens. - deleting an ccdict-instance does *not* commit any changes. You have to explicitely call commit(). If you want to work readonly, don't call commit. - clear() only cleares the cache and not the underlying dict - you can explicitely prune the cache (via cache.keys() etc.) before calling commit(). This lets you avoid writing back unmodified objects if this is an issue. It seems quite impossible to figure out automagically which objects have been modified and so the solution is to do it explicitely (or don't commit for readonly). holger ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 20:55 Message: Logged In: YES user_id=80475 A few more thoughts: Please change the "except:" lines to specify the exception being caught. Also, if GvR shows interest in the patch, we should update the library reference and add unittests. The docstring should also mention that the cache is kept in memory -- besides persistence, one of the forces for shelving is memory conservation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-09 18:43 Message: Logged In: YES user_id=80475 Nicely done! The code is clean and runs in the smart mode without problems on my existing programs. I agree that the patch solves a real world problem. The solution is clean, but a little expensive. If there were a way to be able to tell if an entry had been altered, it would save the 100% writeback. Unfortunately, I can't think of a way. The docstring could read more smoothly and plainly. Also, it should be clear that the cost of setting smart=1 is that 100% of the entries get rewritten on close. Two microscopically minor thoughts on the coding (feel free to disregard). Can some of the try/except blocks be replaced by something akin to 'if self.smart:'? For the writeback loop, consider 'for k,v in cache.iteritems()' as it takes less memory and saves a lookup. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 16:38 Message: Logged In: YES user_id=21627 Even more important than the backwards compatibility might be the issue that it writes back all accessed objects on close, which might be expensive if there have been many read-only accesses. So I think the option name could be also 'slow'; although 'writeback' might be more technical. Also, I wonder whether write-back should be attempted if the shelve was opened read-only. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553171&group_id=5470 From noreply@sourceforge.net Sat May 11 01:08:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 May 2002 17:08:35 -0700 Subject: [Patches] [ python-Patches-554716 ] __va_copy patches Message-ID: Patches item #554716, was opened at 2002-05-10 20:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554716&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: __va_copy patches Initial Comment: This issue was discovered when preparing for OpenBSD 3.1, and compiling on our non-i386 arches. Let me quote a mail from drahn@openbsd.org: > [Tell the Python guys] the vararg handling is poor, and that this is possible solution, but not a great solution. If possible It would be best to not parse the varargs argument twice. > Different architectures deal with varargs differently, __va_copy is a way that some architectures use do a deep copy. __va_copy is present in solaris and powerpc (*BSD and Linux) as far as I know. Attached is the patches we are using to build our Python package; without it we cannot build Python 2.2 on arches like powerpc as the built python cores. Python 2.1 does not need these patches. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554716&group_id=5470 From noreply@sourceforge.net Sat May 11 01:20:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 May 2002 17:20:16 -0700 Subject: [Patches] [ python-Patches-554718 ] OpenBSD fixes for Python 2.1 Message-ID: Patches item #554718, was opened at 2002-05-10 20:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD fixes for Python 2.1 Initial Comment: The following patches are currently in our packaging system. A brief summary: - Use 'cc -shared' to build shared libraries, as is strictly correct on OpenBSD. - Use -fPIC instead of -fpic. - Use OpenBSD threads. - Fix the test_fcntl test. Another patch item will be posted shortly for Python 2.2, for similar items. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 From noreply@sourceforge.net Sat May 11 01:23:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 10 May 2002 17:23:20 -0700 Subject: [Patches] [ python-Patches-554719 ] OpenBSD fixes for Python 2.2 Message-ID: Patches item #554719, was opened at 2002-05-10 20:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554719&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD fixes for Python 2.2 Initial Comment: The following patches are in our packaging tree. A brief summary: - Use 'cc -shared' to build shared libs, as is strictly correct on OpenBSD. - Use OpenBSD threads. - Fix the test_fcntl test. CVS HEAD patches are forthcoming. I am currently working on the shared libpython stuff etc. I also posted separate patches for Python 2.1 already. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554719&group_id=5470 From noreply@sourceforge.net Sat May 11 13:01:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 11 May 2002 05:01:41 -0700 Subject: [Patches] [ python-Patches-554807 ] Add _winreg support for Cygwin Message-ID: Patches item #554807, was opened at 2002-05-11 12:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add _winreg support for Cygwin Initial Comment: This adds _winreg support to Cygwin Python without dependencies on other Windows modules. For platforms in which MS_WINDOWS isn't defined, this reports the OSError exception instead of WindowsErr. It also uses the non-MBCS versions of registry access in this case. Some minor changes to _winreg.c were made to clean up compiler warnings from GCC. setup.py was changed to create a dynamic _winreg module under cygwin. There are also some earlier changes in the patch file to skip the import test (due to Cygwin fork issues), and to require libintl when building _locale under Cygwin. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 From noreply@sourceforge.net Sat May 11 14:32:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 11 May 2002 06:32:29 -0700 Subject: [Patches] [ python-Patches-554841 ] THREAD_STACK_SIZE for 2.1 Message-ID: Patches item #554841, was opened at 2002-05-11 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 Category: Core (C code) Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: THREAD_STACK_SIZE for 2.1 Initial Comment: I created this patch for OpenBSD packaging, so we could bump up the pthread stack size in the same way it is done for Python 2.2 -- by adding -DTHREAD_STACK_SIZE=0x20000 to OPT. (We need this so Zope doesn't crash with our shared libpython.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 From noreply@sourceforge.net Sun May 12 04:22:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 11 May 2002 20:22:01 -0700 Subject: [Patches] [ python-Patches-552468 ] Correct ref manual error for list type Message-ID: Patches item #552468, was opened at 2002-05-05 03:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552468&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Correct ref manual error for list type Initial Comment: Closes SF bug www.python.org/sf/548874 Docs had old information that the list object did not support a .__getitem__ method. With the new style classes, they do: >>> x = list('abc') >>> x.__getitem__(1) 'b' Deleted erroneous sentence. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-11 22:22 Message: Logged In: YES user_id=80475 Checked in as /Doc/ref/ref3.tex 1.88. Patch and bug closed. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-09 12:49 Message: Logged In: YES user_id=3066 Looks good -- check it in & close the patch & related bug report. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552468&group_id=5470 From noreply@sourceforge.net Sun May 12 04:42:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 11 May 2002 20:42:34 -0700 Subject: [Patches] [ python-Patches-549187 ] error about string formatting rewording? Message-ID: Patches item #549187, was opened at 2002-04-26 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 >Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) >Assigned to: Raymond Hettinger (rhettinger) Summary: error about string formatting rewording? Initial Comment: The error message that occurs during string formatting, when one passes more arguments than necessary, is this: TypeError: not all arguments converted It might be good to mention that this conversion is taking place as a result of string formatting. My suggestions is to add a little more to this message: TypeError: not all arguments converted during string formatting The reason is because string formatting uses the same operation as the modulus command, and also can take in a single integer argument, like: ziffer = note % 10 Newcomers to the language often mix up string and numbers, and the error message above can be very cryptic if one doesn't know about string formatting yet. With the reworded error message, there's less of chance of confusion. See: http://mail.python.org/pipermail/tutor/2002-April/014110.html for more details on why this might be nice. Thanks! ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2002-04-27 22:39 Message: Logged In: YES user_id=49843 Ok, I wrote up a patch to add more to the error message. Here's what it does: >>> def isEven(n): return n % 2 == 0 ... >>> isEven(17) False >>> isEven("17") Traceback (most recent call last): File "", line 1, in ? File "", line 1, in isEven TypeError: not all arguments converted during string formatting ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 From noreply@sourceforge.net Sun May 12 07:16:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 11 May 2002 23:16:48 -0700 Subject: [Patches] [ python-Patches-553277 ] Little ftplib bug Message-ID: Patches item #553277, was opened at 2002-05-07 09:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Little ftplib bug Initial Comment: There seem to be a little bug in FTP.retrlines in the module ftplib in the standard library. In this function, the default value for the "callback" parameter is None. The absence of a callback parameter is tested in the body if the function with "if not callback:". This gives problems in real-life when you're using a callable container class as the callback function. When the container is empty (__len__ returns 0), the test "if not callback:" is true and a default callback is used instead of the user supplied one. The fix is to change the test "if not callback" to "if callback is None:". One-line patch attached. Greetings, Geert Jansen ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-12 01:16 Message: Logged In: YES user_id=80475 Per GvR's note below, reverted to original patch. Tested without exception. Per MvL's comment, added item to Misc/NEWS. Committed as ftplib.py 1.68 and NEWS 1.406. Closing patch. Geert, thanks for submitting. Sorry for leading you off-track with callable(). ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2002-05-08 09:07 Message: Logged In: YES user_id=537938 I can confirm that the too-broad false test was a real world problem. I use a callable container class as a callback to retrlines. The container adds a directory entry to itself when called. Initially, the container is empty, so the "if not calllable:" test was true. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-08 08:55 Message: Logged In: YES user_id=6380 Yes, the "false" test was wrong. This is something to watch out for in the standard library: testing for "false" where a test for None is used. This bit us in an internal coding project a few times too, where a database object could be false if the database was empty. "is None" should always be used when a test for "object or None" is required. Let's go back to the original patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 08:49 Message: Logged In: YES user_id=21627 How about we go back to the original patch, testing for None explicitly? I understand that the problem of a "false" value being ignored was real - Geert, can you confirm? I'd rather accept that calling an uncallable false value would now cause an exception; if there is concern that this may break code, that could be mentioned in Misc/NEWS. Anyway, reopening. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-08 08:20 Message: Logged In: YES user_id=6380 I think the "if callable():" test is wrong. Now if someone passes an unusable callback it will be ignored rather than raising an exception. I don't find that an improvement (the bug in the code will go undetected longer). I don't think that that the worry about people passing some other form of "false" is warranted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 03:57 Message: Logged In: YES user_id=21627 Thanks for the patch; committed as ftplib.py 1.67, ACKS 1.172. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 03:26 Message: Logged In: YES user_id=80475 That was quick! You have my sign-off. Will recommend to a developer for a commit. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2002-05-08 03:02 Message: Logged In: YES user_id=537938 Hi! Thanks for your comments. I uploaded a new version of the patch, relative to version 1.66 of ftplib.py, that uses the callable(callback) variant. I tested the patch and verified that it works as expected. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 00:14 Message: Logged In: YES user_id=80475 One other thought. Consider changing the line to: if not callable(callback): callback = print_line This would eliminate the code breakage I outlined in the previous comment. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 00:01 Message: Logged In: YES user_id=80475 Please update the patch to diff from the current version of ftplib.py (revision 1.66). I agree that 'if callback is None' more accurately captures the intent of checking that a callback function was not specified. It is also stylistically consistent with the 'is None' test in the definition of the ntransfercmd function and in other None checks elsewhere in the module. Also, I cross-checked the docs and found no conflict. I tested retrlines with the patch in-place and found no ill- effects. The problem being solved is a bit obscure in that the callback would need to be a user class defining both __len__ and __call__. The only code breakage I could think of would be a case where someone relied on the existing implementation, though the documentation makes no promises, and had their calling code default to a callback value equivalent to False but not identical to None: def getfile(ftpobj, filename, callback=[]): 'This code works before the patch, but not after' ftpobj.retrlines('retr '+filename, callback) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553277&group_id=5470 From noreply@sourceforge.net Sun May 12 13:11:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 05:11:05 -0700 Subject: [Patches] [ python-Patches-555085 ] timeout socket implementation Message-ID: Patches item #555085, was opened at 2002-05-12 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555085&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Gilfix (mgilfix) Assigned to: Nobody/Anonymous (nobody) Summary: timeout socket implementation Initial Comment: This implements bug #457114 and implements timed socket operations. If a timeout is set and the timeout period elaspes before the socket operation has finished, a socket.error exception is thrown. This patch integrates the functionality at two levels: the timeout capability is integrated at the C level in socketmodule.c. Socket.py was also modified to update fileobject creation on a win platform to handle the case of the underlying socket throwing an exception. The tex documentation was also updated and a new regression unit was provided as test_timeout.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555085&group_id=5470 From noreply@sourceforge.net Sun May 12 17:40:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 09:40:06 -0700 Subject: [Patches] [ python-Patches-488073 ] AtheOS port of Python 2.2b2 Message-ID: Patches item #488073, was opened at 2001-12-02 14:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Octavian Cerna (tavyc) Assigned to: Martin v. Löwis (loewis) Summary: AtheOS port of Python 2.2b2 Initial Comment: Hi, While I was playing with AtheOS in the last few days, I saw that it comes with Python 1.5.2. Being a Python enthusiast, I tried to see if a recent version of Python would work. It did not even compile, so I decided to port it, knowing that AtheOS is almost POSIX-compatible. The result is a full-blown Python port with only a (relative) small amount of changes, that builds OOTB. And here it is, with all the details: About the patch: - The diff is against CVS 2001-11-26 - 20 files changed, 1962 insertions, 23 deletions - It does not include changes to autoconf-generated files - The patch includes a few very small fixes not directly related to the AtheOS port, but which were necessary to ensure the port works OK: - setup.py - look for the _curses_panel.c file in $srcdir/Modules, not in $PWD/Modules (otherwise VPATH builds will not build _curses_panel.so) - Makefile.pre.in - only ranlib *.a files (how will this affect other ports?) - Tools/freeze/bkfile.py - not all platforms have the file.truncate method - Tools/scripts/h2py.py - environment- paths code was made more portable Environment: - AtheOS 0.3.6 - gcc 2.95.2 - binutils 2.10 - glibc 2.1.2 Features: - Dynamic loading of modules - Native thread support Issues: Although AtheOS is not a BeOS clone, it is in many ways similar to BeOS, and some issues from BeOS also apply on AtheOS. - dlopen is not properly implemented, so I had to add support for native dynamic loading. - The POSIX threads emulation is almost inexistent, so I added support for native AtheOS threads. - AtheOS doesn't support importing symbols in a shared library from the main executable (the `-export-dynamic' linker flag), so the Python core must be built as a shared library, like on BeOS. - mmap is not implemented in AtheOS, the mmap module was disabled - statvfs is not implemented, os.statvfs and os.fstatvfs disabled - crypt on AtheOS crashes with SEGV if salt is not "$1$" (glibc bug?), disabled - poll - it seems that poll never returns POLLNVAL for an invalid fd (hangs), disabled - Don't mix threading with fork() -- see test_popen2 below. All tests pass, except: - test_nis hangs on my system, probably because NIS is not set up - test_popen2 hangs when imported from regrtest.py, otherwise working (like on BeOS). I suspect that the import semaphore is locked when popen2 forks and AtheOS doesn't like that. - test_mhlib fails, I don't know exactly why, but I suspect a filesystem issue (It corrupted some of my files several times, and I don't want to run it again ;) - test_locale skipped, locale en_US not supported (maybe something's wrong with my environment?) - test_largefile skipped (unless you tell it to eat 2GB disk space) because apparently afs doesn't support sparse files. Notes: - If you build Python, make sure you have shared versions of your libraries and you have links in /system/libs for them, otherwise the kernel won't load modules. AtheOS doesn't have a shared version for each library, I had serious problems with ncurses and the _curses_panel module. Binary packages: - I have prepared binary packages of Python-2.2b2 and Numeric-20.2.1 for testing, I will post them on kamidake.org later. Future: - I'm going to try Zope these days, I think it should work with a minimum amount of changes, almost OOTB ;) (Maybe I should have included this text in the README file?) Please excuse my bad English, I am not a native speaker :) Python is an excellent language/environment, keep going with the good work! -------- Best Regards, Octavian Cerna (Tavy) yLabs ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-12 18:40 Message: Logged In: YES user_id=21627 A few more questions: - Why is AF_UNIX undefined? I.e. what problems would arise if it was exported from the socket module? - Likewise, what problems arise if statvfs is exported from the Posix module? Sure, calling the function might always give an exception, but what is the problem with that? - Also, are you sure this is still an issue with the current autoconf? configure specifically checks for the __stub_ symbols defined in glibc for stub functions. - What problems arise if large file support is enabled? Does seek/tell not work at all, or does it just fail for large files? ---------------------------------------------------------------------- Comment By: Octavian Cerna (tavyc) Date: 2002-05-05 20:23 Message: Logged In: YES user_id=382173 Updated to CVS 2002-05-04. I disabled from setup.py the modules which don't make sense on AtheOS (nis for example). I still used the historic sys.platform[:n] in a few places in order to be consistent with the surrounding code. This time I was more careful with the code, and made more testing. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-20 19:12 Message: Logged In: YES user_id=21627 Can you please update the patch for the current CVS? A few comments: - the plat-*/FCNTL are not generated anymore, FCNTL is deprecated. - Why does test_nis need to skip explicitly on atheos? If the nis module builds, why does the test fail? - Please use the .startswith method over the (historic) [:n] form when testing sys.platform. - I don't understand the O_LARGEFILE chunk. What is the problem with just not defining O_LARGEFILE? ---------------------------------------------------------------------- Comment By: Octavian Cerna (tavyc) Date: 2001-12-02 19:40 Message: Logged In: YES user_id=382173 I know that Python is now in a "feature freeze" or something similar, but this patch could go in Python 2.3. I added the HAVE_GETADDRINFO to acconfig.h because it was simply missing and autoheader complained, (outdated CVS snapshot). I should have removed it from the patch. I posted it here just to make it available to anyone who wants to try it out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 16:42 Message: Logged In: YES user_id=21627 I'd advise not to add this port so shortly before 2.2, in particular since these changes need careful review. As an example: Why does it add HAVE_GETADDRINFO to acconfig.h? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 From noreply@sourceforge.net Sun May 12 17:49:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 09:49:20 -0700 Subject: [Patches] [ python-Patches-554718 ] OpenBSD fixes for Python 2.1 Message-ID: Patches item #554718, was opened at 2002-05-11 02:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD fixes for Python 2.1 Initial Comment: The following patches are currently in our packaging system. A brief summary: - Use 'cc -shared' to build shared libraries, as is strictly correct on OpenBSD. - Use -fPIC instead of -fpic. - Use OpenBSD threads. - Fix the test_fcntl test. Another patch item will be posted shortly for Python 2.2, for similar items. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-12 18:49 Message: Logged In: YES user_id=21627 The -shared chunk looks frightening. What is the first BSD release where ld -Bshareable stops working? Could you rearrange this to integrate the version numbers into the OpenBSD* match? Also, what releases need the ELF test? Could that be restricted to the older releases, too? Would it be acceptable to stop supporting OpenBSD 0 and 1? Is usage of -fPIC correct on OpenBSD 0.x? If not, what is the first release that supports -fPIC? It looks like that 'OpenBSD threads' are 'POSIX threads'? Why does the existing test for Posix threads fail to detect their presence? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 From noreply@sourceforge.net Sun May 12 17:51:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 09:51:15 -0700 Subject: [Patches] [ python-Patches-554719 ] OpenBSD fixes for Python 2.2 Message-ID: Patches item #554719, was opened at 2002-05-11 02:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554719&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD fixes for Python 2.2 Initial Comment: The following patches are in our packaging tree. A brief summary: - Use 'cc -shared' to build shared libs, as is strictly correct on OpenBSD. - Use OpenBSD threads. - Fix the test_fcntl test. CVS HEAD patches are forthcoming. I am currently working on the shared libpython stuff etc. I also posted separate patches for Python 2.1 already. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-12 18:51 Message: Logged In: YES user_id=21627 My comments for 554718 apply for this patch as well - I recommend that we actually first work on the 2.2 patch, and only then consider backporting it for 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554719&group_id=5470 From noreply@sourceforge.net Sun May 12 22:44:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 14:44:24 -0700 Subject: [Patches] [ python-Patches-473512 ] getopt with GNU style scanning Message-ID: Patches item #473512, was opened at 2001-10-21 23:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Postponed Priority: 5 Submitted By: Peter Åstrand (astrand) Assigned to: Nobody/Anonymous (nobody) Summary: getopt with GNU style scanning Initial Comment: Implements GNU style scanning mode. The traditional mode is used if the option string begins with + or if the environment variable POSIXLY_CORRECT is set, just like GNU getopt. Patch includes updated documentation and test. ---------------------------------------------------------------------- >Comment By: Peter Åstrand (astrand) Date: 2002-05-12 23:44 Message: Logged In: YES user_id=344921 New patch added, which hopefully fixes the identified problems. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:51 Message: Logged In: YES user_id=21627 If there is no update of this patch by June 1, it will be rejected. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-06 15:50 Message: Logged In: YES user_id=3066 The documentation needs to clearly describe the differences between GNU-style scanning and what's done in getopt.getopt() -- it seems to assume the reader knows the differences. The implementation of gnu_getopt() also assumes that args will be non-empty. If the caller wants only long options and passes '' as args, IndexError will be raised. Check for a leading '+' with args.startswith('+') to be safe. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-11-24 11:10 Message: Logged In: YES user_id=21627 The patch looks good to me. Since it introduces a new feature, it will be postponed after 2.2 (negotiate with the 2.2 release manager if you want to see it included). Notice that it doesn't offer all features of GNU getopt. It doesn't support the getopt_long_only mechanism (where all options are long, even if they have a single - only). Further, it doesn't allow the caller to specify ordering, and it doesn't support the RETURN_IN_ORDER option (which would be difficult to support with the current calling convention, though). I'm not asking that these problems are somehow resolved; they are meant as proposals for improvements only. ---------------------------------------------------------------------- Comment By: Peter Åstrand (astrand) Date: 2001-11-11 17:09 Message: Logged In: YES user_id=344921 The new patch uses a new function, gnu_getopt, instead of changing the default behaviour. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-22 02:37 Message: Logged In: YES user_id=6380 Rejected in this form. We can't suddenly change the default behavior. If you want a way to support GNU style options (which I personally hate, but which I would accept as an option), try adding a different function (e.g. gnu_getopt(...)) or add a flag argument (e.g. getopt(..., gnu=1)). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=473512&group_id=5470 From noreply@sourceforge.net Mon May 13 01:22:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 17:22:27 -0700 Subject: [Patches] [ python-Patches-555251 ] Mutable object change flag Message-ID: Patches item #555251, was opened at 2002-05-12 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555251&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Mutable object change flag Initial Comment: This patch is a proof-of-concept for marking state changes in mutable objects. It is meant as a simpler, faster alternative to a full built-in observer pattern. Here's the whole protocol: Mutable objects choosing to implement the protocol provide a writable attribute, cachevalid, which is initialized to zero. Upon any update to the object, the attribute is reset to zero. Callers who set the attribute to one can later check to see if an update has occurred (as indicated by a zero). >>> a = list('abcd') >>> a.cachevalid 0 >>> a.cachevalid=1 >>> a.cachevalid 1 >>> a[2] = 'k' >>> a.cachevalid 0 The proof-of-concept patch is implemented only for lists. A production version would need to include dictionaries. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555251&group_id=5470 From noreply@sourceforge.net Mon May 13 03:36:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 19:36:54 -0700 Subject: [Patches] [ python-Patches-552452 ] Add degrees() & radians() to math module Message-ID: Patches item #552452, was opened at 2002-05-05 03:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552452&group_id=5470 Category: Modules Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 3 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add degrees() & radians() to math module Initial Comment: Add functions to convert degrees and radians to the math module. Closes item #3 on feature request www.python.org/sf/426539 . The other two items have already been implemented. The two related entries in PEP 42 can be closed also. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-05-12 22:36 Message: Logged In: YES user_id=31435 Looks good to me, except that x * (1.0 / degToRad) introduces two rounding errors for no reason. Marked Accepted assuming this line gets changed to x / degToRad Note that this also needs doc and test-suite changes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552452&group_id=5470 From noreply@sourceforge.net Mon May 13 04:57:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 20:57:59 -0700 Subject: [Patches] [ python-Patches-552452 ] Add degrees() & radians() to math module Message-ID: Patches item #552452, was opened at 2002-05-05 02:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552452&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 3 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Add degrees() & radians() to math module Initial Comment: Add functions to convert degrees and radians to the math module. Closes item #3 on feature request www.python.org/sf/426539 . The other two items have already been implemented. The two related entries in PEP 42 can be closed also. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-12 22:57 Message: Logged In: YES user_id=80475 Revised patch attached below. Committed as mathmodule 2.67, libmath.tex 1.26 and test_math.py 1.14. Closing patch and feature request. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-05-12 21:36 Message: Logged In: YES user_id=31435 Looks good to me, except that x * (1.0 / degToRad) introduces two rounding errors for no reason. Marked Accepted assuming this line gets changed to x / degToRad Note that this also needs doc and test-suite changes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552452&group_id=5470 From noreply@sourceforge.net Mon May 13 06:05:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 22:05:19 -0700 Subject: [Patches] [ python-Patches-549187 ] error about string formatting rewording? Message-ID: Patches item #549187, was opened at 2002-04-26 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) >Assigned to: Martin v. Löwis (loewis) Summary: error about string formatting rewording? Initial Comment: The error message that occurs during string formatting, when one passes more arguments than necessary, is this: TypeError: not all arguments converted It might be good to mention that this conversion is taking place as a result of string formatting. My suggestions is to add a little more to this message: TypeError: not all arguments converted during string formatting The reason is because string formatting uses the same operation as the modulus command, and also can take in a single integer argument, like: ziffer = note % 10 Newcomers to the language often mix up string and numbers, and the error message above can be very cryptic if one doesn't know about string formatting yet. With the reworded error message, there's less of chance of confusion. See: http://mail.python.org/pipermail/tutor/2002-April/014110.html for more details on why this might be nice. Thanks! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 00:05 Message: Logged In: YES user_id=80475 Martin, is this okay to commit to MAIN and to backport to release22-maint? Review: ----------------------- This makes sense to me. The code runs fine. I grepped the objects directory and found that all instances of the message had been accounted for. Read the original email from an instructor and believe that the current error message was confusing to students. ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2002-04-27 22:39 Message: Logged In: YES user_id=49843 Ok, I wrote up a patch to add more to the error message. Here's what it does: >>> def isEven(n): return n % 2 == 0 ... >>> isEven(17) False >>> isEven("17") Traceback (most recent call last): File "", line 1, in ? File "", line 1, in isEven TypeError: not all arguments converted during string formatting ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 From noreply@sourceforge.net Mon May 13 06:13:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 12 May 2002 22:13:45 -0700 Subject: [Patches] [ python-Patches-549187 ] error about string formatting rewording? Message-ID: Patches item #549187, was opened at 2002-04-27 03:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Martin v. Löwis (loewis) Summary: error about string formatting rewording? Initial Comment: The error message that occurs during string formatting, when one passes more arguments than necessary, is this: TypeError: not all arguments converted It might be good to mention that this conversion is taking place as a result of string formatting. My suggestions is to add a little more to this message: TypeError: not all arguments converted during string formatting The reason is because string formatting uses the same operation as the modulus command, and also can take in a single integer argument, like: ziffer = note % 10 Newcomers to the language often mix up string and numbers, and the error message above can be very cryptic if one doesn't know about string formatting yet. With the reworded error message, there's less of chance of confusion. See: http://mail.python.org/pipermail/tutor/2002-April/014110.html for more details on why this might be nice. Thanks! ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-13 15:13 Message: Logged In: YES user_id=29957 This seems fine to me, and is suitable for the 22 branch. The 21 branch is mostly only getting genuine bugs, rather than cosmetic fixes. I can't imagine anything would depend on the wording of the error messages... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 15:05 Message: Logged In: YES user_id=80475 Martin, is this okay to commit to MAIN and to backport to release22-maint? Review: ----------------------- This makes sense to me. The code runs fine. I grepped the objects directory and found that all instances of the message had been accounted for. Read the original email from an instructor and believe that the current error message was confusing to students. ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2002-04-28 13:39 Message: Logged In: YES user_id=49843 Ok, I wrote up a patch to add more to the error message. Here's what it does: >>> def isEven(n): return n % 2 == 0 ... >>> isEven(17) False >>> isEven("17") Traceback (most recent call last): File "", line 1, in ? File "", line 1, in isEven TypeError: not all arguments converted during string formatting ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 From noreply@sourceforge.net Mon May 13 11:19:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 13 May 2002 03:19:32 -0700 Subject: [Patches] [ python-Patches-555382 ] test_array v.s. --disable-unicode Message-ID: Patches item #555382, was opened at 2002-05-13 10:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555382&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: test_array v.s. --disable-unicode Initial Comment: This patch makes test_array work in --disable-unicode builds. It wasn't a lot of fun to do, but the arraymodule was broken under these builds, so I wanted to get the test working. This mainly consisted of lots of s/u'foo'/unicode('foo', 'unicode-escape') and some judicious testing of test_support.have_unicode. This is very very far from being the only test which fails without unicode literals, but it's a start... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555382&group_id=5470 From noreply@sourceforge.net Tue May 14 01:29:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 13 May 2002 17:29:13 -0700 Subject: [Patches] [ python-Patches-529408 ] fix random.gammavariate bug #527139 Message-ID: Patches item #529408, was opened at 2002-03-13 07:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: fix random.gammavariate bug #527139 Initial Comment: random.gammavariate() doesn't work for gamma < 0.5 See detailed comment on bug # 527139 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 19:29 Message: Logged In: YES user_id=80475 John, I had fixed the original bug report without knowing that this patch existed. Your patch would've saved me the time to figure-out what was wrong :( My patch took the minimal intervention approach (touching the fewest lines) to fix the docs and allow the code to work for alpha>0 without changing the user interface or affecting existing code. The commit is already in the CVS. Is there anything else important that needs to be accomplished? The module is in dire need of docstrings. Also, is it important to deprecate stdgamma? P.S. I did run my own eyeball test for means and variances for alphas including .01 .1 .2 ... 8. Everything is working fine now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-18 08:08 Message: Logged In: YES user_id=6656 I'm afraid this isn't going to make 2.2.1c1. I'll try to consider it before 2.2.1 final, but I'd want to be very certain about things before applying it there. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 08:05 Message: Logged In: YES user_id=480138 Attached is test script test_gamma.py. Passing test means: eye-balling of relative "errors" reveals no nasties for at least alpha >= 0.1 Note that Python's gammavariate() is not very accurate at all for alpha < 0.1 approx. However neither are another two methods that I tried (details in the file). I'll leave it at that -- evidently alpha < 1.0 is "rare and difficult" according to Marsaglia & Tsang. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 07:57 Message: Logged In: YES user_id=480138 Patch file random2.dif uploaded. stdgamma() deprecated as per TP suggestion. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-18 00:32 Message: Logged In: YES user_id=31435 John, if I were you I'd leave stdgamma alone, except for adding this code to its start: import warnings warnings.warn("The stdgamma function is deprecated; " "use gammavariate() instead", DeprecationWarning) Then we can remove stdgamma in 2.4. 2.2.1 will probably go out on Monday night, so it would be nice to get this done before then. OTOH, I expect there will be a 2.2.2 later, so not a tragedy if it's not. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-17 15:46 Message: Logged In: YES user_id=480138 OK; I understand the problems with the patch. Not sure about the way forward -- shall I prepare a patch that just fixes gammavariate() and leaves stdgamma() there (with warning in the comments: deprecated? will be removed in 2.x?)? Do you want it real soon now (for 2.2.1)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-17 14:42 Message: Logged In: YES user_id=31435 Michael, this definitely doesn't belong in 2.2.1 as-is, because it removes a currently-exported name (buggy or not, sensible or not, somebody may be using random.stdgamma now and be happy with it). John, if you're going to remove stdgamma, you need also to remove its (string) name from the module's __all__ list (right before the _verify() function). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-16 12:38 Message: Logged In: YES user_id=31435 Possibly, depending on whether it belongs in 2.3 -- I'm spread too thin to review it now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-16 11:53 Message: Logged In: YES user_id=6656 Tim, do you think this should go into 2.2.1? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 From noreply@sourceforge.net Tue May 14 02:08:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 13 May 2002 18:08:00 -0700 Subject: [Patches] [ python-Patches-529408 ] fix random.gammavariate bug #527139 Message-ID: Patches item #529408, was opened at 2002-03-13 23:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: fix random.gammavariate bug #527139 Initial Comment: random.gammavariate() doesn't work for gamma < 0.5 See detailed comment on bug # 527139 ---------------------------------------------------------------------- >Comment By: John Machin (sjmachin) Date: 2002-05-14 11:08 Message: Logged In: YES user_id=480138 Raymond, If you had read the copious notes that I posted on the original bug report, you would have seen that I had (a)figured out what was wrong and (b) promised a patch. stdgamma with those extra arguments is an abomination and should have never been there in the first place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 10:29 Message: Logged In: YES user_id=80475 John, I had fixed the original bug report without knowing that this patch existed. Your patch would've saved me the time to figure-out what was wrong :( My patch took the minimal intervention approach (touching the fewest lines) to fix the docs and allow the code to work for alpha>0 without changing the user interface or affecting existing code. The commit is already in the CVS. Is there anything else important that needs to be accomplished? The module is in dire need of docstrings. Also, is it important to deprecate stdgamma? P.S. I did run my own eyeball test for means and variances for alphas including .01 .1 .2 ... 8. Everything is working fine now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-19 00:08 Message: Logged In: YES user_id=6656 I'm afraid this isn't going to make 2.2.1c1. I'll try to consider it before 2.2.1 final, but I'd want to be very certain about things before applying it there. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-19 00:05 Message: Logged In: YES user_id=480138 Attached is test script test_gamma.py. Passing test means: eye-balling of relative "errors" reveals no nasties for at least alpha >= 0.1 Note that Python's gammavariate() is not very accurate at all for alpha < 0.1 approx. However neither are another two methods that I tried (details in the file). I'll leave it at that -- evidently alpha < 1.0 is "rare and difficult" according to Marsaglia & Tsang. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 23:57 Message: Logged In: YES user_id=480138 Patch file random2.dif uploaded. stdgamma() deprecated as per TP suggestion. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-18 16:32 Message: Logged In: YES user_id=31435 John, if I were you I'd leave stdgamma alone, except for adding this code to its start: import warnings warnings.warn("The stdgamma function is deprecated; " "use gammavariate() instead", DeprecationWarning) Then we can remove stdgamma in 2.4. 2.2.1 will probably go out on Monday night, so it would be nice to get this done before then. OTOH, I expect there will be a 2.2.2 later, so not a tragedy if it's not. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 07:46 Message: Logged In: YES user_id=480138 OK; I understand the problems with the patch. Not sure about the way forward -- shall I prepare a patch that just fixes gammavariate() and leaves stdgamma() there (with warning in the comments: deprecated? will be removed in 2.x?)? Do you want it real soon now (for 2.2.1)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-18 06:42 Message: Logged In: YES user_id=31435 Michael, this definitely doesn't belong in 2.2.1 as-is, because it removes a currently-exported name (buggy or not, sensible or not, somebody may be using random.stdgamma now and be happy with it). John, if you're going to remove stdgamma, you need also to remove its (string) name from the module's __all__ list (right before the _verify() function). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-17 04:38 Message: Logged In: YES user_id=31435 Possibly, depending on whether it belongs in 2.3 -- I'm spread too thin to review it now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-17 03:53 Message: Logged In: YES user_id=6656 Tim, do you think this should go into 2.2.1? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 From noreply@sourceforge.net Tue May 14 03:30:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 13 May 2002 19:30:43 -0700 Subject: [Patches] [ python-Patches-529408 ] fix random.gammavariate bug #527139 Message-ID: Patches item #529408, was opened at 2002-03-13 07:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: fix random.gammavariate bug #527139 Initial Comment: random.gammavariate() doesn't work for gamma < 0.5 See detailed comment on bug # 527139 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 21:30 Message: Logged In: YES user_id=80475 The tone sounds angry so I apologize for stepping on your toes. The good news is that my patch is essentially a subset of yours (a subset that fixed the docs and the original bug). Code improvements like deprecating stdgamma or improving the docstrings are still possible. If you post any further patches, I'll help them along as much as I can. As it stands, the module leaves much to be desired. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-05-13 20:08 Message: Logged In: YES user_id=480138 Raymond, If you had read the copious notes that I posted on the original bug report, you would have seen that I had (a)figured out what was wrong and (b) promised a patch. stdgamma with those extra arguments is an abomination and should have never been there in the first place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 19:29 Message: Logged In: YES user_id=80475 John, I had fixed the original bug report without knowing that this patch existed. Your patch would've saved me the time to figure-out what was wrong :( My patch took the minimal intervention approach (touching the fewest lines) to fix the docs and allow the code to work for alpha>0 without changing the user interface or affecting existing code. The commit is already in the CVS. Is there anything else important that needs to be accomplished? The module is in dire need of docstrings. Also, is it important to deprecate stdgamma? P.S. I did run my own eyeball test for means and variances for alphas including .01 .1 .2 ... 8. Everything is working fine now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-18 08:08 Message: Logged In: YES user_id=6656 I'm afraid this isn't going to make 2.2.1c1. I'll try to consider it before 2.2.1 final, but I'd want to be very certain about things before applying it there. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 08:05 Message: Logged In: YES user_id=480138 Attached is test script test_gamma.py. Passing test means: eye-balling of relative "errors" reveals no nasties for at least alpha >= 0.1 Note that Python's gammavariate() is not very accurate at all for alpha < 0.1 approx. However neither are another two methods that I tried (details in the file). I'll leave it at that -- evidently alpha < 1.0 is "rare and difficult" according to Marsaglia & Tsang. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 07:57 Message: Logged In: YES user_id=480138 Patch file random2.dif uploaded. stdgamma() deprecated as per TP suggestion. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-18 00:32 Message: Logged In: YES user_id=31435 John, if I were you I'd leave stdgamma alone, except for adding this code to its start: import warnings warnings.warn("The stdgamma function is deprecated; " "use gammavariate() instead", DeprecationWarning) Then we can remove stdgamma in 2.4. 2.2.1 will probably go out on Monday night, so it would be nice to get this done before then. OTOH, I expect there will be a 2.2.2 later, so not a tragedy if it's not. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-17 15:46 Message: Logged In: YES user_id=480138 OK; I understand the problems with the patch. Not sure about the way forward -- shall I prepare a patch that just fixes gammavariate() and leaves stdgamma() there (with warning in the comments: deprecated? will be removed in 2.x?)? Do you want it real soon now (for 2.2.1)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-17 14:42 Message: Logged In: YES user_id=31435 Michael, this definitely doesn't belong in 2.2.1 as-is, because it removes a currently-exported name (buggy or not, sensible or not, somebody may be using random.stdgamma now and be happy with it). John, if you're going to remove stdgamma, you need also to remove its (string) name from the module's __all__ list (right before the _verify() function). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-16 12:38 Message: Logged In: YES user_id=31435 Possibly, depending on whether it belongs in 2.3 -- I'm spread too thin to review it now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-16 11:53 Message: Logged In: YES user_id=6656 Tim, do you think this should go into 2.2.1? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 From noreply@sourceforge.net Tue May 14 04:36:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 13 May 2002 20:36:03 -0700 Subject: [Patches] [ python-Patches-529408 ] fix random.gammavariate bug #527139 Message-ID: Patches item #529408, was opened at 2002-03-13 07:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: fix random.gammavariate bug #527139 Initial Comment: random.gammavariate() doesn't work for gamma < 0.5 See detailed comment on bug # 527139 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-05-13 23:36 Message: Logged In: YES user_id=31435 I'm all in favor of the only two people who have volunteered two seconds to look at this code in two years making up and getting on with it. John, is there something you object to in what Raymond committed (not the process, but the result)? Raymond, would you add the DeprecationWarning for stdgamma? We still need at least a full release cycle to deprecate anything. Heh. You probably thought this would be less contentious than championing PEPs . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 22:30 Message: Logged In: YES user_id=80475 The tone sounds angry so I apologize for stepping on your toes. The good news is that my patch is essentially a subset of yours (a subset that fixed the docs and the original bug). Code improvements like deprecating stdgamma or improving the docstrings are still possible. If you post any further patches, I'll help them along as much as I can. As it stands, the module leaves much to be desired. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-05-13 21:08 Message: Logged In: YES user_id=480138 Raymond, If you had read the copious notes that I posted on the original bug report, you would have seen that I had (a)figured out what was wrong and (b) promised a patch. stdgamma with those extra arguments is an abomination and should have never been there in the first place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 20:29 Message: Logged In: YES user_id=80475 John, I had fixed the original bug report without knowing that this patch existed. Your patch would've saved me the time to figure-out what was wrong :( My patch took the minimal intervention approach (touching the fewest lines) to fix the docs and allow the code to work for alpha>0 without changing the user interface or affecting existing code. The commit is already in the CVS. Is there anything else important that needs to be accomplished? The module is in dire need of docstrings. Also, is it important to deprecate stdgamma? P.S. I did run my own eyeball test for means and variances for alphas including .01 .1 .2 ... 8. Everything is working fine now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-18 08:08 Message: Logged In: YES user_id=6656 I'm afraid this isn't going to make 2.2.1c1. I'll try to consider it before 2.2.1 final, but I'd want to be very certain about things before applying it there. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 08:05 Message: Logged In: YES user_id=480138 Attached is test script test_gamma.py. Passing test means: eye-balling of relative "errors" reveals no nasties for at least alpha >= 0.1 Note that Python's gammavariate() is not very accurate at all for alpha < 0.1 approx. However neither are another two methods that I tried (details in the file). I'll leave it at that -- evidently alpha < 1.0 is "rare and difficult" according to Marsaglia & Tsang. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 07:57 Message: Logged In: YES user_id=480138 Patch file random2.dif uploaded. stdgamma() deprecated as per TP suggestion. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-18 00:32 Message: Logged In: YES user_id=31435 John, if I were you I'd leave stdgamma alone, except for adding this code to its start: import warnings warnings.warn("The stdgamma function is deprecated; " "use gammavariate() instead", DeprecationWarning) Then we can remove stdgamma in 2.4. 2.2.1 will probably go out on Monday night, so it would be nice to get this done before then. OTOH, I expect there will be a 2.2.2 later, so not a tragedy if it's not. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-17 15:46 Message: Logged In: YES user_id=480138 OK; I understand the problems with the patch. Not sure about the way forward -- shall I prepare a patch that just fixes gammavariate() and leaves stdgamma() there (with warning in the comments: deprecated? will be removed in 2.x?)? Do you want it real soon now (for 2.2.1)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-17 14:42 Message: Logged In: YES user_id=31435 Michael, this definitely doesn't belong in 2.2.1 as-is, because it removes a currently-exported name (buggy or not, sensible or not, somebody may be using random.stdgamma now and be happy with it). John, if you're going to remove stdgamma, you need also to remove its (string) name from the module's __all__ list (right before the _verify() function). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-16 12:38 Message: Logged In: YES user_id=31435 Possibly, depending on whether it belongs in 2.3 -- I'm spread too thin to review it now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-16 11:53 Message: Logged In: YES user_id=6656 Tim, do you think this should go into 2.2.1? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 From noreply@sourceforge.net Tue May 14 08:03:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 00:03:01 -0700 Subject: [Patches] [ python-Patches-529408 ] fix random.gammavariate bug #527139 Message-ID: Patches item #529408, was opened at 2002-03-13 07:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: fix random.gammavariate bug #527139 Initial Comment: random.gammavariate() doesn't work for gamma < 0.5 See detailed comment on bug # 527139 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 02:03 Message: Logged In: YES user_id=80475 Done. Put in John's patch as random.py 1.30 and 1.26.6.3. John to close patch if all issues are resolved. Peace and love to all. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-05-13 22:36 Message: Logged In: YES user_id=31435 I'm all in favor of the only two people who have volunteered two seconds to look at this code in two years making up and getting on with it. John, is there something you object to in what Raymond committed (not the process, but the result)? Raymond, would you add the DeprecationWarning for stdgamma? We still need at least a full release cycle to deprecate anything. Heh. You probably thought this would be less contentious than championing PEPs . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 21:30 Message: Logged In: YES user_id=80475 The tone sounds angry so I apologize for stepping on your toes. The good news is that my patch is essentially a subset of yours (a subset that fixed the docs and the original bug). Code improvements like deprecating stdgamma or improving the docstrings are still possible. If you post any further patches, I'll help them along as much as I can. As it stands, the module leaves much to be desired. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-05-13 20:08 Message: Logged In: YES user_id=480138 Raymond, If you had read the copious notes that I posted on the original bug report, you would have seen that I had (a)figured out what was wrong and (b) promised a patch. stdgamma with those extra arguments is an abomination and should have never been there in the first place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 19:29 Message: Logged In: YES user_id=80475 John, I had fixed the original bug report without knowing that this patch existed. Your patch would've saved me the time to figure-out what was wrong :( My patch took the minimal intervention approach (touching the fewest lines) to fix the docs and allow the code to work for alpha>0 without changing the user interface or affecting existing code. The commit is already in the CVS. Is there anything else important that needs to be accomplished? The module is in dire need of docstrings. Also, is it important to deprecate stdgamma? P.S. I did run my own eyeball test for means and variances for alphas including .01 .1 .2 ... 8. Everything is working fine now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-18 08:08 Message: Logged In: YES user_id=6656 I'm afraid this isn't going to make 2.2.1c1. I'll try to consider it before 2.2.1 final, but I'd want to be very certain about things before applying it there. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 08:05 Message: Logged In: YES user_id=480138 Attached is test script test_gamma.py. Passing test means: eye-balling of relative "errors" reveals no nasties for at least alpha >= 0.1 Note that Python's gammavariate() is not very accurate at all for alpha < 0.1 approx. However neither are another two methods that I tried (details in the file). I'll leave it at that -- evidently alpha < 1.0 is "rare and difficult" according to Marsaglia & Tsang. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 07:57 Message: Logged In: YES user_id=480138 Patch file random2.dif uploaded. stdgamma() deprecated as per TP suggestion. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-18 00:32 Message: Logged In: YES user_id=31435 John, if I were you I'd leave stdgamma alone, except for adding this code to its start: import warnings warnings.warn("The stdgamma function is deprecated; " "use gammavariate() instead", DeprecationWarning) Then we can remove stdgamma in 2.4. 2.2.1 will probably go out on Monday night, so it would be nice to get this done before then. OTOH, I expect there will be a 2.2.2 later, so not a tragedy if it's not. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-17 15:46 Message: Logged In: YES user_id=480138 OK; I understand the problems with the patch. Not sure about the way forward -- shall I prepare a patch that just fixes gammavariate() and leaves stdgamma() there (with warning in the comments: deprecated? will be removed in 2.x?)? Do you want it real soon now (for 2.2.1)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-17 14:42 Message: Logged In: YES user_id=31435 Michael, this definitely doesn't belong in 2.2.1 as-is, because it removes a currently-exported name (buggy or not, sensible or not, somebody may be using random.stdgamma now and be happy with it). John, if you're going to remove stdgamma, you need also to remove its (string) name from the module's __all__ list (right before the _verify() function). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-16 12:38 Message: Logged In: YES user_id=31435 Possibly, depending on whether it belongs in 2.3 -- I'm spread too thin to review it now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-16 11:53 Message: Logged In: YES user_id=6656 Tim, do you think this should go into 2.2.1? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 From noreply@sourceforge.net Tue May 14 08:26:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 00:26:13 -0700 Subject: [Patches] [ python-Patches-550002 ] Unittest for base64 Message-ID: Patches item #550002, was opened at 2002-04-28 22:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550002&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mitchell Surface (msurface) >Assigned to: Raymond Hettinger (rhettinger) Summary: Unittest for base64 Initial Comment: Script for testing base64.decodestring and base64.encodestring. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 02:26 Message: Logged In: YES user_id=80475 Test code runs fine. Looks comprehensive. Does not test encode/decode from a file but the underlying logic is the same. If no one has any issues by Fri 2002-May-17, I'll load it to the testbank. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550002&group_id=5470 From noreply@sourceforge.net Tue May 14 13:04:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 05:04:29 -0700 Subject: [Patches] [ python-Patches-555883 ] fcntl.ioctl2 - fix for bug #555817 Message-ID: Patches item #555883, was opened at 2002-05-14 22:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl.ioctl2 - fix for bug #555817 Initial Comment: See bug #555817 - the basics of it are that some ioctl calls rely on both getting back the modified third argument and the return code. Python's ioctl implementation doesn't allow this. Linux docs explicitly mention this, the solaris docs also say it's possible (but not so explicitly). Anyway, this fix is a patch to fcntlmodule.c and a test_ioctl.py script - it merely tries to use TIOCGPGRP and compares it to os.getpgrp(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 From noreply@sourceforge.net Tue May 14 14:22:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 06:22:04 -0700 Subject: [Patches] [ python-Patches-555929 ] Cygwin AH_BOTTOM cleanup patch Message-ID: Patches item #555929, was opened at 2002-05-14 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin AH_BOTTOM cleanup patch Initial Comment: This patch complies with the following request found near the top of configure.in: # This is for stuff that absolutely must end up in pyconfig.h. # Please use pyport.h instead, if possible. I tested this patch under Cygwin, Win32, and Red Hat Linux. Python built and ran successfully on each of these platforms. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 From noreply@sourceforge.net Tue May 14 23:03:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 15:03:47 -0700 Subject: [Patches] [ python-Patches-555929 ] Cygwin AH_BOTTOM cleanup patch Message-ID: Patches item #555929, was opened at 2002-05-14 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 Category: Build Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin AH_BOTTOM cleanup patch Initial Comment: This patch complies with the following request found near the top of configure.in: # This is for stuff that absolutely must end up in pyconfig.h. # Please use pyport.h instead, if possible. I tested this patch under Cygwin, Win32, and Red Hat Linux. Python built and ran successfully on each of these platforms. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:03 Message: Logged In: YES user_id=21627 Sounds good; please install this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 From noreply@sourceforge.net Tue May 14 23:13:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 15:13:25 -0700 Subject: [Patches] [ python-Patches-555883 ] fcntl.ioctl2 - fix for bug #555817 Message-ID: Patches item #555883, was opened at 2002-05-14 14:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl.ioctl2 - fix for bug #555817 Initial Comment: See bug #555817 - the basics of it are that some ioctl calls rely on both getting back the modified third argument and the return code. Python's ioctl implementation doesn't allow this. Linux docs explicitly mention this, the solaris docs also say it's possible (but not so explicitly). Anyway, this fix is a patch to fcntlmodule.c and a test_ioctl.py script - it merely tries to use TIOCGPGRP and compares it to os.getpgrp(). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:13 Message: Logged In: YES user_id=21627 The patch looks good to me, but it probably needs accompanying documentation patch. Also: - why do you put the ParseTuple in an if-else? It is common to put the else part on the function level. - would it be possible to find a more precise name than ioctl2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 From noreply@sourceforge.net Tue May 14 23:19:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 15:19:28 -0700 Subject: [Patches] [ python-Patches-555883 ] fcntl.ioctl2 - fix for bug #555817 Message-ID: Patches item #555883, was opened at 2002-05-14 14:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: fcntl.ioctl2 - fix for bug #555817 Initial Comment: See bug #555817 - the basics of it are that some ioctl calls rely on both getting back the modified third argument and the return code. Python's ioctl implementation doesn't allow this. Linux docs explicitly mention this, the solaris docs also say it's possible (but not so explicitly). Anyway, this fix is a patch to fcntlmodule.c and a test_ioctl.py script - it merely tries to use TIOCGPGRP and compares it to os.getpgrp(). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:13 Message: Logged In: YES user_id=21627 The patch looks good to me, but it probably needs accompanying documentation patch. Also: - why do you put the ParseTuple in an if-else? It is common to put the else part on the function level. - would it be possible to find a more precise name than ioctl2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 From noreply@sourceforge.net Tue May 14 23:19:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 15:19:01 -0700 Subject: [Patches] [ python-Patches-555382 ] test_array v.s. --disable-unicode Message-ID: Patches item #555382, was opened at 2002-05-13 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555382&group_id=5470 Category: Tests Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: test_array v.s. --disable-unicode Initial Comment: This patch makes test_array work in --disable-unicode builds. It wasn't a lot of fun to do, but the arraymodule was broken under these builds, so I wanted to get the test working. This mainly consisted of lots of s/u'foo'/unicode('foo', 'unicode-escape') and some judicious testing of test_support.have_unicode. This is very very far from being the only test which fails without unicode literals, but it's a start... ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:19 Message: Logged In: YES user_id=21627 The patch looks good to me, but I would a) use "ascii" as the encoding if there are no escapes, and b) use raw strings ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555382&group_id=5470 From noreply@sourceforge.net Tue May 14 23:23:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 15:23:22 -0700 Subject: [Patches] [ python-Patches-554807 ] Add _winreg support for Cygwin Message-ID: Patches item #554807, was opened at 2002-05-11 14:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add _winreg support for Cygwin Initial Comment: This adds _winreg support to Cygwin Python without dependencies on other Windows modules. For platforms in which MS_WINDOWS isn't defined, this reports the OSError exception instead of WindowsErr. It also uses the non-MBCS versions of registry access in this case. Some minor changes to _winreg.c were made to clean up compiler warnings from GCC. setup.py was changed to create a dynamic _winreg module under cygwin. There are also some earlier changes in the patch file to skip the import test (due to Cygwin fork issues), and to require libintl when building _locale under Cygwin. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:23 Message: Logged In: YES user_id=21627 Can you please explain why not using MBCS is the right thing? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 From noreply@sourceforge.net Tue May 14 23:25:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 15:25:29 -0700 Subject: [Patches] [ python-Patches-553678 ] Cygwin Makefile.pre.in vestige patch Message-ID: Patches item #553678, was opened at 2002-05-08 13:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553678&group_id=5470 Category: Build Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: Cygwin Makefile.pre.in vestige patch Initial Comment: This patch removes a vestige part of the Cygwin make rules that didn't quite make it over during the flattening of the Makefiles. In its current form, it creates a def file but incorrectly calls it libpython$(VERSION).dll.a which immediately gets overwritten by the next command. Obviously, this is useless. It appears, it was useless in the old nested Makefile structure too. :,) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:25 Message: Logged In: YES user_id=21627 This patch looks fine - please install it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553678&group_id=5470 From noreply@sourceforge.net Tue May 14 23:45:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 15:45:59 -0700 Subject: [Patches] [ python-Patches-529408 ] fix random.gammavariate bug #527139 Message-ID: Patches item #529408, was opened at 2002-03-13 23:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Machin (sjmachin) Assigned to: Tim Peters (tim_one) Summary: fix random.gammavariate bug #527139 Initial Comment: random.gammavariate() doesn't work for gamma < 0.5 See detailed comment on bug # 527139 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 17:03 Message: Logged In: YES user_id=80475 Done. Put in John's patch as random.py 1.30 and 1.26.6.3. John to close patch if all issues are resolved. Peace and love to all. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-05-14 13:36 Message: Logged In: YES user_id=31435 I'm all in favor of the only two people who have volunteered two seconds to look at this code in two years making up and getting on with it. John, is there something you object to in what Raymond committed (not the process, but the result)? Raymond, would you add the DeprecationWarning for stdgamma? We still need at least a full release cycle to deprecate anything. Heh. You probably thought this would be less contentious than championing PEPs . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 12:30 Message: Logged In: YES user_id=80475 The tone sounds angry so I apologize for stepping on your toes. The good news is that my patch is essentially a subset of yours (a subset that fixed the docs and the original bug). Code improvements like deprecating stdgamma or improving the docstrings are still possible. If you post any further patches, I'll help them along as much as I can. As it stands, the module leaves much to be desired. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-05-14 11:08 Message: Logged In: YES user_id=480138 Raymond, If you had read the copious notes that I posted on the original bug report, you would have seen that I had (a)figured out what was wrong and (b) promised a patch. stdgamma with those extra arguments is an abomination and should have never been there in the first place. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 10:29 Message: Logged In: YES user_id=80475 John, I had fixed the original bug report without knowing that this patch existed. Your patch would've saved me the time to figure-out what was wrong :( My patch took the minimal intervention approach (touching the fewest lines) to fix the docs and allow the code to work for alpha>0 without changing the user interface or affecting existing code. The commit is already in the CVS. Is there anything else important that needs to be accomplished? The module is in dire need of docstrings. Also, is it important to deprecate stdgamma? P.S. I did run my own eyeball test for means and variances for alphas including .01 .1 .2 ... 8. Everything is working fine now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-19 00:08 Message: Logged In: YES user_id=6656 I'm afraid this isn't going to make 2.2.1c1. I'll try to consider it before 2.2.1 final, but I'd want to be very certain about things before applying it there. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-19 00:05 Message: Logged In: YES user_id=480138 Attached is test script test_gamma.py. Passing test means: eye-balling of relative "errors" reveals no nasties for at least alpha >= 0.1 Note that Python's gammavariate() is not very accurate at all for alpha < 0.1 approx. However neither are another two methods that I tried (details in the file). I'll leave it at that -- evidently alpha < 1.0 is "rare and difficult" according to Marsaglia & Tsang. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 23:57 Message: Logged In: YES user_id=480138 Patch file random2.dif uploaded. stdgamma() deprecated as per TP suggestion. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-18 16:32 Message: Logged In: YES user_id=31435 John, if I were you I'd leave stdgamma alone, except for adding this code to its start: import warnings warnings.warn("The stdgamma function is deprecated; " "use gammavariate() instead", DeprecationWarning) Then we can remove stdgamma in 2.4. 2.2.1 will probably go out on Monday night, so it would be nice to get this done before then. OTOH, I expect there will be a 2.2.2 later, so not a tragedy if it's not. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2002-03-18 07:46 Message: Logged In: YES user_id=480138 OK; I understand the problems with the patch. Not sure about the way forward -- shall I prepare a patch that just fixes gammavariate() and leaves stdgamma() there (with warning in the comments: deprecated? will be removed in 2.x?)? Do you want it real soon now (for 2.2.1)? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-18 06:42 Message: Logged In: YES user_id=31435 Michael, this definitely doesn't belong in 2.2.1 as-is, because it removes a currently-exported name (buggy or not, sensible or not, somebody may be using random.stdgamma now and be happy with it). John, if you're going to remove stdgamma, you need also to remove its (string) name from the module's __all__ list (right before the _verify() function). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-17 04:38 Message: Logged In: YES user_id=31435 Possibly, depending on whether it belongs in 2.3 -- I'm spread too thin to review it now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-17 03:53 Message: Logged In: YES user_id=6656 Tim, do you think this should go into 2.2.1? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=529408&group_id=5470 From noreply@sourceforge.net Wed May 15 01:09:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 17:09:38 -0700 Subject: [Patches] [ python-Patches-556161 ] Add docstrings to modules Message-ID: Patches item #556161, was opened at 2002-05-14 19:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=556161&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Add docstrings to modules Initial Comment: Fred, please approve patch for 2.3 and release22- maint. It adds docstrings to StringIO.py, tabnanny.py, fileinput.py, and tokenize.py. There is no magic; I cut and pasted the strings out of the current version of the docs (after checking to make sure they were the same for both 2.2 and 2.3). The only text adjustments made were line formatting, removing section references, and filling in the occassional "see above". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=556161&group_id=5470 From noreply@sourceforge.net Wed May 15 01:51:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 17:51:18 -0700 Subject: [Patches] [ python-Patches-555883 ] fcntl.ioctl2 - fix for bug #555817 Message-ID: Patches item #555883, was opened at 2002-05-14 22:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: fcntl.ioctl2 - fix for bug #555817 Initial Comment: See bug #555817 - the basics of it are that some ioctl calls rely on both getting back the modified third argument and the return code. Python's ioctl implementation doesn't allow this. Linux docs explicitly mention this, the solaris docs also say it's possible (but not so explicitly). Anyway, this fix is a patch to fcntlmodule.c and a test_ioctl.py script - it merely tries to use TIOCGPGRP and compares it to os.getpgrp(). ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-15 10:51 Message: Logged In: YES user_id=29957 the else-bit - no reason, I'll fix it before I commit the patch. I'll write the docs today and attach them. ioctl2 isn't my favourite, either, but I can't think of a better name. ioctl_that_returns_a_tuple() isn't any better, ioctlt(), nioctl()... the '2' thing is reasonably common in C libraries... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 08:13 Message: Logged In: YES user_id=21627 The patch looks good to me, but it probably needs accompanying documentation patch. Also: - why do you put the ParseTuple in an if-else? It is common to put the else part on the function level. - would it be possible to find a more precise name than ioctl2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 From noreply@sourceforge.net Wed May 15 03:24:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 19:24:35 -0700 Subject: [Patches] [ python-Patches-556161 ] Add docstrings to modules Message-ID: Patches item #556161, was opened at 2002-05-14 20:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=556161&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add docstrings to modules Initial Comment: Fred, please approve patch for 2.3 and release22- maint. It adds docstrings to StringIO.py, tabnanny.py, fileinput.py, and tokenize.py. There is no magic; I cut and pasted the strings out of the current version of the docs (after checking to make sure they were the same for both 2.2 and 2.3). The only text adjustments made were line formatting, removing section references, and filling in the occassional "see above". ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-14 22:24 Message: Logged In: YES user_id=3066 There's a minor style inconsistency with the rest of the standard library. To be consistent use """ instead of ''' and keep the first line on the line with the opening quotes: """This is the summary line. And the longer explanation goes here. """ Whether the closing quotes go on a separate line or at the end of the last line of text is not consistent within the existing docstrings in the library. With this change, you can go ahead and check this in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=556161&group_id=5470 From noreply@sourceforge.net Wed May 15 04:53:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 14 May 2002 20:53:11 -0700 Subject: [Patches] [ python-Patches-556161 ] Add docstrings to modules Message-ID: Patches item #556161, was opened at 2002-05-14 19:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=556161&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Add docstrings to modules Initial Comment: Fred, please approve patch for 2.3 and release22- maint. It adds docstrings to StringIO.py, tabnanny.py, fileinput.py, and tokenize.py. There is no magic; I cut and pasted the strings out of the current version of the docs (after checking to make sure they were the same for both 2.2 and 2.3). The only text adjustments made were line formatting, removing section references, and filling in the occassional "see above". ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 22:53 Message: Logged In: YES user_id=80475 Changed to triple-double quotes. Moved summary lines. Committed for Py2.3 as StringIO.py 1.25, tabnanny.py 1.19, fileinput.py 1.12, and tokenize.py 1.31. Committed for Py2.2 as StringIO.py 1.19.12.2, tabnanny.py 1.16.16.1, fileinput.py 1.8.8.1, tokenize.py 1.28.14.1. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-14 21:24 Message: Logged In: YES user_id=3066 There's a minor style inconsistency with the rest of the standard library. To be consistent use """ instead of ''' and keep the first line on the line with the opening quotes: """This is the summary line. And the longer explanation goes here. """ Whether the closing quotes go on a separate line or at the end of the last line of text is not consistent within the existing docstrings in the library. With this change, you can go ahead and check this in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=556161&group_id=5470 From noreply@sourceforge.net Wed May 15 12:37:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 04:37:49 -0700 Subject: [Patches] [ python-Patches-553678 ] Cygwin Makefile.pre.in vestige patch Message-ID: Patches item #553678, was opened at 2002-05-08 03:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553678&group_id=5470 Category: Build Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin Makefile.pre.in vestige patch Initial Comment: This patch removes a vestige part of the Cygwin make rules that didn't quite make it over during the flattening of the Makefiles. In its current form, it creates a def file but incorrectly calls it libpython$(VERSION).dll.a which immediately gets overwritten by the next command. Obviously, this is useless. It appears, it was useless in the old nested Makefile structure too. :,) ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-15 03:37 Message: Logged In: YES user_id=86216 Comitted as Makefile.pre.in 1.84. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-14 14:25 Message: Logged In: YES user_id=21627 This patch looks fine - please install it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553678&group_id=5470 From noreply@sourceforge.net Wed May 15 12:54:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 04:54:16 -0700 Subject: [Patches] [ python-Patches-488073 ] AtheOS port of Python 2.2b2 Message-ID: Patches item #488073, was opened at 2001-12-02 15:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Octavian Cerna (tavyc) Assigned to: Martin v. Löwis (loewis) Summary: AtheOS port of Python 2.2b2 Initial Comment: Hi, While I was playing with AtheOS in the last few days, I saw that it comes with Python 1.5.2. Being a Python enthusiast, I tried to see if a recent version of Python would work. It did not even compile, so I decided to port it, knowing that AtheOS is almost POSIX-compatible. The result is a full-blown Python port with only a (relative) small amount of changes, that builds OOTB. And here it is, with all the details: About the patch: - The diff is against CVS 2001-11-26 - 20 files changed, 1962 insertions, 23 deletions - It does not include changes to autoconf-generated files - The patch includes a few very small fixes not directly related to the AtheOS port, but which were necessary to ensure the port works OK: - setup.py - look for the _curses_panel.c file in $srcdir/Modules, not in $PWD/Modules (otherwise VPATH builds will not build _curses_panel.so) - Makefile.pre.in - only ranlib *.a files (how will this affect other ports?) - Tools/freeze/bkfile.py - not all platforms have the file.truncate method - Tools/scripts/h2py.py - environment- paths code was made more portable Environment: - AtheOS 0.3.6 - gcc 2.95.2 - binutils 2.10 - glibc 2.1.2 Features: - Dynamic loading of modules - Native thread support Issues: Although AtheOS is not a BeOS clone, it is in many ways similar to BeOS, and some issues from BeOS also apply on AtheOS. - dlopen is not properly implemented, so I had to add support for native dynamic loading. - The POSIX threads emulation is almost inexistent, so I added support for native AtheOS threads. - AtheOS doesn't support importing symbols in a shared library from the main executable (the `-export-dynamic' linker flag), so the Python core must be built as a shared library, like on BeOS. - mmap is not implemented in AtheOS, the mmap module was disabled - statvfs is not implemented, os.statvfs and os.fstatvfs disabled - crypt on AtheOS crashes with SEGV if salt is not "$1$" (glibc bug?), disabled - poll - it seems that poll never returns POLLNVAL for an invalid fd (hangs), disabled - Don't mix threading with fork() -- see test_popen2 below. All tests pass, except: - test_nis hangs on my system, probably because NIS is not set up - test_popen2 hangs when imported from regrtest.py, otherwise working (like on BeOS). I suspect that the import semaphore is locked when popen2 forks and AtheOS doesn't like that. - test_mhlib fails, I don't know exactly why, but I suspect a filesystem issue (It corrupted some of my files several times, and I don't want to run it again ;) - test_locale skipped, locale en_US not supported (maybe something's wrong with my environment?) - test_largefile skipped (unless you tell it to eat 2GB disk space) because apparently afs doesn't support sparse files. Notes: - If you build Python, make sure you have shared versions of your libraries and you have links in /system/libs for them, otherwise the kernel won't load modules. AtheOS doesn't have a shared version for each library, I had serious problems with ncurses and the _curses_panel module. Binary packages: - I have prepared binary packages of Python-2.2b2 and Numeric-20.2.1 for testing, I will post them on kamidake.org later. Future: - I'm going to try Zope these days, I think it should work with a minimum amount of changes, almost OOTB ;) (Maybe I should have included this text in the README file?) Please excuse my bad English, I am not a native speaker :) Python is an excellent language/environment, keep going with the good work! -------- Best Regards, Octavian Cerna (Tavy) yLabs ---------------------------------------------------------------------- >Comment By: Octavian Cerna (tavyc) Date: 2002-05-15 14:54 Message: Logged In: YES user_id=382173 - AF_UNIX is undefined because Doc/lib/libsocket.tex says: "If the AF_UNIX constant is not defined then this protocol is unsupported." Defining AF_UNIX breaks Lib/SocketServer.py as it doesn't handle EAFNOSUPPORT. - for statvfs I assumed the same convetion, see Lib/test/test_os.py (method StatAttributeTests.test_statvfs_attributes). - the problem is not with autoconf, but in glibc: gnu/stubs.h fails to define __stub_ macros for all unimplemented functions (statvfs for example). - fseeko/ftello don't work at all for large files. Small example: fp = fopen("2.1GB_file", "r"); /*filesize=2307915776LL*/ fseeko(fp, 0LL, 2); /* seeks to eof, returns -1, errno=0 */ ftello(fp); /* returns -1987051520LL, which is (int32)2307915776LL */ This is a sign truncation problem somewhere in libio. The lowlevel functions lseek, stat, etc are all OK: os.stat("2.1GB_file").st_size = 2307915776L So I preferred to disable largefile support for file objects. Perl which also uses stdio has the same problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-12 19:40 Message: Logged In: YES user_id=21627 A few more questions: - Why is AF_UNIX undefined? I.e. what problems would arise if it was exported from the socket module? - Likewise, what problems arise if statvfs is exported from the Posix module? Sure, calling the function might always give an exception, but what is the problem with that? - Also, are you sure this is still an issue with the current autoconf? configure specifically checks for the __stub_ symbols defined in glibc for stub functions. - What problems arise if large file support is enabled? Does seek/tell not work at all, or does it just fail for large files? ---------------------------------------------------------------------- Comment By: Octavian Cerna (tavyc) Date: 2002-05-05 21:23 Message: Logged In: YES user_id=382173 Updated to CVS 2002-05-04. I disabled from setup.py the modules which don't make sense on AtheOS (nis for example). I still used the historic sys.platform[:n] in a few places in order to be consistent with the surrounding code. This time I was more careful with the code, and made more testing. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-20 20:12 Message: Logged In: YES user_id=21627 Can you please update the patch for the current CVS? A few comments: - the plat-*/FCNTL are not generated anymore, FCNTL is deprecated. - Why does test_nis need to skip explicitly on atheos? If the nis module builds, why does the test fail? - Please use the .startswith method over the (historic) [:n] form when testing sys.platform. - I don't understand the O_LARGEFILE chunk. What is the problem with just not defining O_LARGEFILE? ---------------------------------------------------------------------- Comment By: Octavian Cerna (tavyc) Date: 2001-12-02 20:40 Message: Logged In: YES user_id=382173 I know that Python is now in a "feature freeze" or something similar, but this patch could go in Python 2.3. I added the HAVE_GETADDRINFO to acconfig.h because it was simply missing and autoheader complained, (outdated CVS snapshot). I should have removed it from the patch. I posted it here just to make it available to anyone who wants to try it out. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-12-02 17:42 Message: Logged In: YES user_id=21627 I'd advise not to add this port so shortly before 2.2, in particular since these changes need careful review. As an example: Why does it add HAVE_GETADDRINFO to acconfig.h? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488073&group_id=5470 From noreply@sourceforge.net Wed May 15 12:55:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 04:55:43 -0700 Subject: [Patches] [ python-Patches-555929 ] Cygwin AH_BOTTOM cleanup patch Message-ID: Patches item #555929, was opened at 2002-05-14 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin AH_BOTTOM cleanup patch Initial Comment: This patch complies with the following request found near the top of configure.in: # This is for stuff that absolutely must end up in pyconfig.h. # Please use pyport.h instead, if possible. I tested this patch under Cygwin, Win32, and Red Hat Linux. Python built and ran successfully on each of these platforms. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-15 03:55 Message: Logged In: YES user_id=86216 Committed as: configure 1.306 configure.in 1.316 pyconfig.h.in 1.34 Include/Python.h 2.47 Include/pyport.h 2.48 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-14 14:03 Message: Logged In: YES user_id=21627 Sounds good; please install this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 From noreply@sourceforge.net Wed May 15 13:48:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 05:48:11 -0700 Subject: [Patches] [ python-Patches-554807 ] Add _winreg support for Cygwin Message-ID: Patches item #554807, was opened at 2002-05-11 12:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add _winreg support for Cygwin Initial Comment: This adds _winreg support to Cygwin Python without dependencies on other Windows modules. For platforms in which MS_WINDOWS isn't defined, this reports the OSError exception instead of WindowsErr. It also uses the non-MBCS versions of registry access in this case. Some minor changes to _winreg.c were made to clean up compiler warnings from GCC. setup.py was changed to create a dynamic _winreg module under cygwin. There are also some earlier changes in the patch file to skip the import test (due to Cygwin fork issues), and to require libintl when building _locale under Cygwin. ---------------------------------------------------------------------- >Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-15 12:48 Message: Logged In: YES user_id=329402 Windows supplies two versions of the relevant functions. The Cygwin version (at least as built) uses the ANSI versions, as indicated by the A at the end of the symbol names: $ nm _winreg.o | grep RegQueryValue U _RegQueryValueA@16 U _RegQueryValueExA@24 As opposed to the "Windows Unicode/wide-char" functions, which end in W and require MBCS functions to decode. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-14 22:23 Message: Logged In: YES user_id=21627 Can you please explain why not using MBCS is the right thing? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 From noreply@sourceforge.net Wed May 15 13:51:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 05:51:06 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 19:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-15 14:51 Message: Logged In: YES user_id=11105 The attatched patch (stringobject.diff) implements this behaviour: The doc string of 'str' is unchanged, but string objects have a __doc__ attribute of None. The same could (and should) be done for int, float, and probably more types as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 19:08 Message: Logged In: YES user_id=11105 Or maybe add a __doc__ tp_member (or whatever) which always returns None? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 19:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 14:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Wed May 15 13:57:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 05:57:59 -0700 Subject: [Patches] [ python-Patches-554807 ] Add _winreg support for Cygwin Message-ID: Patches item #554807, was opened at 2002-05-11 14:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add _winreg support for Cygwin Initial Comment: This adds _winreg support to Cygwin Python without dependencies on other Windows modules. For platforms in which MS_WINDOWS isn't defined, this reports the OSError exception instead of WindowsErr. It also uses the non-MBCS versions of registry access in this case. Some minor changes to _winreg.c were made to clean up compiler warnings from GCC. setup.py was changed to create a dynamic _winreg module under cygwin. There are also some earlier changes in the patch file to skip the import test (due to Cygwin fork issues), and to require libintl when building _locale under Cygwin. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 14:57 Message: Logged In: YES user_id=21627 Yes, but you are wrong assuming that the *A functions expect Latin-1. Instead, they expect char* encoded as CP_ACP, which is known as "mbcs" in Python. The *W functions do *not* expect multi-byte strings, but Unicode strings. Notice that _winreg also calls the *A functions, even in MSVC builds. So I think converting Unicode to Latin-1 is definitely incorrect. ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-15 14:48 Message: Logged In: YES user_id=329402 Windows supplies two versions of the relevant functions. The Cygwin version (at least as built) uses the ANSI versions, as indicated by the A at the end of the symbol names: $ nm _winreg.o | grep RegQueryValue U _RegQueryValueA@16 U _RegQueryValueExA@24 As opposed to the "Windows Unicode/wide-char" functions, which end in W and require MBCS functions to decode. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:23 Message: Logged In: YES user_id=21627 Can you please explain why not using MBCS is the right thing? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 From noreply@sourceforge.net Wed May 15 14:06:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 06:06:11 -0700 Subject: [Patches] [ python-Patches-555382 ] test_array v.s. --disable-unicode Message-ID: Patches item #555382, was opened at 2002-05-13 10:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555382&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: test_array v.s. --disable-unicode Initial Comment: This patch makes test_array work in --disable-unicode builds. It wasn't a lot of fun to do, but the arraymodule was broken under these builds, so I wanted to get the test working. This mainly consisted of lots of s/u'foo'/unicode('foo', 'unicode-escape') and some judicious testing of test_support.have_unicode. This is very very far from being the only test which fails without unicode literals, but it's a start... ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-15 13:06 Message: Logged In: YES user_id=6656 Fair enough (I always forget about raw strings). Committed as revision 1.15 of Lib/test/test_array.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-14 22:19 Message: Logged In: YES user_id=21627 The patch looks good to me, but I would a) use "ascii" as the encoding if there are no escapes, and b) use raw strings ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555382&group_id=5470 From noreply@sourceforge.net Wed May 15 14:06:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 06:06:28 -0700 Subject: [Patches] [ python-Patches-555382 ] test_array v.s. --disable-unicode Message-ID: Patches item #555382, was opened at 2002-05-13 10:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555382&group_id=5470 Category: Tests Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: test_array v.s. --disable-unicode Initial Comment: This patch makes test_array work in --disable-unicode builds. It wasn't a lot of fun to do, but the arraymodule was broken under these builds, so I wanted to get the test working. This mainly consisted of lots of s/u'foo'/unicode('foo', 'unicode-escape') and some judicious testing of test_support.have_unicode. This is very very far from being the only test which fails without unicode literals, but it's a start... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 13:06 Message: Logged In: YES user_id=6656 Fair enough (I always forget about raw strings). Committed as revision 1.15 of Lib/test/test_array.py ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-14 22:19 Message: Logged In: YES user_id=21627 The patch looks good to me, but I would a) use "ascii" as the encoding if there are no escapes, and b) use raw strings ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555382&group_id=5470 From noreply@sourceforge.net Wed May 15 14:30:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 06:30:06 -0700 Subject: [Patches] [ python-Patches-554807 ] Add _winreg support for Cygwin Message-ID: Patches item #554807, was opened at 2002-05-11 12:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Add _winreg support for Cygwin Initial Comment: This adds _winreg support to Cygwin Python without dependencies on other Windows modules. For platforms in which MS_WINDOWS isn't defined, this reports the OSError exception instead of WindowsErr. It also uses the non-MBCS versions of registry access in this case. Some minor changes to _winreg.c were made to clean up compiler warnings from GCC. setup.py was changed to create a dynamic _winreg module under cygwin. There are also some earlier changes in the patch file to skip the import test (due to Cygwin fork issues), and to require libintl when building _locale under Cygwin. ---------------------------------------------------------------------- >Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-15 13:30 Message: Logged In: YES user_id=329402 It sounds like the patches need some tweaking (my testing had passed but was certainly limited). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 12:57 Message: Logged In: YES user_id=21627 Yes, but you are wrong assuming that the *A functions expect Latin-1. Instead, they expect char* encoded as CP_ACP, which is known as "mbcs" in Python. The *W functions do *not* expect multi-byte strings, but Unicode strings. Notice that _winreg also calls the *A functions, even in MSVC builds. So I think converting Unicode to Latin-1 is definitely incorrect. ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-15 12:48 Message: Logged In: YES user_id=329402 Windows supplies two versions of the relevant functions. The Cygwin version (at least as built) uses the ANSI versions, as indicated by the A at the end of the symbol names: $ nm _winreg.o | grep RegQueryValue U _RegQueryValueA@16 U _RegQueryValueExA@24 As opposed to the "Windows Unicode/wide-char" functions, which end in W and require MBCS functions to decode. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-14 22:23 Message: Logged In: YES user_id=21627 Can you please explain why not using MBCS is the right thing? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 From noreply@sourceforge.net Wed May 15 16:13:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 08:13:07 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 12:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-15 10:13 Message: Logged In: YES user_id=80475 Since this would also go into int, float, and other places, consider factoring it to abstract.c as PyObject_GenericGetNoneDoc or some such. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-15 07:51 Message: Logged In: YES user_id=11105 The attatched patch (stringobject.diff) implements this behaviour: The doc string of 'str' is unchanged, but string objects have a __doc__ attribute of None. The same could (and should) be done for int, float, and probably more types as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 12:08 Message: Logged In: YES user_id=11105 Or maybe add a __doc__ tp_member (or whatever) which always returns None? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 12:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 07:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 09:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 09:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 03:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Wed May 15 19:25:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 11:25:08 -0700 Subject: [Patches] [ python-Patches-555929 ] Cygwin AH_BOTTOM cleanup patch Message-ID: Patches item #555929, was opened at 2002-05-14 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 Category: Build Group: Python 2.3 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin AH_BOTTOM cleanup patch Initial Comment: This patch complies with the following request found near the top of configure.in: # This is for stuff that absolutely must end up in pyconfig.h. # Please use pyport.h instead, if possible. I tested this patch under Cygwin, Win32, and Red Hat Linux. Python built and ran successfully on each of these platforms. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 20:25 Message: Logged In: YES user_id=21627 How did you test this patch? When I build Python on Linux, I get tons of error messages In file included from /usr/include/limits.h:152, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:117, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:11, from Include/Python.h:28, from Python/frozenmain.c:4: /usr/include/bits/xopen_lim.h:123: warning: `LONG_BIT' redefined which come from pyport.h being included before limits.h. Backing the patch out; try again. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 13:55 Message: Logged In: YES user_id=86216 Committed as: configure 1.306 configure.in 1.316 pyconfig.h.in 1.34 Include/Python.h 2.47 Include/pyport.h 2.48 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:03 Message: Logged In: YES user_id=21627 Sounds good; please install this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 From noreply@sourceforge.net Wed May 15 20:24:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 15 May 2002 12:24:20 -0700 Subject: [Patches] [ python-Patches-555929 ] Cygwin AH_BOTTOM cleanup patch Message-ID: Patches item #555929, was opened at 2002-05-14 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin AH_BOTTOM cleanup patch Initial Comment: This patch complies with the following request found near the top of configure.in: # This is for stuff that absolutely must end up in pyconfig.h. # Please use pyport.h instead, if possible. I tested this patch under Cygwin, Win32, and Red Hat Linux. Python built and ran successfully on each of these platforms. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-15 11:24 Message: Logged In: YES user_id=86216 > How did you test this patch? I tested under Red Linux 7.1 configured with "--enable-shared". Note that my version of gcc is different than yours: $ gcc --version 2.96 > which come from pyport.h being included before limits.h. I was concerned about moving where pyport.h is included. I should have made this concern explicit. > Backing the patch out; No problem -- sorry for the trouble. > try again. Should I leave the #include "pyport.h" in its original location and move the DL_IMPORT stuff after it? Or, should I just try moving #include "pyport.h" to right after the #include ? Since I can't reproduce the problem, I'm afraid that my next attempt may cause problems too. Would you be willing to retry my first patch and just move the #include "pyport.h" below the #include ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 10:25 Message: Logged In: YES user_id=21627 How did you test this patch? When I build Python on Linux, I get tons of error messages In file included from /usr/include/limits.h:152, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:117, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:11, from Include/Python.h:28, from Python/frozenmain.c:4: /usr/include/bits/xopen_lim.h:123: warning: `LONG_BIT' redefined which come from pyport.h being included before limits.h. Backing the patch out; try again. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 03:55 Message: Logged In: YES user_id=86216 Committed as: configure 1.306 configure.in 1.316 pyconfig.h.in 1.34 Include/Python.h 2.47 Include/pyport.h 2.48 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-14 14:03 Message: Logged In: YES user_id=21627 Sounds good; please install this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 From noreply@sourceforge.net Thu May 16 11:28:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 May 2002 03:28:06 -0700 Subject: [Patches] [ python-Patches-555929 ] Cygwin AH_BOTTOM cleanup patch Message-ID: Patches item #555929, was opened at 2002-05-14 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin AH_BOTTOM cleanup patch Initial Comment: This patch complies with the following request found near the top of configure.in: # This is for stuff that absolutely must end up in pyconfig.h. # Please use pyport.h instead, if possible. I tested this patch under Cygwin, Win32, and Red Hat Linux. Python built and ran successfully on each of these platforms. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 12:28 Message: Logged In: YES user_id=21627 Can you please explain why moving pyport.h is necessary? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 21:24 Message: Logged In: YES user_id=86216 > How did you test this patch? I tested under Red Linux 7.1 configured with "--enable-shared". Note that my version of gcc is different than yours: $ gcc --version 2.96 > which come from pyport.h being included before limits.h. I was concerned about moving where pyport.h is included. I should have made this concern explicit. > Backing the patch out; No problem -- sorry for the trouble. > try again. Should I leave the #include "pyport.h" in its original location and move the DL_IMPORT stuff after it? Or, should I just try moving #include "pyport.h" to right after the #include ? Since I can't reproduce the problem, I'm afraid that my next attempt may cause problems too. Would you be willing to retry my first patch and just move the #include "pyport.h" below the #include ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 20:25 Message: Logged In: YES user_id=21627 How did you test this patch? When I build Python on Linux, I get tons of error messages In file included from /usr/include/limits.h:152, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:117, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:11, from Include/Python.h:28, from Python/frozenmain.c:4: /usr/include/bits/xopen_lim.h:123: warning: `LONG_BIT' redefined which come from pyport.h being included before limits.h. Backing the patch out; try again. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 13:55 Message: Logged In: YES user_id=86216 Committed as: configure 1.306 configure.in 1.316 pyconfig.h.in 1.34 Include/Python.h 2.47 Include/pyport.h 2.48 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 00:03 Message: Logged In: YES user_id=21627 Sounds good; please install this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 From noreply@sourceforge.net Thu May 16 13:16:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 May 2002 05:16:19 -0700 Subject: [Patches] [ python-Patches-555883 ] fcntl.ioctl2 - fix for bug #555817 Message-ID: Patches item #555883, was opened at 2002-05-14 22:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: fcntl.ioctl2 - fix for bug #555817 Initial Comment: See bug #555817 - the basics of it are that some ioctl calls rely on both getting back the modified third argument and the return code. Python's ioctl implementation doesn't allow this. Linux docs explicitly mention this, the solaris docs also say it's possible (but not so explicitly). Anyway, this fix is a patch to fcntlmodule.c and a test_ioctl.py script - it merely tries to use TIOCGPGRP and compares it to os.getpgrp(). ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 22:16 Message: Logged In: YES user_id=29957 marking as invalid in favour of a mutable array arg. see bug #555817 for details. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-15 10:51 Message: Logged In: YES user_id=29957 the else-bit - no reason, I'll fix it before I commit the patch. I'll write the docs today and attach them. ioctl2 isn't my favourite, either, but I can't think of a better name. ioctl_that_returns_a_tuple() isn't any better, ioctlt(), nioctl()... the '2' thing is reasonably common in C libraries... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 08:13 Message: Logged In: YES user_id=21627 The patch looks good to me, but it probably needs accompanying documentation patch. Also: - why do you put the ParseTuple in an if-else? It is common to put the else part on the function level. - would it be possible to find a more precise name than ioctl2? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555883&group_id=5470 From noreply@sourceforge.net Thu May 16 13:26:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 May 2002 05:26:43 -0700 Subject: [Patches] [ python-Patches-555929 ] Cygwin AH_BOTTOM cleanup patch Message-ID: Patches item #555929, was opened at 2002-05-14 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin AH_BOTTOM cleanup patch Initial Comment: This patch complies with the following request found near the top of configure.in: # This is for stuff that absolutely must end up in pyconfig.h. # Please use pyport.h instead, if possible. I tested this patch under Cygwin, Win32, and Red Hat Linux. Python built and ran successfully on each of these platforms. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-16 04:26 Message: Logged In: YES user_id=86216 > Can you please explain why moving pyport.h is necessary? It's not. It seemed cleaner, albeit riskier. Attached is the second version of my patch. It's identical to the first version except for the Include/Python.h hunk. The changes to Include/Python.h leave the #include "pyport.h" in its original location. Instead, I moved the DL_IMPORT stuff to after the #include "pyport.h". I tested under Cygwin, Win32, and Linux (i.e., gcc 2.96) again without any problems. Please test under your Linux environment. If successful, should we have others test on other platforms to prevent a repeat of this "fiasco?" ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 02:28 Message: Logged In: YES user_id=21627 Can you please explain why moving pyport.h is necessary? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 11:24 Message: Logged In: YES user_id=86216 > How did you test this patch? I tested under Red Linux 7.1 configured with "--enable-shared". Note that my version of gcc is different than yours: $ gcc --version 2.96 > which come from pyport.h being included before limits.h. I was concerned about moving where pyport.h is included. I should have made this concern explicit. > Backing the patch out; No problem -- sorry for the trouble. > try again. Should I leave the #include "pyport.h" in its original location and move the DL_IMPORT stuff after it? Or, should I just try moving #include "pyport.h" to right after the #include ? Since I can't reproduce the problem, I'm afraid that my next attempt may cause problems too. Would you be willing to retry my first patch and just move the #include "pyport.h" below the #include ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 10:25 Message: Logged In: YES user_id=21627 How did you test this patch? When I build Python on Linux, I get tons of error messages In file included from /usr/include/limits.h:152, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:117, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:11, from Include/Python.h:28, from Python/frozenmain.c:4: /usr/include/bits/xopen_lim.h:123: warning: `LONG_BIT' redefined which come from pyport.h being included before limits.h. Backing the patch out; try again. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 03:55 Message: Logged In: YES user_id=86216 Committed as: configure 1.306 configure.in 1.316 pyconfig.h.in 1.34 Include/Python.h 2.47 Include/pyport.h 2.48 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-14 14:03 Message: Logged In: YES user_id=21627 Sounds good; please install this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 From noreply@sourceforge.net Thu May 16 13:36:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 May 2002 05:36:35 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 13:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-16 08:36 Message: Logged In: YES user_id=6380 I'm very sympathetic, but have no time to review this just yet. Please don't check in without my approval -- this is awfully deep shit (see the history of the __doc__ descriptor in typeobject.c). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-15 11:13 Message: Logged In: YES user_id=80475 Since this would also go into int, float, and other places, consider factoring it to abstract.c as PyObject_GenericGetNoneDoc or some such. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-15 08:51 Message: Logged In: YES user_id=11105 The attatched patch (stringobject.diff) implements this behaviour: The doc string of 'str' is unchanged, but string objects have a __doc__ attribute of None. The same could (and should) be done for int, float, and probably more types as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 13:08 Message: Logged In: YES user_id=11105 Or maybe add a __doc__ tp_member (or whatever) which always returns None? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 13:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 04:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Thu May 16 20:06:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 May 2002 12:06:13 -0700 Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks Message-ID: Patches item #432401, was opened at 2001-06-12 15:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Postponed Priority: 6 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode encoding error callbacks Initial Comment: This patch adds unicode error handling callbacks to the encode functionality. With this patch it's possible to not only pass 'strict', 'ignore' or 'replace' as the errors argument to encode, but also a callable function, that will be called with the encoding name, the original unicode object and the position of the unencodable character. The callback must return a replacement unicode object that will be encoded instead of the original character. For example replacing unencodable characters with XML character references can be done in the following way. u"aäoöuüß".encode( "ascii", lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos]) ) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-05-16 21:06 Message: Logged In: YES user_id=89016 OK, PyUnicode_TranslateCharmap is finished too. As the errors argument is again not exposed to Python it can't really be tested. Should we add errors as an optional argument to unicode.translate? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-01 19:57 Message: Logged In: YES user_id=89016 OK, PyUnicode_EncodeDecimal is done (diff8.txt), but as the errors argument can't be accessed from Python code, there's not much testing for this. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-20 17:34 Message: Logged In: YES user_id=89016 A new idea for the interface between the codec and the callback: Maybe we could have new exception classes UnicodeEncodeError, UnicodeDecodeError and UnicodeTranslateError derived from UnicodeError. They have all the attributes that are passed as an argument tuple in the current version: string: the original string start: the start position of the unencodable characters/undecodable bytes end: the end position+1 of the unencodable characters/undecodable bytes. reason: the a string, that explains, why the encoding/decoding doesn't work. There is no data object, because when a codec wants to pass extended information to the callback it can do this via a derived class. It might be better to move these attributes to the base class UnicodeError, but this might have backwards compatibility problems. With this method we really can have one global registry for all callbacks, because for callback names that must work with encoding *and* decoding *and* translating (i.e. "strict", "replace" and "ignore"), the callback can check which type of exception was passed, so "replace" can e.g. look like this: def replace(exc): if isinstance(exc, UnicodeDecodeError): return ("?", exc.end) else: return (u"?"*(exc.end-exc.start), exc.end) Another possibility would be to do the commucation callback->codec by assigning to attributes of the exception object. The resyncronisation position could even be preassigned to end, so the callback only needs to specify the replacement in most cases: def replace(exc): if isinstance(exc, UnicodeDecodeError): exc.replacement = "?" else: exc.replacement = u"?"*(exc.end-exc.start) As many of the assignments can now be done on the C level without having to allocate Python objects (except for the replacement string and the reason), this version might even be faster, especially if we allow the codec to reuse the exception object for the next call to the callback. Does this make sense, or is this to fancy? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-18 21:24 Message: Logged In: YES user_id=89016 And here is the test script (test_codeccallbacks.py) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-18 21:22 Message: Logged In: YES user_id=89016 OK, here is the current version of the patch (diff7.txt). PyUnicode_EncodeDecimal and PyUnicode_TranslateCharmap are still missing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-17 22:50 Message: Logged In: YES user_id=89016 > About the difference between encoding > and decoding: you shouldn't just look > at the case where you work with Unicode > and strings, e.g. take the rot-13 codec > which works on strings only or other > codecs which translate objects into > strings and vice-versa. unicode.encode encodes to str and str.decode decodes to unicode, even for rot-13: >>> u"gürk".encode("rot13") 't\xfcex' >>> "gürk".decode("rot13") u't\xfcex' >>> u"gürk".decode("rot13") Traceback (most recent call last): File "", line 1, in ? AttributeError: 'unicode' object has no attribute 'decode' >>> "gürk".encode("rot13") Traceback (most recent call last): File "", line 1, in ? File "/home/walter/Python-current- readonly/dist/src/Lib/encodings/rot_13.py", line 18, in encode return codecs.charmap_encode(input,errors,encoding_map) UnicodeError: ASCII decoding error: ordinal not in range (128) Here the str is converted to unicode first, before encode is called, but the conversion to unicode fails. Is there an example where something else happens? > Error handling has to be flexible enough > to handle all these situations. Since > the codecs know best how to handle the > situations, I'd make this an implementation > detail of the codec and leave the > behaviour undefined in the general case. OK, but we should suggest, that for encoding unencodable characters are collected and for decoding seperate byte sequences that are considered broken by the codec are passed to the callback: i.e for decoding the handler will never get all broken data in one call, e.g. for "\u30\Uffffffff".decode("unicode-escape") the handler will be called twice (once for "\u30" and "truncated \u escape" as the reason and once for "\Uffffffff" and "illegal character" as the reason.) > For the existing codecs, backward > compatibility should be maintained, > if at all possible. If the patch gets > overly complicated because of this, > we may have to provide a downgrade solution > for this particular problem (I don't think > replace is used in any computational context, > though, since you can never be sure how > many replacement character do get > inserted, so the case may not be > that realistic). > > Raising an exception for the charmap codec > is the right way to go, IMHO. I would > consider the current behaviour a bug. OK, this is implemented in PyUnicode_EncodeCharmap now, and collecting unencodable characters works too. I completely changed the implementation, because the stack approach would have gotten much more complicated when unencodable characters are collected. > For new codecs, I think we should > suggest that replace tries to collect > as much illegal data as possible before > invoking the error handler. The handler > should be aware of the fact that it > won't necessarily get all the broken > data in one call. OK for encoders, for decoders see above. > About the codec error handling > registry: You seem to be using a > Unicode specific approach here. > I'd rather like to see a generic > approach which uses the API > we discussed earlier. Would that be possible? The handlers in the registry are all Unicode specific. and they are different for encoding and for decoding. I renamed the function because of your comment from 2001-06-13 10:05 (which becomes exceedingly difficult to find on this long page! ;)). > In that case, the codec API should > probably be called > codecs.register_error('myhandler', myhandler). > > Does that make sense ? We could require that unique names are used for custom handlers, but for the standard handlers we do have name collisions. To prevent them, we could either remove them from the registry and require that the codec implements the error handling for those itself, or we could to some fiddling, so that u"üöä".encode("ascii", "replace") becomes u"üöä".encode("ascii", "unicodeencodereplace") behind the scenes. But I think two unicode specific registries are much simpler to handle. > BTW, the patch which uses the callback > registry does not seem to be available > on this SF page (the last patch still > converts the errors argument to a > PyObject, which shouldn't be needed > anymore with the new approach). > Can you please upload your > latest version? OK, I'll upload a preliminary version tomorrow. PyUnicode_EncodeDecimal and PyUnicode_TranslateCharmap are still missing, but otherwise the patch seems to be finished. All decoders work and the encoders collect unencodable characters and implement the handling of known callback handler names themselves. As PyUnicode_EncodeDecimal is only used by the int, long, float, and complex constructors, I'd love to get rid of the errors argument, but for completeness sake, I'll implement the callback functionality. > Note that the highlighting codec > would make a nice example > for the new feature. This could be part of the codec callback test script, which I've started to write. We could kill two birds with one stone here: 1. Test the implementation. 2. Document and advocate what is possible with the patch. Another idea: we could have as an example a decoding handler that relaxes the UTF-8 minimal encoding restriction, e.g. def relaxedutf8(enc, uni, startpos, endpos, reason, data): if uni[startpos:startpos+2] == u"\xc0\x80": return (u"\x00", startpos+2) else: raise UnicodeError(...) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-04-17 21:40 Message: Logged In: YES user_id=38388 Sorry for the late response. About the difference between encoding and decoding: you shouldn't just look at the case where you work with Unicode and strings, e.g. take the rot-13 codec which works on strings only or other codecs which translate objects into strings and vice-versa. Error handling has to be flexible enough to handle all these situations. Since the codecs know best how to handle the situations, I'd make this an implementation detail of the codec and leave the behaviour undefined in the general case. For the existing codecs, backward compatibility should be maintained, if at all possible. If the patch gets overly complicated because of this, we may have to provide a downgrade solution for this particular problem (I don't think replace is used in any computational context, though, since you can never be sure how many replacement character do get inserted, so the case may not be that realistic). Raising an exception for the charmap codec is the right way to go, IMHO. I would consider the current behaviour a bug. For new codecs, I think we should suggest that replace tries to collect as much illegal data as possible before invoking the error handler. The handler should be aware of the fact that it won't necessarily get all the broken data in one call. About the codec error handling registry: You seem to be using a Unicode specific approach here. I'd rather like to see a generic approach which uses the API we discussed earlier. Would that be possible ? In that case, the codec API should probably be called codecs.register_error('myhandler', myhandler). Does that make sense ? BTW, the patch which uses the callback registry does not seem to be available on this SF page (the last patch still converts the errors argument to a PyObject, which shouldn't be needed anymore with the new approach). Can you please upload your latest version ? Note that the highlighting codec would make a nice example for the new feature. Thanks. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-17 12:21 Message: Logged In: YES user_id=89016 Another note: the patch will change the meaning of charmap encoding slightly: currently "replace" will put a ? into the output, even if ? is not in the mapping, i.e. codecs.charmap_encode(u"c", "replace", {ord("a"): ord ("b")}) will return ('?', 1). With the patch the above example will raise an exception. Off course with the patch many more replace characters can appear, so it is vital that for the replacement string the mapping is done. Is this semantic change OK? (I guess all of the existing codecs have a mapping ord("?")->ord("?")) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-15 18:19 Message: Logged In: YES user_id=89016 So this means that the encoder can collect illegal characters and pass it to the callback. "replace" will replace this with (end-start)*u"?". Decoders don't collect all illegal byte sequences, but call the callback once for every byte sequence that has been found illegal and "replace" will replace it with u"?". Does this make sense? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-15 18:06 Message: Logged In: YES user_id=89016 For encoding it's always (end-start)*u"?": >>> u"ää".encode("ascii", "replace") '??' But for decoding, it is neither nor: >>> "\Ux\U".decode("unicode-escape", "replace") u'\ufffd\ufffd' i.e. a sequence of 5 illegal characters was replace by two replacement characters. This might mean that decoders can't collect all the illegal characters and call the callback once. They might have to call the callback for every single illegal byte sequence to get the old behaviour. (It seems that this patch would be much, much simpler, if we only change the encoders) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-08 19:36 Message: Logged In: YES user_id=38388 Hmm, whatever it takes to maintain backwards compatibility. Do you have an example ? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-08 18:31 Message: Logged In: YES user_id=89016 What should replace do: Return u"?" or (end-start)*u"?" ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-08 16:15 Message: Logged In: YES user_id=38388 Sounds like a good idea. Please keep the encoder and decoder APIs symmetric, though, ie. add the slice information to both APIs. The slice should use the same format as Python's standard slices, that is left inclusive, right exclusive. I like the highlighting feature ! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-08 00:09 Message: Logged In: YES user_id=89016 I'm think about extending the API a little bit: Consider the following example: >>> "\u1".decode("unicode-escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 2: truncated \uXXXX escape The error message is a lie: Not the '1' in position 2 is the problem, but the complete truncated sequence '\u1'. For this the decoder should pass a start and an end position to the handler. For encoding this would be useful too: Suppose I want to have an encoder that colors the unencodable character via an ANSI escape sequences. Then I could do the following: >>> import codecs >>> def color(enc, uni, pos, why, sta): ... return (u"\033[1m<%d>\033[0m" % ord(uni[pos]), pos+1) ... >>> codecs.register_unicodeencodeerrorhandler("color", color) >>> u"aäüöo".encode("ascii", "color") 'a\x1b[1m<228>\x1b[0m\x1b[1m<252>\x1b[0m\x1b[1m<246>\x1b [0mo' But here the sequences "\x1b[0m\x1b[1m" are not needed. To fix this problem the encoder could collect as many unencodable characters as possible and pass those to the error callback in one go (passing a start and end+1 position). This fixes the above problem and reduces the number of calls to the callback, so it should speed up the algorithms in case of custom encoding names. (And it makes the implementation very interesting ;)) What do you think? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-07 02:29 Message: Logged In: YES user_id=89016 I started from scratch, and the current state is this: Encoding mostly works (except that I haven't changed TranslateCharmap and EncodeDecimal yet) and most of the decoding stuff works (DecodeASCII and DecodeCharmap are still unchanged) and the decoding callback helper isn't optimized for the "builtin" names yet (i.e. it still calls the handler). For encoding the callback helper knows how to handle "strict", "replace", "ignore" and "xmlcharrefreplace" itself and won't call the callback. This should make the encoder fast enough. As callback name string comparison results are cached it might even be faster than the original. The patch so far didn't require any changes to unicodeobject.h, stringobject.h or stringobject.c ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-05 17:49 Message: Logged In: YES user_id=38388 Walter, are you making any progress on the new scheme we discussed on the mailing list (adding an error handler registry much like the codec registry itself instead of trying to redo the complete codec API) ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 12:38 Message: Logged In: YES user_id=38388 I am postponing this patch until the PEP process has started. This feature won't make it into Python 2.2. Walter, you may want to reference this patch in the PEP. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 12:53 Message: Logged In: YES user_id=38388 I think we ought to summarize these changes in a PEP to get some more feedback and testing from others as well. I'll look into this after I'm back from vacation on the 10.09. Given the release schedule I am not sure whether this feature will make it into 2.2. The size of the patch is huge and probably needs a lot of testing first. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-27 05:55 Message: Logged In: YES user_id=89016 Changing the decoding API is done now. There are new functions codec.register_unicodedecodeerrorhandler and codec.lookup_unicodedecodeerrorhandler. Only the standard handlers for 'strict', 'ignore' and 'replace' are preregistered. There may be many reasons for decoding errors in the byte string, so I added an additional argument to the decoding API: reason, which gives the reason for the failure, e.g.: >>> "\U1111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 8: truncated \UXXXXXXXX escape >>> "\U11111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 9: illegal Unicode character For symmetry I added this to the encoding API too: >>> u"\xff".encode("ascii") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'ascii' can't decode byte 0xff in position 0: ordinal not in range(128) The parameters passed to the callbacks now are: encoding, unicode, position, reason, state. The encoding and decoding API for strings has been adapted too, so now the new API should be usable everywhere: >>> unicode("a\xffb\xffc", "ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' >>> "a\xffb\xffc".decode("ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' I had a problem with the decoding API: all the functions in _codecsmodule.c used the t# format specifier. I changed that to O! with &PyString_Type, because otherwise we would have the problem that the decoding API would must pass buffer object around instead of strings, and the callback would have to call str() on the buffer anyway to access a specific character, so this wouldn't be any faster than calling str() on the buffer before decoding. It seems that buffers aren't used anyway. I changed all the old function to call the new ones so bugfixes don't have to be done in two places. There are two exceptions: I didn't change PyString_AsEncodedString and PyString_AsDecodedString because they are documented as deprecated anyway (although they are called in a few spots) This means that I duplicated part of their functionality in PyString_AsEncodedObjectEx and PyString_AsDecodedObjectEx. There are still a few spots that call the old API: E.g. PyString_Format still calls PyUnicode_Decode (but with strict decoding) because it passes the rest of the format string to PyUnicode_Format when it encounters a Unicode object. Should we switch to the new API everywhere even if strict encoding/decoding is used? The size of this patch begins to scare me. I guess we need an extensive test script for all the new features and documentation. I hope you have time to do that, as I'll be busy with other projects in the next weeks. (BTW, I have't touched PyUnicode_TranslateCharmap yet.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-23 19:03 Message: Logged In: YES user_id=89016 New version of the patch with the error handling callback registry. > > OK, done, now there's a > > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > > codecs.escapereplace_unicodeencode_errors > > that uses \u (or \U if x>0xffff (with a wide build > > of Python)). > > Great! Now PyCodec_EscapeReplaceUnicodeEncodeErrors uses \x in addition to \u and \U where appropriate. > > [...] > > But for special one-shot error handlers, it might still be > > useful to pass the error handler directly, so maybe we > > should leave error as PyObject *, but implement the > > registry anyway? > > Good idea ! > > One minor nit: codecs.registerError() should be named > codecs.register_errorhandler() to be more inline with > the Python coding style guide. OK, but these function are specific to unicode encoding, so now the functions are called: codecs.register_unicodeencodeerrorhandler codecs.lookup_unicodeencodeerrorhandler Now all callbacks (including the new ones: "xmlcharrefreplace" and "escapereplace") are registered in the codecs.c/_PyCodecRegistry_Init so using them is really simple: u"gürk".encode("ascii", "xmlcharrefreplace") ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-13 13:26 Message: Logged In: YES user_id=38388 > > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > > with \uxxxx replacement callback. > > > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > > I'd rather leave the special encoder in place, > > > > since it is being used a lot in Python and > > > > probably some applications too. > > > > > > It would be a slowdown. But callbacks open many > > > possiblities. > > > > True, but in this case I believe that we should stick with > > the native implementation for "unicode-escape". Having > > a standard callback error handler which does the \uXXXX > > replacement would be nice to have though, since this would > > also be usable with lots of other codecs (e.g. all the > > code page ones). > > OK, done, now there's a > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > codecs.escapereplace_unicodeencode_errors > that uses \u (or \U if x>0xffff (with a wide build > of Python)). Great ! > > [...] > > > Should the old TranslateCharmap map to the new > > > TranslateCharmapEx and inherit the > > > "multicharacter replacement" feature, > > > or should I leave it as it is? > > > > If possible, please also add the multichar replacement > > to the old API. I think it is very useful and since the > > old APIs work on raw buffers it would be a benefit to have > > the functionality in the old implementation too. > > OK! I will try to find the time to implement that in the > next days. Good. > > [Decoding error callbacks] > > > > About the return value: > > > > I'd suggest to always use the same tuple interface, e.g. > > > > callback(encoding, input_data, input_position, > state) -> > > (output_to_be_appended, new_input_position) > > > > (I think it's better to use absolute values for the > > position rather than offsets.) > > > > Perhaps the encoding callbacks should use the same > > interface... what do you think ? > > This would make the callback feature hypergeneric and a > little slower, because tuples have to be created, but it > (almost) unifies the encoding and decoding API. ("almost" > because, for the encoder output_to_be_appended will be > reencoded, for the decoder it will simply be appended.), > so I'm for it. That's the point. Note that I don't think the tuple creation will hurt much (see the make_tuple() API in codecs.c) since small tuples are cached by Python internally. > I implemented this and changed the encoders to only > lookup the error handler on the first error. The UCS1 > encoder now no longer uses the two-item stack strategy. > (This strategy only makes sense for those encoder where > the encoding itself is much more complicated than the > looping/callback etc.) So now memory overflow tests are > only done, when an unencodable error occurs, so now the > UCS1 encoder should be as fast as it was without > error callbacks. > > Do we want to enforce new_input_position>input_position, > or should jumping back be allowed? No; moving backwards should be allowed (this may be useful in order to resynchronize with the input data). > Here's is the current todo list: > 1. implement a new TranslateCharmap and fix the old. > 2. New encoding API for string objects too. > 3. Decoding > 4. Documentation > 5. Test cases > > I'm thinking about a different strategy for implementing > callbacks > (see http://mail.python.org/pipermail/i18n-sig/2001- > July/001262.html) > > We coould have a error handler registry, which maps names > to error handlers, then it would be possible to keep the > errors argument as "const char *" instead of "PyObject *". > Currently PyCodec_UnicodeEncodeHandlerForObject is a > backwards compatibility hack that will never go away, > because > it's always more convenient to type > u"...".encode("...", "strict") > instead of > import codecs > u"...".encode("...", codecs.raise_encode_errors) > > But with an error handler registry this function would > become the official lookup method for error handlers. > (PyCodec_LookupUnicodeEncodeErrorHandler?) > Python code would look like this: > --- > def xmlreplace(encoding, unicode, pos, state): > return (u"&#%d;" % ord(uni[pos]), pos+1) > > import codec > > codec.registerError("xmlreplace",xmlreplace) > --- > and then the following call can be made: > u"äöü".encode("ascii", "xmlreplace") > As soon as the first error is encountered, the encoder uses > its builtin error handling method if it recognizes the name > ("strict", "replace" or "ignore") or looks up the error > handling function in the registry if it doesn't. In this way > the speed for the backwards compatible features is the same > as before and "const char *error" can be kept as the > parameter to all encoding functions. For speed common error > handling names could even be implemented in the encoder > itself. > > But for special one-shot error handlers, it might still be > useful to pass the error handler directly, so maybe we > should leave error as PyObject *, but implement the > registry anyway? Good idea ! One minor nit: codecs.registerError() should be named codecs.register_errorhandler() to be more inline with the Python coding style guide. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-12 13:03 Message: Logged In: YES user_id=89016 > > [...] > > so I guess we could change the replace handler > > to always return u'?'. This would make the > > implementation a little bit simpler, but the > > explanation of the callback feature *a lot* > > simpler. > > Go for it. OK, done! > [...] > > > Could you add these docs to the Misc/unicode.txt > > > file ? I will eventually take that file and turn > > > it into a PEP which will then serve as general > > > documentation for these things. > > > > I could, but first we should work out how the > > decoding callback API will work. > > Ok. BTW, Barry Warsaw already did the work of converting > the unicode.txt to PEP 100, so the docs should eventually > go there. OK. I guess it would be best to do this when everything is finished. > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > with \uxxxx replacement callback. > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > I'd rather leave the special encoder in place, > > > since it is being used a lot in Python and > > > probably some applications too. > > > > It would be a slowdown. But callbacks open many > > possiblities. > > True, but in this case I believe that we should stick with > the native implementation for "unicode-escape". Having > a standard callback error handler which does the \uXXXX > replacement would be nice to have though, since this would > also be usable with lots of other codecs (e.g. all the > code page ones). OK, done, now there's a PyCodec_EscapeReplaceUnicodeEncodeErrors/ codecs.escapereplace_unicodeencode_errors that uses \u (or \U if x>0xffff (with a wide build of Python)). > > For example: > > > > Why can't I print u"gürk"? > > > > is probably one of the most frequently asked > > questions in comp.lang.python. For printing > > Unicode stuff, print could be extended the use an > > error handling callback for Unicode strings (or > > objects where __str__ or tp_str returns a Unicode > > object) instead of using str() which always > > returns an 8bit string and uses strict encoding. > > There might even be a > > sys.setprintencodehandler()/sys.getprintencodehandler () > > There already is a print callback in Python (forgot the > name of the hook though), so this should be possible by > providing the encoding logic in the hook. True: sys.displayhook > [...] > > Should the old TranslateCharmap map to the new > > TranslateCharmapEx and inherit the > > "multicharacter replacement" feature, > > or should I leave it as it is? > > If possible, please also add the multichar replacement > to the old API. I think it is very useful and since the > old APIs work on raw buffers it would be a benefit to have > the functionality in the old implementation too. OK! I will try to find the time to implement that in the next days. > [Decoding error callbacks] > > About the return value: > > I'd suggest to always use the same tuple interface, e.g. > > callback(encoding, input_data, input_position, state) -> > (output_to_be_appended, new_input_position) > > (I think it's better to use absolute values for the > position rather than offsets.) > > Perhaps the encoding callbacks should use the same > interface... what do you think ? This would make the callback feature hypergeneric and a little slower, because tuples have to be created, but it (almost) unifies the encoding and decoding API. ("almost" because, for the encoder output_to_be_appended will be reencoded, for the decoder it will simply be appended.), so I'm for it. I implemented this and changed the encoders to only lookup the error handler on the first error. The UCS1 encoder now no longer uses the two-item stack strategy. (This strategy only makes sense for those encoder where the encoding itself is much more complicated than the looping/callback etc.) So now memory overflow tests are only done, when an unencodable error occurs, so now the UCS1 encoder should be as fast as it was without error callbacks. Do we want to enforce new_input_position>input_position, or should jumping back be allowed? > > > > One additional note: It is vital that errors > > > > is an assignable attribute of the StreamWriter. > > > > > > It is already ! > > > > I know, but IMHO it should be documented that an > > assignable errors attribute must be supported > > as part of the official codec API. > > > > Misc/unicode.txt is not clear on that: > > """ > > It is not required by the Unicode implementation > > to use these base classes, only the interfaces must > > match; this allows writing Codecs as extension types. > > """ > > Good point. I'll add that to the PEP 100. OK. Here's is the current todo list: 1. implement a new TranslateCharmap and fix the old. 2. New encoding API for string objects too. 3. Decoding 4. Documentation 5. Test cases I'm thinking about a different strategy for implementing callbacks (see http://mail.python.org/pipermail/i18n-sig/2001- July/001262.html) We coould have a error handler registry, which maps names to error handlers, then it would be possible to keep the errors argument as "const char *" instead of "PyObject *". Currently PyCodec_UnicodeEncodeHandlerForObject is a backwards compatibility hack that will never go away, because it's always more convenient to type u"...".encode("...", "strict") instead of import codecs u"...".encode("...", codecs.raise_encode_errors) But with an error handler registry this function would become the official lookup method for error handlers. (PyCodec_LookupUnicodeEncodeErrorHandler?) Python code would look like this: --- def xmlreplace(encoding, unicode, pos, state): return (u"&#%d;" % ord(uni[pos]), pos+1) import codec codec.registerError("xmlreplace",xmlreplace) --- and then the following call can be made: u"äöü".encode("ascii", "xmlreplace") As soon as the first error is encountered, the encoder uses its builtin error handling method if it recognizes the name ("strict", "replace" or "ignore") or looks up the error handling function in the registry if it doesn't. In this way the speed for the backwards compatible features is the same as before and "const char *error" can be kept as the parameter to all encoding functions. For speed common error handling names could even be implemented in the encoder itself. But for special one-shot error handlers, it might still be useful to pass the error handler directly, so maybe we should leave error as PyObject *, but implement the registry anyway? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-10 14:29 Message: Logged In: YES user_id=38388 Ok, here we go... > > > raise an exception). U+FFFD characters in the > replacement > > > string will be replaced with a character that the > encoder > > > chooses ('?' in all cases). > > > > Nice. > > But the special casing of U+FFFD makes the interface > somewhat > less clean than it could be. It was only done to be 100% > backwards compatible. With the original "replace" > error > handling the codec chose the replacement character. But as > far as I can tell none of the codecs uses anything other > than '?', True. > so I guess we could change the replace handler > to always return u'?'. This would make the implementation a > little bit simpler, but the explanation of the callback > feature *a lot* simpler. Go for it. > And if you still want to handle > an unencodable U+FFFD, you can write a special callback for > that, e.g. > > def FFFDreplace(enc, uni, pos): > if uni[pos] == "\ufffd": > return u"?" > else: > raise UnicodeError(...) > > > ...docs... > > > > Could you add these docs to the Misc/unicode.txt file ? I > > will eventually take that file and turn it into a PEP > which > > will then serve as general documentation for these things. > > I could, but first we should work out how the decoding > callback API will work. Ok. BTW, Barry Warsaw already did the work of converting the unicode.txt to PEP 100, so the docs should eventually go there. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > > replacement callback. > > > > Hmm, wouldn't that result in a slowdown ? If so, I'd > rather > > leave the special encoder in place, since it is being > used a > > lot in Python and probably some applications too. > > It would be a slowdown. But callbacks open many > possiblities. True, but in this case I believe that we should stick with the native implementation for "unicode-escape". Having a standard callback error handler which does the \uXXXX replacement would be nice to have though, since this would also be usable with lots of other codecs (e.g. all the code page ones). > For example: > > Why can't I print u"gürk"? > > is probably one of the most frequently asked questions in > comp.lang.python. For printing Unicode stuff, print could be > extended the use an error handling callback for Unicode > strings (or objects where __str__ or tp_str returns a > Unicode object) instead of using str() which always returns > an 8bit string and uses strict encoding. There might even > be a > sys.setprintencodehandler()/sys.getprintencodehandler() There already is a print callback in Python (forgot the name of the hook though), so this should be possible by providing the encoding logic in the hook. > > > I have not touched PyUnicode_TranslateCharmap yet, > > > should this function also support error callbacks? Why > > > would one want the insert None into the mapping to > call > > > the callback? > > > > 1. Yes. > > 2. The user may want to e.g. restrict usage of certain > > character ranges. In this case the codec would be used to > > verify the input and an exception would indeed be useful > > (e.g. say you want to restrict input to Hangul + ASCII). > > OK, do we want TranslateCharmap to work exactly like > encoding, > i.e. in case of an error should the returned replacement > string again be mapped through the translation mapping or > should it be copied to the output directly? The former would > be more in line with encoding, but IMHO the latter would > be much more useful. It's better to take the second approach (copy the callback output directly to the output string) to avoid endless recursion and other pitfalls. I suppose this will also simplify the implementation somewhat. > BTW, when I implement it I can implement patch #403100 > ("Multicharacter replacements in > PyUnicode_TranslateCharmap") > along the way. I've seen it; will comment on it later. > Should the old TranslateCharmap map to the new > TranslateCharmapEx > and inherit the "multicharacter replacement" feature, > or > should I leave it as it is? If possible, please also add the multichar replacement to the old API. I think it is very useful and since the old APIs work on raw buffers it would be a benefit to have the functionality in the old implementation too. [Decoding error callbacks] > > > A remaining problem is how to implement decoding error > > > callbacks. In Python 2.1 encoding and decoding errors > are > > > handled in the same way with a string value. But with > > > callbacks it doesn't make sense to use the same > callback > > > for encoding and decoding (like > codecs.StreamReaderWriter > > > and codecs.StreamRecoder do). Decoding callbacks have > a > > > different API. Which arguments should be passed to the > > > decoding callback, and what is the decoding callback > > > supposed to do? > > > > I'd suggest adding another set of PyCodec_UnicodeDecode... > () > > APIs for this. We'd then have to augment the base classes > of > > the StreamCodecs to provide two attributes for .errors > with > > a fallback solution for the string case (i.s. "strict" > can > > still be used for both directions). > > Sounds good. Now what is the decoding callback supposed to > do? > I guess it will be called in the same way as the encoding > callback, i.e. with encoding name, original string and > position of the error. It might returns a Unicode string > (i.e. an object of the decoding target type), that will be > emitted from the codec instead of the one offending byte. Or > it might return a tuple with replacement Unicode object and > a resynchronisation offset, i.e. returning (u"?", 1) > means > emit a '?' and skip the offending character. But to make > the offset really useful the callback has to know something > about the encoding, perhaps the codec should be allowed to > pass an additional state object to the callback? > > Maybe the same should be added to the encoding callbacks to? > Maybe the encoding callback should be able to tell the > encoder if the replacement returned should be reencoded > (in which case it's a Unicode object), or directly emitted > (in which case it's an 8bit string)? I like the idea of having an optional state object (basically this should be a codec-defined arbitrary Python object) which then allow the callback to apply additional tricks. The object should be documented to be modifyable in place (simplifies the interface). About the return value: I'd suggest to always use the same tuple interface, e.g. callback(encoding, input_data, input_position, state) -> (output_to_be_appended, new_input_position) (I think it's better to use absolute values for the position rather than offsets.) Perhaps the encoding callbacks should use the same interface... what do you think ? > > > One additional note: It is vital that errors is an > > > assignable attribute of the StreamWriter. > > > > It is already ! > > I know, but IMHO it should be documented that an assignable > errors attribute must be supported as part of the official > codec API. > > Misc/unicode.txt is not clear on that: > """ > It is not required by the Unicode implementation to use > these base classes, only the interfaces must match; this > allows writing Codecs as extension types. > """ Good point. I'll add that to the PEP 100. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-22 22:51 Message: Logged In: YES user_id=38388 Sorry to keep you waiting, Walter. I will look into this again next week -- this week was way too busy... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 19:00 Message: Logged In: YES user_id=38388 On your comment about the non-Unicode codecs: let's keep this separated from the current patch. Don't have much time today. I'll comment on the other things tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 17:49 Message: Logged In: YES user_id=89016 Guido van Rossum wrote in python-dev: > True, the "codec" pattern can be used for other > encodings than Unicode. But it seems to me that the > entire codecs architecture is rather strongly geared > towards en/decoding Unicode, and it's not clear > how well other codecs fit in this pattern (e.g. I > noticed that all the non-Unicode codecs ignore the > error handling parameter or assert that > it is set to 'strict'). I noticed that too. asserting that errors=='strict' would mean that the encoder is not able to deal in any other way with unencodable stuff than by raising an error. But that is not the problem here, because for zlib, base64, quopri, hex and uu encoding there can be no unencodable characters. The encoders can simply ignore the errors parameter. Should I remove the asserts from those codecs and change the docstrings accordingly, or will this be done separately? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 15:57 Message: Logged In: YES user_id=89016 > > [...] > > raise an exception). U+FFFD characters in the replacement > > string will be replaced with a character that the encoder > > chooses ('?' in all cases). > > Nice. But the special casing of U+FFFD makes the interface somewhat less clean than it could be. It was only done to be 100% backwards compatible. With the original "replace" error handling the codec chose the replacement character. But as far as I can tell none of the codecs uses anything other than '?', so I guess we could change the replace handler to always return u'?'. This would make the implementation a little bit simpler, but the explanation of the callback feature *a lot* simpler. And if you still want to handle an unencodable U+FFFD, you can write a special callback for that, e.g. def FFFDreplace(enc, uni, pos): if uni[pos] == "\ufffd": return u"?" else: raise UnicodeError(...) > > The implementation of the loop through the string is done > > in the following way. A stack with two strings is kept > > and the loop always encodes a character from the string > > at the stacktop. If an error is encountered and the stack > > has only one entry (during encoding of the original string) > > the callback is called and the unicode object returned is > > pushed on the stack, so the encoding continues with the > > replacement string. If the stack has two entries when an > > error is encountered, the replacement string itself has > > an unencodable character and a normal exception raised. > > When the encoder has reached the end of it's current string > > there are two possibilities: when the stack contains two > > entries, this was the replacement string, so the replacement > > string will be poppep from the stack and encoding continues > > with the next character from the original string. If the > > stack had only one entry, encoding is finished. > > Very elegant solution ! I'll put it as a comment in the source. > > (I hope that's enough explanation of the API and > implementation) > > Could you add these docs to the Misc/unicode.txt file ? I > will eventually take that file and turn it into a PEP which > will then serve as general documentation for these things. I could, but first we should work out how the decoding callback API will work. > > I have renamed the static ...121 function to all lowercase > > names. > > Ok. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > replacement callback. > > Hmm, wouldn't that result in a slowdown ? If so, I'd rather > leave the special encoder in place, since it is being used a > lot in Python and probably some applications too. It would be a slowdown. But callbacks open many possiblities. For example: Why can't I print u"gürk"? is probably one of the most frequently asked questions in comp.lang.python. For printing Unicode stuff, print could be extended the use an error handling callback for Unicode strings (or objects where __str__ or tp_str returns a Unicode object) instead of using str() which always returns an 8bit string and uses strict encoding. There might even be a sys.setprintencodehandler()/sys.getprintencodehandler() > [...] > I think it would be worthwhile to rename the callbacks to > include "Unicode" somewhere, e.g. > PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but > then it points out the application field of the callback > rather well. Same for the callbacks exposed through the > _codecsmodule. OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors really is a long name ;)) > > I have not touched PyUnicode_TranslateCharmap yet, > > should this function also support error callbacks? Why > > would one want the insert None into the mapping to call > > the callback? > > 1. Yes. > 2. The user may want to e.g. restrict usage of certain > character ranges. In this case the codec would be used to > verify the input and an exception would indeed be useful > (e.g. say you want to restrict input to Hangul + ASCII). OK, do we want TranslateCharmap to work exactly like encoding, i.e. in case of an error should the returned replacement string again be mapped through the translation mapping or should it be copied to the output directly? The former would be more in line with encoding, but IMHO the latter would be much more useful. BTW, when I implement it I can implement patch #403100 ("Multicharacter replacements in PyUnicode_TranslateCharmap") along the way. Should the old TranslateCharmap map to the new TranslateCharmapEx and inherit the "multicharacter replacement" feature, or should I leave it as it is? > > A remaining problem is how to implement decoding error > > callbacks. In Python 2.1 encoding and decoding errors are > > handled in the same way with a string value. But with > > callbacks it doesn't make sense to use the same callback > > for encoding and decoding (like codecs.StreamReaderWriter > > and codecs.StreamRecoder do). Decoding callbacks have a > > different API. Which arguments should be passed to the > > decoding callback, and what is the decoding callback > > supposed to do? > > I'd suggest adding another set of PyCodec_UnicodeDecode... () > APIs for this. We'd then have to augment the base classes of > the StreamCodecs to provide two attributes for .errors with > a fallback solution for the string case (i.s. "strict" can > still be used for both directions). Sounds good. Now what is the decoding callback supposed to do? I guess it will be called in the same way as the encoding callback, i.e. with encoding name, original string and position of the error. It might returns a Unicode string (i.e. an object of the decoding target type), that will be emitted from the codec instead of the one offending byte. Or it might return a tuple with replacement Unicode object and a resynchronisation offset, i.e. returning (u"?", 1) means emit a '?' and skip the offending character. But to make the offset really useful the callback has to know something about the encoding, perhaps the codec should be allowed to pass an additional state object to the callback? Maybe the same should be added to the encoding callbacks to? Maybe the encoding callback should be able to tell the encoder if the replacement returned should be reencoded (in which case it's a Unicode object), or directly emitted (in which case it's an 8bit string)? > > One additional note: It is vital that errors is an > > assignable attribute of the StreamWriter. > > It is already ! I know, but IMHO it should be documented that an assignable errors attribute must be supported as part of the official codec API. Misc/unicode.txt is not clear on that: """ It is not required by the Unicode implementation to use these base classes, only the interfaces must match; this allows writing Codecs as extension types. """ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 10:05 Message: Logged In: YES user_id=38388 > How the callbacks work: > > A PyObject * named errors is passed in. This may by NULL, > Py_None, 'strict', u'strict', 'ignore', u'ignore', > 'replace', u'replace' or a callable object. > PyCodec_EncodeHandlerForObject maps all of these objects to > one of the three builtin error callbacks > PyCodec_RaiseEncodeErrors (raises an exception), > PyCodec_IgnoreEncodeErrors (returns an empty replacement > string, in effect ignoring the error), > PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode > replacement character to signify to the encoder that it > should choose a suitable replacement character) or directly > returns errors if it is a callable object. When an > unencodable character is encounterd the error handling > callback will be called with the encoding name, the original > unicode object and the error position and must return a > unicode object that will be encoded instead of the offending > character (or the callback may of course raise an > exception). U+FFFD characters in the replacement string will > be replaced with a character that the encoder chooses ('?' > in all cases). Nice. > The implementation of the loop through the string is done in > the following way. A stack with two strings is kept and the > loop always encodes a character from the string at the > stacktop. If an error is encountered and the stack has only > one entry (during encoding of the original string) the > callback is called and the unicode object returned is pushed > on the stack, so the encoding continues with the replacement > string. If the stack has two entries when an error is > encountered, the replacement string itself has an > unencodable character and a normal exception raised. When > the encoder has reached the end of it's current string there > are two possibilities: when the stack contains two entries, > this was the replacement string, so the replacement string > will be poppep from the stack and encoding continues with > the next character from the original string. If the stack > had only one entry, encoding is finished. Very elegant solution ! > (I hope that's enough explanation of the API and implementation) Could you add these docs to the Misc/unicode.txt file ? I will eventually take that file and turn it into a PEP which will then serve as general documentation for these things. > I have renamed the static ...121 function to all lowercase > names. Ok. > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > replacement callback. Hmm, wouldn't that result in a slowdown ? If so, I'd rather leave the special encoder in place, since it is being used a lot in Python and probably some applications too. > PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, > PyCodec_ReplaceEncodeErrors are globally visible because > they have to be available in _codecsmodule.c to wrap them as > Python function objects, but they can't be implemented in > _codecsmodule, because they need to be available to the > encoders in unicodeobject.c (through > PyCodec_EncodeHandlerForObject), but importing the codecs > module might result in an endless recursion, because > importing a module requires unpickling of the bytecode, > which might require decoding utf8, which ... (but this will > only happen, if we implement the same mechanism for the > decoding API) I think that codecs.c is the right place for these APIs. _codecsmodule.c is only meant as Python access wrapper for the internal codecs and nothing more. One thing I noted about the callbacks: they assume that they will always get Unicode objects as input. This is certainly not true in the general case (it is for the codecs you touch in the patch). I think it would be worthwhile to rename the callbacks to include "Unicode" somewhere, e.g. PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but then it points out the application field of the callback rather well. Same for the callbacks exposed through the _codecsmodule. > I have not touched PyUnicode_TranslateCharmap yet, > should this function also support error callbacks? Why would > one want the insert None into the mapping to call the callback? 1. Yes. 2. The user may want to e.g. restrict usage of certain character ranges. In this case the codec would be used to verify the input and an exception would indeed be useful (e.g. say you want to restrict input to Hangul + ASCII). > A remaining problem is how to implement decoding error > callbacks. In Python 2.1 encoding and decoding errors are > handled in the same way with a string value. But with > callbacks it doesn't make sense to use the same callback for > encoding and decoding (like codecs.StreamReaderWriter and > codecs.StreamRecoder do). Decoding callbacks have a > different API. Which arguments should be passed to the > decoding callback, and what is the decoding callback > supposed to do? I'd suggest adding another set of PyCodec_UnicodeDecode...() APIs for this. We'd then have to augment the base classes of the StreamCodecs to provide two attributes for .errors with a fallback solution for the string case (i.s. "strict" can still be used for both directions). > One additional note: It is vital that errors is an > assignable attribute of the StreamWriter. It is already ! > Consider the XML example: For writing an XML DOM tree one > StreamWriter object is used. When a text node is written, > the error handling has to be set to > codecs.xmlreplace_encode_errors, but inside a comment or > processing instruction replacing unencodable characters with > charrefs is not possible, so here codecs.raise_encode_errors > should be used (or better a custom error handler that raises > an error that says "sorry, you can't have unencodable > characters inside a comment") Sure. > BTW, should we continue the discussion in the i18n SIG > mailing list? An email program is much more comfortable than > a HTML textarea! ;) I'd rather keep the discussions on this patch here -- forking it off to the i18n sig will make it very hard to follow up on it. (This HTML area is indeed damn small ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 21:18 Message: Logged In: YES user_id=89016 One additional note: It is vital that errors is an assignable attribute of the StreamWriter. Consider the XML example: For writing an XML DOM tree one StreamWriter object is used. When a text node is written, the error handling has to be set to codecs.xmlreplace_encode_errors, but inside a comment or processing instruction replacing unencodable characters with charrefs is not possible, so here codecs.raise_encode_errors should be used (or better a custom error handler that raises an error that says "sorry, you can't have unencodable characters inside a comment") BTW, should we continue the discussion in the i18n SIG mailing list? An email program is much more comfortable than a HTML textarea! ;) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 20:59 Message: Logged In: YES user_id=89016 How the callbacks work: A PyObject * named errors is passed in. This may by NULL, Py_None, 'strict', u'strict', 'ignore', u'ignore', 'replace', u'replace' or a callable object. PyCodec_EncodeHandlerForObject maps all of these objects to one of the three builtin error callbacks PyCodec_RaiseEncodeErrors (raises an exception), PyCodec_IgnoreEncodeErrors (returns an empty replacement string, in effect ignoring the error), PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode replacement character to signify to the encoder that it should choose a suitable replacement character) or directly returns errors if it is a callable object. When an unencodable character is encounterd the error handling callback will be called with the encoding name, the original unicode object and the error position and must return a unicode object that will be encoded instead of the offending character (or the callback may of course raise an exception). U+FFFD characters in the replacement string will be replaced with a character that the encoder chooses ('?' in all cases). The implementation of the loop through the string is done in the following way. A stack with two strings is kept and the loop always encodes a character from the string at the stacktop. If an error is encountered and the stack has only one entry (during encoding of the original string) the callback is called and the unicode object returned is pushed on the stack, so the encoding continues with the replacement string. If the stack has two entries when an error is encountered, the replacement string itself has an unencodable character and a normal exception raised. When the encoder has reached the end of it's current string there are two possibilities: when the stack contains two entries, this was the replacement string, so the replacement string will be poppep from the stack and encoding continues with the next character from the original string. If the stack had only one entry, encoding is finished. (I hope that's enough explanation of the API and implementation) I have renamed the static ...121 function to all lowercase names. BTW, I guess PyUnicode_EncodeUnicodeEscape could be reimplemented as PyUnicode_EncodeASCII with a \uxxxx replacement callback. PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, PyCodec_ReplaceEncodeErrors are globally visible because they have to be available in _codecsmodule.c to wrap them as Python function objects, but they can't be implemented in _codecsmodule, because they need to be available to the encoders in unicodeobject.c (through PyCodec_EncodeHandlerForObject), but importing the codecs module might result in an endless recursion, because importing a module requires unpickling of the bytecode, which might require decoding utf8, which ... (but this will only happen, if we implement the same mechanism for the decoding API) I have not touched PyUnicode_TranslateCharmap yet, should this function also support error callbacks? Why would one want the insert None into the mapping to call the callback? A remaining problem is how to implement decoding error callbacks. In Python 2.1 encoding and decoding errors are handled in the same way with a string value. But with callbacks it doesn't make sense to use the same callback for encoding and decoding (like codecs.StreamReaderWriter and codecs.StreamRecoder do). Decoding callbacks have a different API. Which arguments should be passed to the decoding callback, and what is the decoding callback supposed to do? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 20:00 Message: Logged In: YES user_id=38388 About the Py_UNICODE*data, int size APIs: Ok, point taken. In general, I think we ought to keep the callback feature as open as possible, so passing in pointers and sizes would not be very useful. BTW, could you summarize how the callback works in a few lines ? About _Encode121: I'd name this _EncodeUCS1 since that's what it is ;-) About the new functions: I was referring to the new static functions which you gave PyUnicode_... names. If these are not supposed to turn into non-static functions, I'd rather have them use lower case names (since that's how the Python internals work too -- most of the times). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 18:56 Message: Logged In: YES user_id=89016 > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. Another problem is, that the callback requires a Python object, so in the PyObject *version, the refcount is incref'd and the object is passed to the callback. The Py_UNICODE*/int version would have to create a new Unicode object from the data. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 18:32 Message: Logged In: YES user_id=89016 > * please don't place more than one C statement on one line > like in: > """ > + unicode = unicode2; unicodepos = > unicode2pos; > + unicode2 = NULL; unicode2pos = 0; > """ OK, done! > * Comments should start with a capital letter and be > prepended > to the section they apply to Fixed! > * There should be spaces between arguments in compares > (a == b) not (a==b) Fixed! > * Where does the name "...Encode121" originate ? encode one-to-one, it implements both ASCII and latin-1 encoding. > * module internal APIs should use lower case names (you > converted some of these to PyUnicode_...() -- this is > normally reserved for APIs which are either marked as > potential candidates for the public API or are very > prominent in the code) Which ones? I introduced a new function for every old one, that had a "const char *errors" argument, and a few new ones in codecs.h, of those PyCodec_EncodeHandlerForObject is vital, because it is used to map for old string arguments to the new function objects. PyCodec_RaiseEncodeErrors can be used in the encoder implementation to raise an encode error, but it could be made static in unicodeobject.h so only those encoders implemented there have access to it. > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. I look through the code and found no situation where the Py_UNICODE*/int version is really used and having two (PyObject *)s (the original and the replacement string), instead of UNICODE*/int and PyObject * made the implementation a little easier, but I can fix that. > Please separate the errors.c patch from this patch -- it > seems totally unrelated to Unicode. PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with four hex digits. I removed it. I'll upload a revised patch as soon as it's done. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 16:29 Message: Logged In: YES user_id=38388 Thanks for the patch -- it looks very impressive !. I'll give it a try later this week. Some first cosmetic tidbits: * please don't place more than one C statement on one line like in: """ + unicode = unicode2; unicodepos = unicode2pos; + unicode2 = NULL; unicode2pos = 0; """ * Comments should start with a capital letter and be prepended to the section they apply to * There should be spaces between arguments in compares (a == b) not (a==b) * Where does the name "...Encode121" originate ? * module internal APIs should use lower case names (you converted some of these to PyUnicode_...() -- this is normally reserved for APIs which are either marked as potential candidates for the public API or are very prominent in the code) One thing which I don't like about your API change is that you removed the Py_UNICODE*data, int size style arguments -- this makes it impossible to use the new APIs on non-Python data or data which is not available as Unicode object. Please separate the errors.c patch from this patch -- it seems totally unrelated to Unicode. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Fri May 17 00:10:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 16 May 2002 16:10:56 -0700 Subject: [Patches] [ python-Patches-553108 ] Deprecate bsddb Message-ID: Patches item #553108, was opened at 2002-05-06 20:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Nobody/Anonymous (nobody) Summary: Deprecate bsddb Initial Comment: Large numbers of inserts break bsddb, as first discovered in Python 1.5 (bug 408271). According to Barry Warsaw, "trying to get the bsddb module that comes with Python to work is a hopeless cause." If it's broken, let's discourage people from using it. In particular, let's ensure that people importing shelve or anydbm don't end up using it by default. The submitted patch adds a DeprecationWarning to the bsddb module and removes bsddb from the list of db module candidates in anydbm. ---------------------------------------------------------------------- Comment By: Martin D Katz, Ph.D. (drbits) Date: 2002-05-16 16:10 Message: Logged In: YES user_id=276840 I am not sure there is a reason to deprecate bsddb. The btopen format appears to be stable enough for normal work. Maybe 2.3 should change dbhash to use btopen? ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2002-05-08 20:12 Message: Logged In: YES user_id=59803 Let's not turn a simple patch into something requiring a PEP, compulsory thrashing on comp.lang.python, SleepyCat being willing to change their distribution model, lawyers (to make sure the licences are compatible), and so on. I'd hate it if other people spent the kind of time I did trying to get shelve to work only to find that a known- broken bsddb was causing all the problems, and that a patch was there to gently guide them to gdbm, but it got jammed because of scope-creep. Let's get this one, very simple and necessary (bsddb IS broken) change out of the way, and THEN start negotiating, thrashing, and integrating. :) I firmly believe bsddb3 should be one of the included batteries. Let's do it, but let's guide people away from broken code first. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 02:01 Message: Logged In: YES user_id=21627 I'm in favour of this change, but I'd like simultaneously incorporate bsddb3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 From noreply@sourceforge.net Sat May 18 01:26:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 17 May 2002 17:26:11 -0700 Subject: [Patches] [ python-Patches-550002 ] Unittest for base64 Message-ID: Patches item #550002, was opened at 2002-04-28 22:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550002&group_id=5470 Category: Tests Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mitchell Surface (msurface) Assigned to: Raymond Hettinger (rhettinger) Summary: Unittest for base64 Initial Comment: Script for testing base64.decodestring and base64.encodestring. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-17 19:26 Message: Logged In: YES user_id=80475 Committed test_base64.py version 1.1. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-14 02:26 Message: Logged In: YES user_id=80475 Test code runs fine. Looks comprehensive. Does not test encode/decode from a file but the underlying logic is the same. If no one has any issues by Fri 2002-May-17, I'll load it to the testbank. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550002&group_id=5470 From noreply@sourceforge.net Sat May 18 16:02:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 May 2002 08:02:05 -0700 Subject: [Patches] [ python-Patches-551915 ] GC collection frequency bug Message-ID: Patches item #551915, was opened at 2002-05-03 16:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551915&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel Dunbar (danieldunbar) Assigned to: Neil Schemenauer (nascheme) Summary: GC collection frequency bug Initial Comment: - bug fix, garbage collection frequency was incorrect in the presence of empty generations. The generational cycle collection algorithm skipped calling collect() on empty generations, however collect() has the side effect of resetting the 'allocated' global, on which the collection frequency is based. The result was that in pathological cases every call to PyObject_GC_Malloc could trigger a collection, for an extended number of calls to _GC_Malloc. Note that this bug only has a noticable effect when many calls to _GC_Malloc are made without tracking any of the returned objects. It also raises the question of whether allocated should be tracked from within _GC_Malloc, as it is the actual _GC_Track function that causes objects to be exposed to the collector. Patch consolidates empty generation tests at top of gcmodule:collect(), and sets allocated to 0 if it skips the collection - perhaps this should be fixed by changing _GC_Track to control the collection frequency. The collection frequency will still be incorrect if, for large N, N objects are allocated without being tracked (allocated=~N), a collection is run (allocated=0), and then all N objects become tracked (gen0 is now very large, but no collection, nor does _GC_Malloc think one needs to be done). In practice I believe this is unlikely to be important, as a new collection will probably run very soon anyway. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2002-05-18 15:02 Message: Logged In: YES user_id=35752 This bug should not occur in the CVS version of Python. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-05-04 05:41 Message: Logged In: YES user_id=35752 I still like basing the threshold on the number of objects allocated (hmm, maybe it should be the number of bytes now that we have PyObject_GC_Malloc). I've changed the code so that the allocated counter is always zeroed on a collection. I've also removed the code that handles an empty gen0 specially. I don't think it's a case worth optimizing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-05-04 02:27 Message: Logged In: YES user_id=31435 Oddly enough, this came up on Python-Dev this week, but in the context of deliberately untracking tracked items with no intent of deallocating them for a long time. Same glitch: pretty soon generation 0 is empty, and a useless gen0 collection gets run on nearly every GC malloc; worse, a gen2 collection gets run about 700x too often. I view "allocated" as trying to guess the size of gen0, and agree the net excess of tracked less untracked is a better guess in edge cases. Assigned to Neil for cogitation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=551915&group_id=5470 From noreply@sourceforge.net Sat May 18 19:32:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 May 2002 11:32:23 -0700 Subject: [Patches] [ python-Patches-557719 ] OSX build -- make python.app Message-ID: Patches item #557719, was opened at 2002-05-18 18:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557719&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: OSX build -- make python.app Initial Comment: Some small improvements to OSX build: 1. When building from separate directory than the build directory, automatic --with-suffix code was not working. 2. Tk for Mac OS X is detected and built automatically. 3. WASTE is found more automatically. 4. Building of Python.app can be invoked from the main makefile. (via make python.app) 5. A .pth file is installed in the Python.framework so that Mac modules are found by default. Also, a change to the Python IDE: when it looks for and creates an "IDE Scripts" folder under OSX, it was breaking. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557719&group_id=5470 From noreply@sourceforge.net Sat May 18 19:47:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 18 May 2002 11:47:27 -0700 Subject: [Patches] [ python-Patches-557719 ] OSX build -- make python.app Message-ID: Patches item #557719, was opened at 2002-05-18 18:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557719&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: OSX build -- make python.app Initial Comment: Some small improvements to OSX build: 1. When building from separate directory than the build directory, automatic --with-suffix code was not working. 2. Tk for Mac OS X is detected and built automatically. 3. WASTE is found more automatically. 4. Building of Python.app can be invoked from the main makefile. (via make python.app) 5. A .pth file is installed in the Python.framework so that Mac modules are found by default. Also, a change to the Python IDE: when it looks for and creates an "IDE Scripts" folder under OSX, it was breaking. ---------------------------------------------------------------------- >Comment By: Tony Lownds (tonylownds) Date: 2002-05-18 18:47 Message: Logged In: YES user_id=24100 The new file python/dist/src/Mac/OSX/Mac.pth wasn't included in diff so I am attaching it now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557719&group_id=5470 From noreply@sourceforge.net Sun May 19 15:20:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 19 May 2002 07:20:36 -0700 Subject: [Patches] [ python-Patches-557946 ] Ebcdic compliancy in stringobject source Message-ID: Patches item #557946, was opened at 2002-05-19 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jean-Yves MENGANT (jymen) Assigned to: Nobody/Anonymous (nobody) Summary: Ebcdic compliancy in stringobject source Initial Comment: the printable character set test made inside strincgobject.c is not compliant with EBCDIC systems(OS390 or OS400) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 From infomailsys@mail.ru Sun May 19 17:29:54 2002 From: infomailsys@mail.ru (New Banner Systems) Date: Sun, 19 May 2002 20:29:54 +0400 Subject: [Patches] Re: Your Logo Message-ID: This is a multipart MIME message. --= Multipart Boundary 0519022029 Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit
--= Multipart Boundary 0519022029 Content-Type: image/gif; name="___WWW.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhWAKRAPcAAAAAAP////eQku0dJe8yOPNTWGsCHP6PrkcXNH5LeFYQ T7GwsVMOXEwNZlwrd0IObjwQdTQQczcTei4RejIVgIBypSgReysVgDomhpSL tiURgE0+jycWhy0bhoV9sJ6XwCERfyIThCUXgm1ln0E2jlJJl1xUmeHg6R4T hhwTgyEWiScdiS0kjTQsjWFaoBwVinBsqhgThx4ZhiIcjDo2lRcVjBwbjbKx 1h8gkYuLw8vL5dnZ6uXl8fPz+f39//v7/fDw8S8xkzw/mVBTpGNlrXh5uL6/ 3BcdjyYrlpeZyaOlzhEakhsjljA5nGZsthQhlRQmnBopnhIrpRgxrCpCsT1P sFdpvvf4/A8xr2d7yHWIz4GW1pGj2rPA5pKp4fv9//3//f///f/++uMjAeMh AeIlAeEjAeEhAd8hAd0jAdohAdQhAdMfAdEgAc4eAc0hAcoeAcYeAcIdAb4d AbodAeMjA+EjA90oB9KLf+odAeUhAeUeAeMdAeMfAeEdAeEfAd8dAd8fAd0b Ad0fAd0dAdoeAdYeAdYaAdMdAdIaAdEdAc4aAcoaAcYaAcIaAb4aAboaAboX AbcYAbQXAbAXAeMfA98gA9wdA9EdA+khBNwhBOQiBuAiBtciBtskB8IfB7kd B98mCdsoC90rD70jDtcqEOAvFdYxGMotGNE2H9g6ItA/KM9HMsxTQOVeTM5k U854ategmNy0ruPJxf739vfw7+gXAeYbAeIXAeIaAd8ZAd8bAd0ZAdwXAdoa AdQXAcsWAcMWAb4WAbgVAfEbAugbBd8bBd4eBdkbBeceBuIfBtgeBtIdBuwe CM8cB+4iDNwiC8odCuonDtUkD+ozHOc/K+ZNPMASAaYQAucfC/ImEs4iEfEu Hf7x8MsPAb8LAdkXC90qIPi9uvnX1fvp6NcJAfMNA+EdFPFoZPOFgvetqvzj 4pEKCfN2c/aenPvIyP/6+tnU1Pn29v/9/eTi4vv6+v39/cfHx5CQkHBwcFdX Vz4+Pi8vLyEhIQEBAf///yH5BAEAAAEALAAAAABYApEAAAj/AAMI7OYunTpx 49aRI0cLnsCHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmyZcpZ qChNGnaNVCpWrdC1MyjuXUJaLoMKHUq0qNGjSJMqXcq0acYw6j5Nkjmp6rBh MiNdA7YtVTVrrtoJcNdzHEOnaNOqXcu2rdu3cJmKkUWKkt2pdmVmHSZM2LCZ fKOdCxeOgLUC6NIJOJjQYdzHkCNLnky5smWIsebktYttM+BhkvAClsQ3krBg wYAtcsbsHDUCiHe6U+dzYTda80LS6na5t+/fwIMLFxoGD6TNnO9Srcp8JulI 0PsKMx3p0aO+kk4zAsYoWlecrhIv/y5rFmjEbg7hjVOHroCAd+SGy59Pv759 ysXxUuqMnCrV55NIIgl0BFZXHSSnhfaIIww2eA1q1iGo1SeopLJKK+HJls5h 7bhCjS/eXPNLYQWkQ1ZCvE3UzTsp3ufiizDGKCNFYLQzTGf8ITdVcwGGVlVo kECX3SORBCngI5As6Ih1jTjSyJNQLklkksFEIol1czgCzJaLqAZMMF0uksgv v0ATTjXVuBKWieoIgA415xww45x01mlnZfDAol9/yzUnIHMCDlhkhEEmWR2R Cy4oh5NxNAJHo3E0qiQklFrnyDBgLsJIIotEkppqv4yZyJi/+HKIL2Sm+gs4 Ajh256uwxv8qq1BiwIJVcn0uF6iVf/Z46HTWBZvodUk6kuWiDToix6ONxPGo snLIMQeTcDDixiKIOoLak9yplggioYoKjDfATMPTOmDMqu667LZrkZ579slj gH/1CJqgBEopTISDJvlIlskae2y00cYhR6TOLuqotYwo6chpqAXzZDCMMNII xRZri9o24VhjEIvuhizyyDN208pf++k4r4D1+molgf4KO4eVlB5qqSMGKzuH HP/y3HOkBDMCBxxuKNLIgsEI09lpTjKiacVP3uxkMN6U4wkB7RwAn3kkd+31 15SNs0okKCsnL3OguSxkkEjaHCwkAtJBR6VYLtjIwU0quyQkchP/HO3Qb7gB hxyUSIKNAQawozg22DhS8SJ3K9lkHG6s0YYiivSCCzexuTMO12CHLvroSYkD SlWeoX1Vj5/9KEmhpllnsyNF1pxkktPOMW2DCAud8yNzQ3LwwXC8QbTxcAyD +PKJS7Jk3to66agibbjxRhvYt6FGGmgAYgo66oyTG+nkl29+SfPEIonZd43G a6A+3isgr8PIbimhlFJqrKJOMkgwwgoTGN925qxHFQ8OjbgGNhS3uOHJ4W5+ c9bl2EBBCrbBeG6goCE2UQ10vON8IAyhCN9VtrtcZRhCgg7c3ge/AVFKQGwT FpL8VSmeAUxJ/+Lf/4BWMMANDXBuKJrg/x51MAD20A3Vo2AQgeYsIWLPEIT4 3ge9Jo7FjPCKWIQILVxBth1Z5SoFCuOPAvTCmkEHScMilAyHRTC9Nct/ESyg 8d4QODoGsXjIM+CjEBYHOmKPiNKKFiPawAbMBdENiFAEGwoxCmuoIz4jK8AA BpDFSo6QHKxA4V9WRzboaBKFnuzV6+ZXJBVSCUnTWmOiIJGlnUVLWXe7m8EM RjA80jFwFwwiBomGwD1i0HgGmwMdCFi8y1UPiYoIYjLZYAhDQMMa7xkfu7ox yQFM0ZLYJF0YxpEKYVyjXqQZ0L1ASaABhUZQNZtfofZ2pWAx6IbBEiYrWTmw B/IRYcfDnvVuaf/H6/1waJQLpu6KiMTsHdKP1lPE0Kh3PUNQwxXjYNc8xFFN AWTzoqLbpioedA2/nDCFBSKN/EjZrwNZCm5wu9+SXsmgRM2Bnqx8hN8K1ihG ROoNa8jp9fjJU4Dmbg4FDGIbEKHPX+ryDcmk3BARyQxqiMNVskpHNQuA0ap+ bRyqiFhHBQXK6ZTznAH6kQpVib8kCcNY/YsnllypLOAN1JU0jRQc2mC5nOaU rmpYAzAD2cQgJvKQiphjHi9oR7n+s2ilsIZ4xAG6OkmymlaN7MiwytGOdtI0 fQmjkMJauNixbV9LamuEFDVTlu5sZ83aY8GiRdq76RFwhMzlHg1b0KL/JfOQ QzQgbov5hmUBtImQKxobBIGOddyJmtW0pmSXuy6NPigYD/KqVzVbzh69bqzu xGHdkhXBNr6yYDb9YQEBirNIOcpZfDRg4AqavfUeUmjVGtoiiCY4oS3xn01M RKTm64ZEVMMd66BFQ2akjuQOwKLMTTCsNOoNb6Cmo3yZbmapU6QdkVKGZw2t w5SErCJGq1k8fGDQUju0Q/6Tl4f1I/UwxwaDHhS3MH7a0BiGM5s2K3BwcATR 5ruIZ6JDJ+kI8njGgZ75+KAdA3hskhXM5Du94xQOdnDSTINC6UQHZs1B4YL2 ZamjbbhBLJWlmB1VRB4mLKjVyiNujdne7LX4/3K31eVuD7kIE5fYDU0zr9Pw 7LRqXSsRXKoYIpdxpgK0QxxnEQ4BrJncFjX50TB6cmqga9noTJc6oPTioK4T 2gYxaUk7C1iNB7covKF3tnuk7x1LfOdlVi+wbn51nJUZRPvSGcXWckMcgIrA RlyLERSrltCE1iQ0XiezfLlGONDhOUdbZh1LXvQkxQHparvIB++YBtVQI51u 9+XYXkWZVSKhrQwny51+i+WHQUzLRoEYoKmmL5vda1uhYu96ycReId+cvaHO edX25eXB+BxEyFXMYnmrDlhlchVBTUIY0ehYO9wBssq448DwQEc105EWhAjl HQUogDsiIvIApCPkIf9vR0QFcnJ1RATkEtlJRNSB8pCrg+Y1DznHac5xa/tG HM5o8Je83W1wZ5Y5WQnGzYJxbv89iWBQMtiTDPuk2aY3cJhDRCFvW8iCYi6X lwtii9mQSH2zoWjVO2a9Tyy4aC3VDTa1WKKkhKT4BeirqKPEMBgxDaxBUjIa H4cPLj5JqjalG1K9ZkvmsWgCQGQcypUkbBpv3ABIEsEPkeR5BuB4iAiA8yE/ 8OcL0HjSU3X0Pv/5loBxjY4S/dvdpp2Pkr4vpqfVnQyKeu8euLAZp/e1cKhz nQnZYur123LGd3PZMZd84jNfmWe3lqrdUDBf19nGyGqQMNI5IOvsC24sswr/ dIMBDsVDhgAEcAjkq+nso6hD2uZniVQHQG2Wd/7yAejGonuO/4cUmJIQQVED IHgPgXrwMA/rUHmoh4ABgHqpdxnqMC7Q5RevlzTT0RdVYiU7AjGoIT1S4nRQ EoLoFQc25iwlKF4/VGf9VTRaZ28ttgZvFoMalAhox3xEpUgsRj1KJH2qBgdz 8CSHFAcMInUZs0YWOF2gtEmZpQp/BxnvMADo4AMB4APSRn9SmBQFNn/xtxLQ BoUPQQD8d2ABMA9SZXj9JxDSFhHzN3IFuGQS4YACAYcPOBlfkA6s902aRHRT hoFVQho74ilPgnCM0GlDGIJT1yzNwnuRUjHjBW8L/3VbOKgIWheDMGhBxGcI hWAIFWRIiUBBWgdnOqhQuGVIPNMIw5YxIAZsDsN0UEIknpSEM9EXw2AN7fcW PiBVbDgPGjdJ7bAUPiAOPjBJW7gSj8Ub0LZy+OcDDniG/weAXzhJ6OB5bhgR ciiHcxgZtPAK0nEVr7cvmAUxnYQ2qFEx3AE9T1KIcVctzWIxQoiI8XViP1Q0 i8B8hYQIk1hBZFd2bLAGmFgIhUBUm3iPkkh2+jZraNcGcPAIvnZwg3NwF6OQ IZgxRbIrmxVh14AOjQUX8CBJKzd41dR5Y0h6vYiG7hByFgVyjsd4BfAO7wAb DWhoBbhoBbByEhGMyiURLf9JAOOwfw8xDpKHYCA3SQSAeREhgCPnDiCZjBrH hv2nf2n4ENCGZM7YgNMojYYXh1V5jZCxDqzAbX1hWd3YFwziVaFBCZ5Cjlty MRJjiKZoitVCgiPYexZzYraGCIjUBoeACJiYbzJIfMykBmowCIVAQTnVTBWU SPcIg8k0fYt5MIvwmE4jaBZzVmyZgWHUF1bhF9dAlI9BTQRwhQHQhZNUeSbH eQMxAOuAf08IgMK4mvMwelJ4cQCWZFAFEcIImg+xmuggAIvmclG5iy73DunQ Dfo3AGwYEVRomiUnEPgHeQWQIv3HmwIIETQngNdkjVh5lVSpnVr5GOJwCtGl hxH/Ix0RM4EaaJafohpdoiUSI4gHJ5lw2UszJmjBV2L2hQijopeHcAiGYJfK 1290tQb+qIn7aJgapIn0uI+FVGIqWGuRKTSPWY5NYopQo4rCAiyRgDZ9EQ0u JxkF1g64WYUdGgCraVzi4HiqOUkC0Zoq6oCLxpz0RxHCOBGrKQA+UGCd9w4+ 4AOSZHhXiJ0CQXgFRpqSd3l/h3/QRnEq+hBiQQ6ThHmfl1xQWpWfBxuGNozd mRYC8CUWyG1deoSnwaXchhWTEAkUqp6p8Zhdgoin6DQ8Np/V8jT1ZWt/Nir8 2Z9ExWb8RomGyY/NRKB/aokVpFf1JUS6JgePGae+554U/5o3XOZVj0CmD+cX qYClbHFkAzCiArGLXigQjJept8hxl4dtKjoPLDoAyrhkT2h4n8eZDzGjyLma Orp+jmaNUhWNKjJVEFGknId5+IcOn7matqmjPdqGQykABtGG2lmlpAerWdoW YhNd5TmeEIOBwKCW0EWmD7IdYvIlTpMqMtamj6NqmlJwMEZriYA5d/qJ/UZ2 L3g9xGc5m1hBzYSYY2cIMFg99CWJitAoT5OoFdNrFOqQTEcdInWek9BR32AN TRgXn0qaQfqRD+EDGtcOG/lBKcqa1iSsqPd51sCSSMadr3qTLzdJO2qT15Sa 0zgOJ0qyyCmV7iBNlzcP64dgl//3hB8krAIBeVM4fynigLhZjUvWDcX6rG0h BuOAB6tQns81rUkTMdc6gVXxIOqJcOpJJpxyivGlKfMVp2q6KdazY9BXNIbA n3n5daDIb0N1CAXKTBSkg2NHg+2Kr6J4TJjTSwd3feX4OBaDcH04P9wYGick DN+Aq5Ghs4+XXAQYADhKTSyXZEE5ALlxqql6egaWlSOrozg5SeMzo+MArEVr eU+KmyWLmqCZjBd3fwOQDi5JokvagLgqgPUHpEJreP9ntHAxDu3ACttALpPW tE+bnlyKFcOgnppCMVxCKjQop/x1LcJXZ5wifDAmt/jZn/UqVIpUiRU0VL3g C/jKTPj/SqDEl3bw6pcmhkgKlWtw56DvyYiDKHu7UmUEklneoA5hIBm3WpNV iHld6CZSuA7S9lgrurEtumSwSboS4awQgbjCuJME0A1wOA7voHGGq78FAFX9 p7OSh5oCgbgiJ4XIlQ5SSLtU6oaIi7ts8QVfsA7igAeqIHSosXoSs3qr901m 2QhjsqbCgMO/sAipEr3OW2eLKSb4ma6K8C1iwnwsZo/6mZeFFKD4WInNlImF qYkGqkTItI8wqInCJlwKFXwreEfCF7BQo3SBomVXRoF9EQ40+RgbaZwSMQ9K dpVvTAAd6gPkwCI6S7mwSVEgaREKLBCkCoDItQ5IZlFy6API/9XGJHecMAqU S/pYIznIp7lydZydEwGHlTuFOkuT69AijIzCSTHBrHAK25CeYOKtXYIafyEM 3rIdiXAxPvzDYsK1YvIt6bqff4oI66p1TPzL7qqXZNdMA6mXf9pM/KgGBIqP vpxB+2ZXRAV3TWRIwHAtdlk0jwN3wyaERHJ3VLIkE/aVrpCRb9GFoUyV7CfI 8wexPjAPe0zAlIR6XQixMuqyuTlJEfWEn4l/1ohcw0hNjJyMZQijD3zPAPh+ V3iLo7mdmVzChjfQSOabphkAES3KTAEG8iDB6uAKzPALwEAmX+IlX0I2ezcq TjMqphgqv3AInLK8t/wtvDzF/ugLA/96zG7bTPwJvse804agzJnYjzu9BpNo j4qkQVon1GcXj4W0Zys4KuX6NFBDO2BUHeVmsNJxDSLsoZxXmx2cXPXnuhe8 uZIbAHzshpKEqwlRz5pbuhaFZO2giwMAosV6EPmHZAU9Ee8nEfgnpLlxea4i rKlZAKAZpQIAwUPrE8pqlQEgpGRtwDNaeBbtFD4ABvUgDhtSCr3QC6CyJUmT sB+tKWNyCNvByys9KpgzKqG9n6ciCL7gC4Lw2oLgj4VA07Jd0z+NiX8q2z5d CIDZ22pQ0wban55Ir4Z5LfRlj0STrmo6j5rCHQhHOy8DWlOWNFWWNKjw1ZCh cSJ7mtU0klP/KIZiPcCX64Y7CXp3ncD23NVJ9ljG9X/WYNfjMH/VpA4IvKk9 t6sGBqLMed6ui6rNON7vEKUVldhtmFz6vWi9+H/GheCRnRaTLQ/i0A7VgAwg vQjUHQm1DCos3QiL0NqHsNIsXcSq3dqCoAt+4Ae74Ad8kAuAUAixXQiE4Now 7o+EUNv++Ns2XgiDoAZosOO9LdvITMxHfKDXW65DRYN2ec3K3b4XUyic9jCu aGWoEQnWQM9wcWQTVxGGhqzaOZMTsQ4CgGBhPuZk3qEIeHIqVxFhbuWD3A0/ FlE7KgAFAIzp4EHYFubqUIuCLABW3iZjvriMi92hGea/6B5kPuYE/8CSh35N Aa6pAf7nVzjB67CjWU6ixdXgbPED5GDZqeDRrOw4pviYp4IITnMq++nhuly2 rc0LggAIt5ALueAHt3DihDAItm7rgBAIgLDrgsnrgWnr/jgIhACYur7raIAG gdDjOd6fA7nLk9igRJ1ILH3abtCoUQOpWyZdUt5RGDkZJ2sR3/4Q+gfuCX2y 4Q4RCQ3uFLGa5y7I5r6jU1jfyEkRUtju8F6ToSnIUxjvA/Ht8o6c8I6boHnv +47pbvEF5CAArOAMScMtYsIIilAIhyDqutwJpdAJl2Aqre3auqALK54LurAL fMAHuY4Gf+AHg9A9J5/rgwAIfpDrZxAIgf9wBj3e8j2+62cACH+Q8ynP8jCe CrDwCqyACn4KqGcHd3Bgg/jJxJwSJQ9ZGl85ZRFGnh0lAD8AI+zx70YhrFpv 8Fk62eTgDq+ACk1y0mKynzQ44qkQC7EQ9KlA4ru+4q/+8idu63UPCGfwBzvP B38g83zgB2fQB36Q7LsOCMhOBidPBiP/93of84BgCa0gC/QQD7MQC6hgCNNw ChdPdmt2xKbt+SzN2TvsCGbFhw9zRg/DgcEg6PbBbGnB7l4f++lCC+/QCtx6 9vypCJui8a3wEPAQC53g2rtwCtagCpxw4rsQ6y6/C7sACLh+Biqe8zBPBoF/ BtbvB4Rw7GTQB3z/QAZ7oAd6sAfU/wd8MAqwQA9AEA/xAASykPl4IAt4AAut YAiiyIn2iNr99dwZVh1iCRDBggl7FCnSwGvCBAbbti7AQ4gRJU6kWNHiRYwZ JXYbME7jR5AUfbwbMCDkSZQpVa5k2dLlS5gxZc4ECeaLOkaLFiX6lciQL0M7 D/ny9SpArXoB5LUStCsXHnqyTolq9coVq6mAcvkJdMbPnzNnBv0B9Mcs2D57 yHj1c2YPnz5k9sR9q4dMKjyz9Oqlh4dVLHr0ePDAgwiRG0ZuEPk8hOiQITdu FjFq5EghI0eRhDlqtHAzwYHChF0Lds1VN5qpWaoj4EM1SpImX8+mXdv2/23c uW93e/Wr5yHgQwslWjR0GZ4As/C4ljVN0DJZAWSVwkOuW61xsmLBeqVKExk+ gMIGQuMVjZ+yf+Dy8eOnj59bet72oc+HEys8sfDkj9efb/946HmlEEQUicww QxBhg41EDJzMkWA4Y+SRzSD0TCGBRFvomnRo0e1DdQSY58OKxkmnHddIVHFF Flt08UWKunGll99+Cc6XQ4o7ZJpYAogFlejsecWXU2YJAI9TxvliHXrkCWOe eeqZ5RU+SmElFU8CGQQNQsgg44+0+BDzK/bi8lLMP1JpBRY2YckvsFlkkZMv elpJ0EBFDHsskcUSIW6RzhyhzELOggFmoQsFev8kGnVgnM2HFF+ENFJHK7X0 UkwzraidnogaCrhCDklkqFSiw8OXVuSRrpNUPHqFlVpqeSUVV9yUZR0fxjnl lVpmaeWP9u4wZZRQOCGDvjOA5UOtPZrl45ZQWGmFFWlfySse/fCwlR4gpDoM TzYQMURURfIkjpFgKmMEM4E6AwYYdw8NjbRrWtX0Xnzz1Xdffh0dp5pffOFl KF8EGRfHQwRZxSNYdCklunpeWYUee1ppJTlVCCkEkFBM4ZUeVmABgxxX0lol L1lgOSWUVUYpT64+7IrrDPtGKeUUamGJZbuqXnFzFmxXCdcNAxUr1zDD/FwE 3ggZkbeRztw11FBgNCz/zRrU+tV6a6679vrrAATQpBddeCGqYODO1uUVIOR5 RRddWqlFOljIqWUVWOaRahBCABkEkFRnwSu5UzR5ZRwwxBjnlVBeibMVmpfN JJSz2nOvjlWsbQUVVFZZpRU8FogHj1LEZaNcA5M+pNwGJWM6GMqghr2Rd6mu XSF50fkCbN579/134GcSwxpdeuGFl16MF8SXgAXG5RVyQM5lF01imecHcn4Q 3Ho8RDkDEPDtwEOMWFSRJQxZ8JPnh75U2YQM5MB45Yw++LADdFhaEcUsuESR dpVLoEENb/gLPWZBjx8BpQ2nO1CDFLSYxujEEROEGrycdqh3YRBdpDkUo3YX /zwQhlCEI+xdGNZBDVx4KmBmQ1gvBGaKqpQCF7rAxcQgIpXoyKIVqYCGJgbB iR7hQRWzmMcsPII+VlTCLpuIRa5Y0Qe3tIIeAaAFOeZ3rD6UAktgAcQ0WiEL HvQnKqkoRIIQ0YbI+OlofVJaI4TRiHWtC44XxODtDOWNhZFQj3vkYx9hFIZ3 UANuxiOKIAx5CN8QhWw0hFsulGGtWIwjFqLAgz0e0quUwWIW8IAFK8gRADf5 QEjNmssoZgGGWagCLkOEUlLwwIn1xAVYfxgFLAIEtAPGohRqKOMa0OgGNhiC QYYYFxurBkdgTCaOF4Sa0zpjqGugw4/TpGY1rRkTdf9sAm5lM2QucgG35Qni m7o4Rin8gAtv2iIX0FCFKnSBF1mMQ1ViGNFDqpKUV4iiR+NghZf+oAqHxMIU fQhFj+ShswDoKlnqIYMfNBGyneFBFvGYBRDw8AY1qIGYv0QEgcQ1HFH5aSC0 W+a7lpbBOmLQHZS6Zktd+tKWuoMTyUNkwbZpyIIB4p2vmBY0cnELb85QF7vw QyhUIS1b6QUPo0DOPFoRiIV9IR6qAAsrVIUHS/QBFkpZ6it+UI9WgAeLowgZ m7QVi3h0ixWFyCgv2fAGNxjCYMEUpiH8lIgJ5eSCS9MJSoFBx2BM4x0wJWxh DTtCMaRjkMfThTd1sbyCCaL/ENR5hRdVYQplOPaxTTEkH4basVOoQhSe0OQs TuGHQcgNfacog1Hctgde+YBkMPRILO5gFz94QloWq4pE+5KKjLKVrWsgWiE0 1lFihmpUjIjETnLCE5309Rd+BcY1quGRw2ZXu9vtFy3Qgc5GetObhnShIA5x slLowotXSsUpyqkJ9PwNfIBoD1kEMYhStNOH4IMFEMAgC1UghxyrUMUUA2AP AwImAFO1yx80MY1SdI4V1pLFKzyhhjSkoa2FWEOe7pugQoTTroloRCTuKqqe 8CSDvgGGN97FiGpkjbszpnGNWyQjXODCeLzYrCAe64td7IJIsFiFJlLxilP0 TE1I/0ZFKrAkiCxx5W9aAp9xtxQtn4UsTqw4Xz12Not11CIMVAyrV7Q0iEKg Yk2vQEUa0KDhQbRVDWwgGhrQ7JgPi6pqwgAOce7ak18Y6qTvcnEBPGTYe9yj IvFQdEXuEaBER1rSiX7IpCdNESBEOh4UoYelJQ2Eh/SH048O9aZHfQ9Q21jV K1pHNW6RY6E+FpwC40UhlvG/zx15whLjjppb4TlqrSIVpfDElANBX7+hgT2c 6ISVVIE3WQjxDke11ojwYAY0oIE8aOjE/96g4WxvKc4ZJS4bjh0qRRSiEJyA ximAbQ14W4MV1WgnvFvhCmu0At6ucMUrBJBdAOyjIvjox/8CKLKAghO8Hwtn eMMf0nCI9yMiQMDHPiKeDwM/ROERX3ij9aGPicSDH/ww9ccxzY+Or1rlugnD OFAItxn2Ita9wOnZpnGKS7g7FcLmKd4mbDE2A91iWCnFaEcR55uJYr5nyHYd RuE9M5iBDHoYRSxoEY9U2Dnc20gFKdqQhjinwQxqCHdGIYMINAAiEIWoRjoE 4A5xvGMc6+jGdcixjnHknRy0qCI5/F4PH1yBFt2op0uBsIB84CMfAOhH4vPR 6IcAoR8gl4g99MEPIHQ60vnox6UD0HhPQ/4HnNcHPiKN+H7sI9UBILinW/8Q k0dE5CRPUewj8gOCWxzyK+c9bcT/IQ2hwhoXyINbIXEaTll7QhCsekPneMrT abThc59bE/VbcYrU5m8Vas9296N+BjMk6wyqsBYrANF9AWJUDVvKNtnbz8ug KCIsatDGO8BwfzHcXyIsnfEPFuAPAABAfxhAAAQAxjO1AOA8BHwIemi8iSA4 iugHfMCIBsyHymO9goMICJyIe+g82KO8UEM5g4MI24OIDuSHDty93ltBmlCH WygbGuIxHdsxX9ixssERXwAEQ9IFHSwjNegEVGAFX7MSIZwWnyEyz1EDa3GT VTgFS7gDT8i2DFuLrvAKMggF5RO34GIrNAi/cPsDO4szyEgEPxAgc5gFMWBB ibgHxhvB/wAIuMjDhwBMtQqUCILLOA2UuImQQIwgODeMiB5ovKTAQIpIwQ+E CJHLwIgowYewuAUwRDWMRJgIAwGwheEznm26KRcSGJwaCkIQBF7AKePisDV4 gzUAQjVoLzXZHG1JBWoxBDfZtV+jlps5BU/ghPJgujM4s/tqCzRTN/r6AzL4 QmyzM7tSBELYgzTIhncYM0kMAH0AgHuwpIeAQw0EgAl8CM7LuB/gBxCMiA2U CD68CIJbQIgIA34QOI3TwzX0QGikPCAQwR+QCEYkOAuERA7Eh48rPTyMiAXY R4BEwHjQx4/Dh4z7R4AsvXmkB8UryEZDyITUB4OTSNmLvXiIyP+Pc0OGzAeH RMSMfEBGfEaQoIV2mCHig0EfM6QZMiTJKoSziSyzUTe+KSN1ays384RSuIMm k5ZT6AQ8eAU1CJlX4KlqyTI0cDdTUAPwkS/w+R62qsI++APyMA87K4RyIYQ8 yITTEMkfWDhqrEZ1DDV/oLwf6MBstAeE+8M8jMBsrIgf0Ad2nAi4XEsOdEeT 6wFHBAO5/EZ6GDlQw0d/XLiPsziSmwh7sEd8SEzOe0jB/LiFM7jDnDyAtMC+ TL2PQ7kJvIfErDgJTExFG0fYW7hKs0yAHMfK3IfLHMcOnDyJaEDRFEmUoAVX yLFBIpsaNBse00GWhKxCAoSBISb0oMn/QkCzKRuEsFOD0VqDO9ghNcicodu1 WEyD6vMEP1gL9fCKXRzOMwCPsNA2+vJOMxKEPdCDf4NNa4SI83wIfwhLaMQ8 2NuHrwTHuIQI0gRI0yPB+VxEdgzHiIDEy9MHR7QH/itBuMxGwISIfVA9RHTA B3THAIDEBM04IEjQdaSIxdRPPJzLiADN3NPDAx3HC8XPKepABZRPzoNNlOgG a7CF4om54lGk5ElJHuzBEDMks0kbdTsEmeSbZCOEQQA7m8w2MxCF9sIZakEy ixGFoUyFNAC/MxiDMQCTM+ClLQGTtdhFtgAEQrArRBCEPCCGZjRP9nzDMU3P tASDeJDA+KRL/3FEzYR8TL3UUIqQU/40Qbv0Rkecx72ECIQDwQMNAMlry0Ns UMgzxEC1w34AtTptxG98UEUMTXHMxngsPQ910IfLRtRsR4PrwAXgBwtEUEpd UxTFiHXgBlzYQeNZSZpbrN0Mp0LK0ccwBHXzBXUThL4ZBEPyUVw1Tm0DwwzL sDsI1lJIg+nrOffLtjEwD42aSn8CFvHrAzTzE0G4hWpwCNj0B36QiPQEAgDQ h6+0hwT1gW0cuPz8PEGNvH3IVmgsV0it0Lr0OJCb0EddRHhEuYz70z8l10L1 wAM1xEU11z0UVDm9VG3kB4asVBUcR9Ckz8zsvHxwT0ddgH8d1Ypouf88AKpB ghsW2sGy6YVdOL5XlVVZFc5RFATw0RgeNVktDUNdLI/uS4MyiNk7eLo7GIOo K0Zs07D1ox8v4QqfXQtAGI5EKARiKIBPuo0v4IEd6AKm7QIu4AIv0AEeuIIu 0AIuOAFRzZd9AAA8TE988IdPfQj/KzhPtYh/XVg+7YdNG1h63M9y9U/KS0S1 fMcAwL2FxVdLJUcHNcR+9cCzPVeAxc9IDQCEm8AN/NBsRFuATcEGHMF82Id6 mFiKnYgwEAdbeLUZjDVQtNGyOR6WPJtDckkgo1UqNU4f/cSPFYRAIAQf5Yq0 Uzvwq8Lw+9U0gNJkvdkuTIM1WINCCAvrZNn/8vgD80KEQcgDQ6ONK+ABHeiC LbCCKqAC6I1e6LUCLaiCKZiCKtABramHBejW1TvPBvSHfoxHlJtGcmXLQuw8 uzVHiEhHNu1Pu6Q8H5BbegS5DhxTvFVBs91bfs1bfy1XxV1YtpXACVXHw81b hQVcPjREAAVUCQQDyZ1ciXAHW7BE2mSkm0JJ5WHJENsFLa1RP1A3ddOYHAQf P+ib8xuEQAgEskC2QajOPuiKmYlKP5A6Mgi/YRTStjKDMRjGYnQz+glhRRja PUAHZ6QJHrgBLciCKogCKIACKYhiKIgCKZhiJ5aCKAABEXiCGICBQeSXeojG 9UzQAExQfjBAwA2D/9zTU4r42/RVND/ENAYlxHcd1ACYXxH8SpOzOHP80zRd AEr5xzbmX0X740BWWzqWiLKNiAYU2PnsTHc84ITNxkWGiEZ2VEVDuIHshymK YAl+iDBIhwrGBUvcpuTpBc26QUVano3RUt802eEMJ0LIKR3sm68QBDdj4fZQ O2BJVvL4CmBpj+1si7V4M2zjwictA9zVOr9RrkLIg3agiSvQAScQgil4YiyY AizGAiyQAm7+Zm6eAiZggid4AhkIAi/gATbeF8RL0H3wh9RL0MfL2sLVW/Sd iBMNgAZs1HVcAGp83De24zuWW718R4LDh3XG5AgM24Id5H1ttDnWxn5wjf9/ beDA3L0BLtBBlOTBhcYxRThFg9DH/VRP/mQxQIfLHeUcO2Uey0SaA8XOFYT2 4EE/8GARbuX58oP7amEV7r6o3JKw6OHuZDqw2M73cI8Vfj+y892oa78ubI9Q IaY8KE+YuIIbIIIjeAJv/uatBmevloIZgIJsnoIomAIsoIIt0IEr4Bd7YOP0 FFXFG7kesOc9LL3NTEyLO0vSM71EQz0FRT2GtlN4lQipEsH3TMfVE2wLlcBI s0eJOLx0hd9G47x8eETAdleJ6NNHvIeHHdMB7geIpWPEfQjNTrTOHs1Gw4fy xexPrghaWFELtkTHKq/GYqRw0s1pFS8+yAU+0Jj/ET4/E7YcD1Zh+qqvYxsE f6KfPjAD99jOhgoLKBJGO8so8WA6bDuzbKOfQUiuPHCHmOCBIshqKH5iKI7i KPbqb4YCG9hqKbjesjZrKsiCLkjsfUnPCEy9eDjiQb7viCu9etBTirO4hvNU eojTyaNv1BbohyhsD4TLzhPVfO0BB2c4faDv+/1DSAQCzmu4fEi1f8U9lFu4 dDTHz/ZnuhztulVthhvxBHfgsCxpCSYHasgDC86xXMAFP4DBb9IKG+UFnZLp n5LtWwiPTyTuQECPY/PR4kYDZ/2eI28LZz0W62SoL/GSLwGLXwwEKd/FYzuL twAEYRKEZ2iUl9CBKngC//J+YjSvYihGb24+giPo6rHG4usN5yrogrWusbbO 2kxLtH58CTDI2pMYsz5HtYQ+iUirW0EPuURD8NlgNFRr7ZgYh2eo8XHK2Nr2 JvAxJEDYhcYCqltwilsIdZUt7l32m0EgKkCgjyokjyMvj/T4CvRwbjMwEy8Z D3Vj8vZYYeM02frZg6B1DG0Qh5e4ASFQ83JG8/Eu7/Pm5ig+Ahxw82x24jqv cy3gAUnPdm2/jcqlcRufwUzcinFiyRn1g2cZcm8adVUnBMsRhGCmLz4wi/pp i/MQt+2EC/l4Cz6QOvqwcvADlrXbmOr8kq/AVXNnj6AFDm7ALpa4gSBI9iVQ 8/80N2+K7+YZQAJpd3Yq1uZsFus733aQD3mZEAN1uNxLlzUfeyxP3ybkaQpv ehbeho9l4QOxoK9cCO72EJNkEZN+/54yxKIx0AOh1wP6oAsy6GEveQ+UZXL6 AJb5Ug8x2YVZBgQCsNaV2IEmqOJkf4KIT/PxlmKLj4KMN+vrFWtvLnsooAIu OHSRb3u3x4h5SIc8QKdL/6ZQDEWWxHtf2KafAio+ICox4QMqqy+x6BuZrm4x AQ99dw8xGU+4sPJmkXKhbyiu+EQtB4+2OINPNOHdzoUtPQQCkLGUqIciWAKI T3YoUPavN2/1ZoKMz+ax3ngoJmssjoItmOu3z33dnwj/kqzxTLz7odpN3957 lx/1m99t9qjVIz+/Y5svFj4W9Tj48Ih3MHmLtoCLZpGPtDgW6zdOQFgP+voe +hqEwM8FVrYGeGCJE0h9rn8CON/6NF/zKpYBsedqZwfn69VmZifrIwCIKFOi ZAES4CDChAoXMmzo8CHEiBInUqxo8SLGjBo3cuzo8SPIkBnJubKF66SulCl7 CdIliJcgQb5iFio0E5CuW3z8AOKT6xagQmoKEQL05w+gpIH+oPlDhkwfP2f6 7OzJZw9WPlf39CGDFSqfPnv4kDkTaNCZqU+rJvWj1U+upLnQbaxXZMmTJ0uO 8M3LJC+UwIGlSLERRQoWwogT/2OZguVx4ylSmBCOYlnFDIFRrPAQ6fkz6NCi R5MOzaNH6dSqKYZZZ80kLl27dPWizWuly5i8fNUsJAgQXJ7AqwodNMgP8kFJ AaFtSobpUqNiseqhSsbPnqdcr2rlCtV4ILFPoRIidFyrz7i52m3cAUVK3r18 jzyhz4QJlCdMDuPAkVgxZIgt9lhlUby3XxQ4qACFZVBYYdBqEUo4IYUVjsaD EENYuGFp43CTxy245KKSSrngcptMvqgoU0yEBIKcXHwkNYggNQFSFCBnLedW WX+cgQYaZpxxVR56PHfGH1pBBdVYW+3hxyAvjoVcckltlYtPu/CRzkZJQIEX XkfsFf+mfn/9JQUOKwioGIBtshkFgpbNIIMNHUjQwRNWoMYhn336+adqSgQR xA6AGrrRO9TYYuKIusRGYkoszjRTi37sEpMgyDklyCCFGJejp4HMCCMaLw6C RlrTPecUlV2t5RZ6OyGXnVhw/QZrk1oV485GTogJ5hLy5fVEfvpJEcUMbCq7 7GHvYQGnZfd1cAEHEDAgwV9F7Hkot9166+2eSQyqw7flOiSGONLYAttJ7UJ6 aUwzWbrLbLoAEtNwfnCqRpSBnKGGUmgM8ocfoiKZ1lFhPYWkkE79EdUZVKJ3 7y7YvSUcrlntRIw4GtVTxXxhzjdffTbg8EQHhxE22GDMMrj/cmBwQkGBBBxw UHN9ONzAIT33+PxzPNwCcY+5RXO4QxEH3TBoZ0Y7HYA7xbQ7tUoopTSbIBXz IWIuu+TiG3C55KKveebleCN40QFXqlNdiRVWxOO5ugeSU2p1Y6Za9YFUW2Ht cQvgMj7zzjwY+XBDfmLSJ1+w9T0hgwwzrLACfvkJJhjM72UuGBMzPCHBAxyo cIEKR9hgAw1NV4hPP6273s8+9Bh6Tz9P267aDkIQcVAPQyR9e9ECZDL1o+2K zbXYycOli9h73GsV4FCaN0h5N+K4o1HO+Y3VGGO4utPeY1zXtlNnRfmqvVDC BfgtIPKhzTgZ8UAFfEvUMDJfp+OP/wMUlfv/3uUYRKwA5ocJOGCCBBpAARWo 4HT1ecHvVqcPhdBjH/j4AWkWQLR7LCAitAMeCEMjLiL4IIRGE0M6bmEidzlK RMhDXvLExgfAXeonY9HJjcz3m+UwxygFQ8oZxqKHPHBFSAtLy3OgIhWv8IEp xiHYeHgiRRX+LXrc6IbhtGCZvdwvBvR5nAz6cgQcHOE+ZbwPsQwkBcEQ6z79 0w+xTHcfJlCgARIIwQvmczoWGMFC+JigQv5YGnrkQx/5oEcJH/JBEzLyIyNs pLlogY5FmUglvKjNSWKIpeT5hH0qzEkeQokVvhECDfd6kVGOkqOmIIkMetgD EcuyFlmWhf8PcVMYlPpGBlsiRStYqiJW9kAAeGAEQ/w7ggxq4MUjBIYJY8TB 6WwgAxEcYQYnu88BDYSfbR5wP9j8ZpouwAAIXICaM8jfDFyAQQoJMpCADMAC 8CHPBUCIHvhIiAYRYk+EACGe+OjgQexpjx8QNJ6yo6A8fVa7eNLzIBxMiDwd CoR4zFOfEU2IPe8ZAHwcFKMahWSFHglSb3UDHSF6VC9Y0hJIaWU2wcES+7rW vlASsQ88vCkgqPJDqaTllWSRm9ug0ocfOWVhfsCRUfcGlyRhhYiwzEMBMmIE JojAmci0ATP7t8Y5mm4GXu3PM3EQrW0S64AzMJMby+hVCjAgdKT/m4HJbMAB DOyMne88CBAsGIAf4MOC8tyHPgyyyIPo46OLjAc/+KEPffQjsAEYLBD40Q+i JQSxit1HPvqRD8DCziDtfGzrDgI7wDIWkLTrB0D3yrraBWCyCxmshXKQhLre IAl9DIAOlGCEJESwCDlASBJ2IFva2vYguVWIDmYbACXUNQA8SEISAnADJSCk tqqTrhJQowMiBGEISeDBc6N7kB1AF7rkUtp3IVLb2x7kudmtbhLIpdv2xte4 ymUucutr350lN1z6le554auDHmirtuc1MEfI8ZpeoLQXKBLEiMbmh6uNTRdw eUvF/kbTPOjUlDBCTlp4cqpA+EuowYyK/x+64ofxRKwPLiaqKQcBFiq9aHtN hSU6xHCRH3gAmvVJ5gH716xm9u+A/YHmV41swP7N0YBcfYLJcNABtiqQAzNg IAMpQAEP6HhC+FDsYhfLj3xAyLUI2ccC7AHbwiJkkYXkp14Hu1kzI6SvEMqs RuPh2s/uYx+s1SxC9LxBzeYjIYr9M2UTAtsKcVe84vptAJJABB0MCiGD2lMQ thsERwcB0pJWyAjF1WnjMm3TBxnCoITQNFGrWtSVpnQQDpKDIBRBCIMSL6qD oGqHFGFQ3UVN7gY1hD01utdBMEIPbE2oSAeBCKKGdACMPWpmE2Fp3T0Id4tg j4MIgb3Y3nSvff/Q6G+LVyPrqAYuUlobddfmJbIRW1K8JhtAjG0nEN6DLWa6 k528CC4VkwpPVAkkslBlOlzR2FNcbJ0jCmxgZxhfUqKilZmGkhhcusgVYLCX H5OACE24z5D7V+Qj28Ca1nQyym2AzRUcE64qmNwK2MqAC1DLZiqYMgdKACEJ 9VWePv+yRu2xbYSwec2GrZ09+JHojeZDzaylHdQT8gNDHsQeC+jHzvXazi8v ErUI8UGcUduPgy6AH1cX7dIdytoNzXp3AeCu22Xbg3Hhlu5zD0Dbvx33ch9k hEOYdRA6A+tZR3dpuqV1AJJdBEHFl7verXusdzAoIIiLutINwuEjqBD/QWm7 16hB9Q6W9rts+9p3vk6a3wHfmRsIIQe57oy4hqDsYzNbQ4kPvEK4C/i3m5r3 fMfIOKiRbnWryBcpRZFKdogvfGENELfI9ygJ4SMYxUVJKOYDL6Sj8KK6Mjvj WYt3dhmVGwEiVTwRVSDQMHGa3oIYvLpID4gABc8hMwNiuMEQvLnNv3QTrCVP 05F5DjaNkZPhgDW9gAqwwJTJXM1QwAWEwAVoGQVsQKF42V0RFD2M3Q/cg5+1 TiHdk9G12Z+R1mIBFmjtlV7RGWEdXUKwmSBloAYhWguCYO3oVQAYUteRIJmd IIcIiu05Hrb1ka31Eazxl4b44Lf9oLcxWxDs/wyqUResoVoS+ACqoUalGUEQ oEYR9NEIlRCs1V7d7Q4VZmEAVNpCjGFn9E4ASJ4TBIA9oFpncJcQ9ICodd61 iZoTYl4AGAG58MCgUFcdCoqpYWGs4ZYQLITjVdq4+R5HiIPw4YLxpZTxqcht rAgl7gam8AK8+EYuNInAlMqQ5BJSJImM6EtKhEXBLZx4JJweiI8rvRJyBIJ5 hMcuFQxzNAVZPFXFdcxFAEEVPMEF1IfO8cD9BcF9IIEbzdGRjZFXJZnJWFMA MuM5yZXkUIC1jBPNSMAEUMAESIAEQEBzRchnJcRkAUE/4MPPsA4NzqAIilY+ /Nw/neCXAcEPqOANsv8g0d2TIC0WD6pg0dVOXwVABvbMn6Gjz/DjolHIF5Zh pVFhoYybqBVe0iykrwWAQ4LapTHbRKbabPnhIQYAqiVXId4AuYjUF/ba7nyh R55api0EpX0k3uFd73HXznBXG0peEy5XpYkaaohL0myLFDJhZ6Ba0vjhsvEW Ig5KESTNIi6iRqhDNvSCLxzCIUhlL1BlVRYfTFAiJb4EihyCL2wS2pxKGqDS cRCVHwCJHxxFi6XYUbiKU4RFWIjPKxkJV/yBebjFVBgFc9RYWNDUHmjDOxRT FcjABUABEtwDD4zADpxAEOBACfTafZzckSFZybEcX0hOM9JJyZkONa7AlEH/ gAI0AAR8IwRAwAM8wGk+gP1ZIENMFu3Uw9DdIw+uYDsGgNIpxLbRDj2YHdop BNUdxNV1lNbpQ9nJTtelVgCEXeKZnSB1XaJ9UEJOiFGeRq6RSxCUUK8ljes1 mw9Alw9UZ+/QXXZiZBCAweVpSBGSmttx127pIXA1G6nFGtxBXhh+2xJSG0Kg J032naktIt19oaih59LYHkJApK4dBEqWkK3tTBFMYe511zo1Ze9phDvcgiQe wi/8wlVS5VSC5aTUBKVgSvHNRG5MT00oRw+tKJCcgRkEycEkyZCURVcojFj4 VHeURVL0VFkIB3Agx4blATesQ+FYhA60gAXIABPk/8AXVEALGEE9CAESGAE9 DAERFMEQGJkBNtDpeFWUeWkzroBmqgAHdICZapkEMEBbeWNqPkADpGYDVAAt uGYgYZ2eBQ1eMWc+3mY+5MM6bdQE0U6fomdrpd08EtY5qh3R/JENdl3THcSd nmAY9KnZOd1vCic/1OaGjMt2DeEO2N4jXem1OcFtcSoReKqBxqfbfSGsrZp8 +p6oWR61eWGl5Z2AvqpTIkSv/V5I+ufuAGhL3uqqmiHv2Fp0iZRI6R5IBtiB Ih65PatGoFAuXJLxYeVUfqiHfuikzARR2ARVyoRNdEqNlI1xGIfApB+QoIqL wujCvOiPxA1Y/M1VuM2nuP9SV0TMvVAJxeWBNWBRRYCBDghBBFzAESDBByzN CnxAAJhABYQBDHgAEDTmDTgBDRigCMAVXD1jNGGGV63Ay91cB3AABUyONaqp arqpmzaAyj5AAuzcanxZmJVgoi5nY5Vg2MUsP5Cgn+0VYpGWn3UQ7fBDR9lj b16WOnLWPhwE67xTDl4WoPFgBu7Dbv7ZO/7VOvIJdzFXDjSaDvzOS1IhIb5d BWbtDWztpnXtQpjkqxGrq/mabZ2er84nGGKhhrTtrbladOWqPdCdfgIruQir 3B6EEeTasb4qsspnIUZouVHo71mEJNFGtWKlh2qo5IKotdpEIRyCIRhCb5RH 59b/BCHcRKmYT/ohCRqkgZCcwRiYAeumLqqQgfc0yXTwQZRYTFm8SPVoCSzN VAHMKUX4gBK0QAoQLF8EQcXiQAaEgRGcgBK4wAl8wAbAwPIagQvIAAuswOk0 kOREU8k14zSG7M1MC+io6ZuqrPmirAOcwITcAzwmVD2skz9xVD5lVPv+3EH8 QD/5HJ7aU5rVWUdZFEfRzgb+056wbzwM3T4VKvv+0w+UUAJvFEAlMDwuwPs+ 8IbsahIowaw9qHgZZQDQwNwFXuJisAbTGnSl7auyKtt2V3nFV7L5WqGobeRd 2qz9Vuy1sEjeGiMmBN+Gau8F6E6msBluJ4K6nUgR4qcy/4RTMu5G0IIr5ELx Ua7k/oK1gqUgSG7xGQJVYq5v9IYXm8dv4EuUMMePBILrti6QtK4ZLMx1WEwT /ShWdIUp4YtbtM9MoQMxUUQSiAAfe9ESIEHFYtUQ6IAY9MAIkCQNwFULmAAY fAANKMEIcCYDXVnJvUCXZmyZqoAIaNlpNoCaMoD5enIoO0A8JJK3zCZFgMGf aoTTrRMYEKob/gAsI4Q9ZgQq94m4OMGkjVARBNgf7s6g3IDbMZsui+SVMmvc 2udCzqpCWJupybCC0hoNzCEzx6cO5ypDnpcPixcQxxo0+6Q9FHEyG2UOaF6z Lu5MVihGdIM16AK2UjFVajHlwv8zWFprFG/uIRBFpxQC53aucexCX96Li6Rf wAiJGRt0uprB6prB9KGHvgBHk/DNDvVEFeWBxRVpRPzAHouABViAFyGBC2zA BrCANNFADsBACdRDwBrgDBDBYmYAGLgAByyyC9CA6FyylYmpXHEABEKANUJA AyjAJ4fy+TaADmD0SIHEdD5ELUMSpRHBEPDAS7p0sy4l7zlBBD11VE/1dSWz CieuoAxzQrCefELzqV1p04R1fpkX70HbQfRwELSh39onNKNaH4mzfnJbd4Xj Off1DmPEPKwDNfgCFW+oFGPlhiZC5RpCidaIh3oK6BIFIRQCD/0G6ZIYlfiB pzwcIDT/xVD5SJCkbvkRzFreC1qghyzScXfsbjO8X0RcgQeAgAhMwARcQAws QRO4wAyQQAmwwJyYDAtkQGMaARGMAA98wAhsoAtkgA6cwA24QAsQwQac0wyI DpnajAhE4AOYpierqVCDcpuqZgOkXVJ7xFI7RFM3Ek7OcIIehA8YW3Q5ga6V 23qvYaohhBHsWuwpjXwu8zIjV1kLcSEqQara50PkXUL0KiPO9a3a3tIAc0vi tUjx3rKdGqQtcTo3Lmu8gylMJTzT82H/gmLjs4dKCosEhW8IAiHUCPXMMXCc QWc3BRqAWI6s2HWMto8sxVP46FGspbmqRVS4xL1kCkyBiDSo/4NE9AAMpIAI gAAIdHQK4AUJtEAJlMAI9LZXvZwQeMANnEAP7IAJLG8GgJcHQHcHVIA8eEDG soBvY3cIdCMETEAne/donm+bNoBylrdHDI1F3IPLJvWguJ2wJYSoleSgeFug v/W1saQNm6FPGrhzMU1C7EAFWmleL+QQFHh1PsTSwKRF7ipL3vUPB2sQF+Kj 052EvyoT4ndGYrigq/NFqEMoXOUvEDYiKHblHkIiJAIiXO6K4MSPQklv7JCo jMqMnAqQ6Gj6FdUaE0zpOoVZLEeSHJW5+kjC8URRwAVMAQ438OJD8AARpMA0 ibsFTIAI4IX1toAQjAAMuEAJtEALrP9A5KyAC3iAEFSAGHhAC8TDDmDADKDA BvSAEZBAAnqADtyACbxABF6AnEOABcS5JyuAUBc1nOK5Kes5xluIrbUhSDrr QQhioVhbBeo1xxOlpQX4sj2hD/x3UK6hwIsXEfyWWhu4UipBgLX8DmwLQhjl eVGX6Ck6ajB4qReKyh86QxauEas6Fg5zof814O2AIGo4RbjDFYu4huJ6r9Pz ruM6iM6EDMGUjEA22OzIhzGHcrDl2aDBGDyc+K1lUfHNjtqUPhvFw/WBGfQb wRicTlRD/DzEp0KODKSA4MvABHj0EjC5CIDmBli5CYzABtBACxxBzHXAcpMA CniAPWQAB6z/gBIAQQmkwAbcwNDIgxJoAM1t42mCDmoygMSDMlGL8ixcfMbP foQwMUIs5H/vsFMmurgIweJJ+n/3/g2wXqQJAaXTHqwhG0X62q8xmxAMv6cn hBwagRLsTrLN4c/vcDc7/+/jXrYlga2hnuGq+txBW9M7pTN3F6z/azpM5a7T 8y9osWLPP9dbcUw8X/IEDvWMMfoBRCBAhAYB4uMn0Bk/Z8igQaPQoZ+Ffcic +WORTEU0gwL5+RNoUCFAgP5U9EPmj8Q/fPrs2ZPnpTVyAWjWrOljRwkRIkCk 8JkChIgJFoBOoLBTxgoMJka4ILHBBA0WHFRw2IlBiY4NI8JkaFHh/0S9ERvo 3bgQwugECBMkrH3AgIECBg3o1o3bIJ5NvXv59vX7F3BgwYMJFzZ8GHFivTmC 3Ajgg7Hjmj2CDKFJ2bLNyI83B7BXJIiSAEmCEBkSJEgOmjpQ2+xxGrVqI6gr 1xSCWgfrIDSJ0EYt+jVt1Xx53EadJAAYJZWFCOHBOwjyALgD6B5dGvbw5UhK LA9NmghN8DXtDZEcYEcQIdClB+hhPEfv9od9oPN16NCiX4cSHdrPH79DDOnP kEN88UUQQPzIJZdbctmlQT8ISXAkP0a6sCCE/OjjozNACuSjPwAJhAyJ+pgo I4s+tLAQkQzqwyKJQOSDD5deyiMPV2jpC/8nGmIAyqcfe0rBgiItGOqCnVaQ AYOnWiDBhChJYGGqnTrYgIQKbhjhgyuA4OGDD+RR4oILJjBTggsgiCCCBuKS y00354rLgbwUuxPPPPXck88+A+NBhx5oAlTQmsDQYQcfkkNUL0IHDbSmHZwQ FLwdisihUEB10KuH+NozgogiCg0A1CR60JQmI4QgogTUirjM0794KIII0WoC tYgdasrtOVIhRbXSS0fNAYYdeigCuR0YRW9Z3nStKQfJeLVJUkxzezYxVwJM BJhE9vuPv//6axHBBGl0MBc+bnFQQUIUtBCQXSRS8KIx+ADEIhE/OqmPGvdo iY8z+mhpYIQKCgn/DZRU8tDCM2js9xYc82jHrx2E+OmnHzMGgc0JPD7zAhlC 4GCFFVh4yoQKTNighQtK2EAGETrAYIMMKoDSg3sCMAtkCiSgAAIIHnATTjnr ctMBevxcmummnX76aUVvSmw8qZt+bYcvvgDPaqj1qjrPILoOLIzk8qSlGvz2 WySRtv+7778C8UNQ3nRzWdDBW/gQsaC7SaKXj1wu6vcPihT6w4ySBNZDDzL0 oGgPx1mCF5CQDDqIXoRIUohGiTNRp+y9TigBhaBA6Enjn3qygE02i0ySgxB2 2qkFmlemeYQRSuiggxBe2OmsCzbY4QYLNDiTLTWHnhOuueIkOgEgvJ6e//rq rb/+sPGgVmIIqXkoDXvxwM9Th/DCr6Wabw8BBhj8vA2QDUQKNKSQAwXRJd3A c7mcxj8K6sgjgyCEuyTCEBo5zCUpYUmN+sWSjOyhcX1gHIfmNYiLmMRCgQhE gvzABzJEDEfSeAdxhoACEwJpSD5BQQxAsEKOdcxjZRKBBsrEgRQcDwM5NMFT XPAyEuSwAxc4ngRKUAKQsWUtQpMT85xHNAVU4Arhk+IUqVjFPGnvaU4wX3LG hz0s3ikJw7leGNaRvgD9oj8BCtD8DlGINpZLXurKhS784CA/FEIN7voIGgTi rhGdpEQLpJFEDgLBPVxkb5DLCBkO0i+QkIRDZ/8YiYhI0kEy3CgP1ZiJXoAw hBig4AU3DAHGUvCjGLxghT+aQAQ8xsoYFkkDIrgABy5ggQtgwAIoK0HuxkKB HHoMAhIw3iojELQIwEUuzVvimzIgBis+E5rRjOYXm0aELU5nPtajZmKIcJ7r jYMa/lEb237RC0HcZ431q5/9AIG/gxBiQQdpkRoEuBAM+eEhFKkIIPploQ4y kAyQY4lLMrKgDnpoRnwQyCAk5EeJ+EFieUCHM13jAhmQUmOmrIEKP1nKEIBg lR/zWJGQpAGTjjIFV3kKVDawFQe0jpgSeIAEIjC0ZCpAAQlIAE55igAFzAIe 0hTqUIkKtW0uzTT2oEn/eowgxaMeJgjYut47qtELq6oNGPvxRYv4k4gCHWir hRBEgtJVocBVDo8Z8oMA3VUQi8BIkimZiI0uuTca1XUlDHqYhvawNwlViIAd BGEeBBA6mvygAj45HZAwZoEY/EgDMahBDEKggVLGQARsegAr1zSUI30MBMcz 6fEmgAEHbMABQVuTah/Q2prilAEIQMAC4EEOWeAjAfiIxQJmIY+i/ha4waVa F51Gmk2NpntOJW5iWCPFMIhjFOor5y+o659e+OdtBrKfINDgh10AQhAQstAg BIFHgYwEJBP6I4z+8IeNoMFejmvcRRRYkoqkREEsGcg/JTJWCo0kXSDMhDj0 //IBEFiAYwg+3WJPJ1nKYux0pQsl6za7JlYW05W2PJIQjxSBtrTWtQ9Y7Wbb 1NMF6EUM8IiicFncYhfv5al9Ko4QjHCDIBw3fDEmTBIyE7503AKraaxudcUJ VvupdyRjVVBZCaGGQnAEJINwCCDQ8K5AdHcjCelXSzCikIWMwb0X6qAfBAHP QYJXrBXqYINcQo1NBiAMOugASU+n4AM3+LF5/qTGUBCkyRZJsyIOJisBzUoz XRjEdHFtMYMpgdjKVh/yMOyLKV3pFt8gB2J0mg6McJohNPVOvUoMpjVNtWxa Lx1/gBu3usU2NcpNu71QEHh38V0lG3SsIZEyQh3iIf8FadAiZzBDAT04Boac wdjHPoMkzYoQM6MEEAdS70NplC5X2AQIJWDhgoFy4CKl7rI/MuFHU9BnU0r2 z6yLgLo1u1qaCm1odQFx0GbaANnKVhaW1ve++c2nIfDgBwEf22FygON+J0YM 7VDjGRe+VQGxM3B0xN9YJcIgCQliEP+zYFuBHSP3kmjLAV1kRUaeIo/zDUQB vddA1AyxW+wBHYY1wpDqvGBulxLnly03zkGQ5yDp+UfqBrGIhx7vo9VFLjyF S/TAcHCnP716PEjC1Kk+9abpoMeBkWpfQAV1xIjBFb1wY4DQiSDtjtUXvNgF /hjU9nvdz263GK8AC+GuW3v/pIP4tW+N9BC5RQ5MYAO7794KB6/C9cEMVZbX Q/95kHTYJAN3tjOCjVRnnIfgsT4JwQpT2VGcP7YGoRdS64Y2dEWbHi4NSKab FjBwr78e9nfSjW9as7QfFMFWpPL01gOArMWoZz5BELVednAaIki1B735dE1I Q/vd7GX2tRfPbUQ1GdAIQdPJrwyoEdMNbZGd4QjSxVh1gYu2n39dNNLFLvSm t70RIsplvlB7SYJIlQz0XyRniMgX6cGC+tqSNuREFm/NDmKtBKDpAuD2NMDb JO90JuDOFmvPYiBmREAGYgZ1Mi/zMO+xRikGlmAJNObAWud0CO2zaEothCYB aiH2/1rQBZmrMmCDCG6DaSjjWWaMMbKu96JDM4QgCW6jPYig1C5DCIbACSpj VIZgCBjjxsSH9q5pV2jvVirjCMWIMYrgNLhPCZnQ4AqjjABEnLDLQHRBF3gh 7cgQF/AHb84lF8zPJdzvIy4EvdzLvjrkXlKir1xiYPYwoPLvrvwvDgEBrxQC RDyigaotF9QhAX3AAz7J21in8oqE2zRghWpAZJRElkyq3PQslTYP9PLMEnci pVJg82xJli6AAihgliRAAu7hB14QFmMRMHpAUKwDPZjGxqQGNFTjNCRD+3jw MlJjZ9SD+YZAqb5G+AJgCJBAMmajqUCjCJSq+Xwj92wi+v+eTxmDwAgoIxm/ JwiAYDaSyxl3MBoR4x1M4RdcTVz24356wQztZ/zGj3/upkHy58z+ayBA5CIs 4iEU5K0giJE4ROQGRpDyjwxGZCQMSEMq6SD8JXD8QBwScDSEBBJZyeYODEg+ akiS5BSFCCPPzZT6bLIka/Ms8aJCQAVmiZZkiQNSURVTsQJcTxZnciZtsWmw sCayMACuMAB44DSAsCZs7Liog1SSUS9wkhxpAjRWo/amkTZ4ryh9IxiDQFB6 sSgtgxufYymrQ/oKQwzUwRDSsW28RcgQxB2NjEIISBf2y+IMSg4FKOMwjqH2 0b2kzAwognHuKyVgZJFcwl/2IIP/NmfZJKLKruyf3vAW+mAcamIebqDbPsvb iKQnFoyyGPB0KlCWjEQDiMLBVAAFPBHdQk9kPLEGRGBkgidJUNEoKKAEpIcm XxM2bZJphmCLqGM8eoAGbkA+IoUqaeI0bIU1vGlQXuU6zId7plJXdKDqkBLG Ts0Wd1N7qOM43QM1oDIw0qFtgIFt+uN9qssXeuFA6se/EkQeKa6DwCskxKpF 1rO8GAq9+HHZDFIgS8SSKOJENqR/kuwkSsK9qmxz/sBG9uAWTGEdbOIESODA IFASUcjOuo2FbggpZgjBSucDN+oFPNOEXqAGNPR3TGiFRlMDQqCGZukC0qQD uA82UzQW/2VzaYBxOppQexJlN2uCOANgRrGJOMRni2qUKDWjRr/GOWsPOseH KHm0CQ8DHeDAW9gnjdJIbcDKvw4EvMhMyd7lnNZzPeWnjehHg0Bk2cygf/7l 2P4g2RpIYBqyf3LtXfogIUdkJWpkXdZFk/RCCUKrzmCJwShTAoHiAmeIATNG zyaL816AUEPAUC1LBUxTFU+RAjggdmgpA1RUUle0K2lCN4tg+JSgm/jiWHiP NdrDNoOgCKzmRt2jJm50uZBxVC+jJno0J4WT+aqRKZ+vN0QjOqOKVWnCVQdD HlwhqxaBERpBHbNLq9yR/NbyjsLrIO5mQrC0fg5BfgyBnionJf/QgL5oxCX2 j0NOhJFSpCXedK0EQQ3oxcvETLDiNA+soRs4BQZCixRB4KMUjPKAwqRAUgb6 TLFW6LJGsvNC7zM/c/M4ALNiR0RpyFFFgANcYFQmlWFfj0WXw9OGxUVtgjR0 kCtzrzeeMTRsolQ51kVp8y9AQ1Z19Uhr4nsWlmK7kGSrEldZwzK+Zz32YlcD AwzKKKu8hRHYx9XCRY3Szr8g5CDGikHWZX8Gwcmw1EDUqSAUxFotgq7GYAy8 dS8DKiUygiUkKeMeIiPY9A/Ms0FeTkDRYUdsYh54wAVA4ALg9THtbLHM7bEi bLF+DugqcbJSoAY27wU27zNfIGY+UwT/VEAGLhQDVLZhC7ffZPM9LIMxMDZV bbRSA2A5cMzGeNEo2aMvbkMyfsA0/mIInGMv0qNyLdVimY9wQWMbkSAzyoMq Z+NHlwo1hm8w3kEV0Ii62AcYGIERXK1tepYX2ilOc+F+4pRGDiK9BChBCOLJ lvZCsPUlMuIhlm3ZSoIiDoIhOCQQCCLlDKe9HCoXEFMP2oGiyJYHRuB0KstI 2FYCO2/bIsxuTYiyQMl9U+kzW+gFfiQEagAFGFADVKAqqOIDDBeAn042J5cr a7M29qI3sJH5StZGsW9jPfbUqBNXoUMmbQxWizJmb+JS/CKMTkPTfHIIYEAI dEBqjIAGsHAI/1AWgxEDuoaMOxdhEbqlbdygbRDBQDhIePEnovaA2f4oQUTE IVKCI1JicFoicr70as0AgzxikRAKkgIqRshsJM7FJWDCHSbtJnigAlYApM6E AY3HeEYr83qOsnzusfAVXvW2bjevssYNJUO0z2TABmygKmBgxQIYj/VNNo/w BsCAGwcFNo7RJiAWxkpW+zxYLzqWKY3xVINAIj22CFxTVfeCxji4CH8jUkqg CIXgBqTmBppDCEqA90ijdWN3FHoBXO6jbWCYbRBBEWr4hhvPD3QhYmxBYvZg g6hsJAhikk5ElwWiJAgqRUwOJY6NDxnivOxvYM4rv/4yDwbML+aBHv8WoARG yaRQAJY0s+c+85PUV+c28Yz7zFD19nj67BRRUgVqgI434ARkMo/fGbhk8zSG MhmN4AgZ+DJypZBxjDGQoze8SZGvoxp7oy9u4AiHgPd6Y+tYQ4WZT1dAI7my MVBu4zlmrAd0AHXHRqEPQwzWgRp6QResigzzgxHGkkD4wxCkLY76QBDSBZNg wgAr5Ls2J4MSQiGmlw8ah5H2cm+0tXpDRIMYang5ZCA46J/AlhoW0y98AB7A xKK8zTJHy7L+dYX09ozxFwUu8ANPqTI/6ZqPZ5xRgH81lAWMwJ3hGa2HSjZ/ Izdsk8cagy9cz7hsozfDEYL5onMXlqD9AjT/oJAyoHAne+yir8UmcKI60aMy fAAyhHE5hkMnJ6NxyaaMcAEXegEXiMEWfEERqIvI5Caly4uD9kcQ1GVdYIKQ KIkePWglHmpE0ABbIWdg8jBgzlSfBEYhKkcNDNEAz+nWsBVHrKFAAaNswNED fGQzQ4sSQamUUgleO3CFCNUGZKAGQDD0LjR///VQY8AG+JaOceAG5iGtw1u4 1tr5NoUIdGAXd+xIWSNmQfeuiQ+uPfYvHjZ0H2MJoxA1oPAHbsNWRZUmliM8 avUxQGM+lgN2CYMWrAF/dMEWMNs/Npu6vhOVr2tuxCpByutrX46lZwReZpkl 7jMXeIGOYORh+M8l/8YAL1vCcfolIz4i4/YxX8BLvR7mJW4BHdaVMOphBz5A CMRaBQy1hWxA9LqZmx+LUPkWBNFt3AoVlIToQmfABo5gBf5XvKv8t8g7K3ID UpxDx5DxuAC8VUtWkXOAkeXbL7jR4IaglL+H+2YPsHeTwBXFOm7juL5Ize9k HFyhGva8GqjBFEyhFAJ9GqbBE8buQPBDPM/JF3RheMfLIzCHECRJy3T5fjqo gQIyoFj8gR6Icf5lXgphRjjkIgYiQ2gcR8DXMBQFCG6gBFbAUOmWX7P7lAY1 9GodYDN0bwGXA2bgCGwgCc7ayoNdishbByaNMlZ4MFijzruoRzv2PVRWCf8B o0d1QAhUeDlGxc0RmAdn1DqIEouovaEJQwxogRzWYRzG4R3Q/R3Egd3VQR3c IR3SoR3QwRVUYZ3M8BAEYZbFNeOMliMqZ0Q4wp88AnoH5loNR2CsNiM6PSD5 pv4wR0S+q7tSonufubAQYx7E4Ap0kwVCbwmqG0Nnqc88FJQ0dEM/CSUJ1YSq G8plYAY84BWFXeahySZVVzjLhyt78xbnGxixqNkndmcAezqE3iZ61Pf2Iton Q8sTOjrAgNtbw9u76OjzJAyqPjnAQGvAAOuxXmvqoR5qYRzEwR3aQc9NIRQ4 4T7wqBPWvkUIIuPO68qWDQ3MgB9JpCKWbSAv6ZL//FLTKwcjWjwwp1iwnhl0 8OSii7u6a8AzDdW6x3msT56qHfXIUYAD6JgDYH7mM9+KZLNjk+BVfCBUN6U4 YJUypAPMJVjUStUHhuC4dkDU/LtRjisrB6XaV6NQKGMI9QLH5jkAjlA67JrO aYIne7L2qyPcl8awwIDcw97d2V0c3h3eyd4aVGEUkjfj1MAhrNUhlJgMjC3x lg3YotZf2KwlBuhFun/KlrbxIkYaxCF87wQnPmAIXiDKa/3IUel9TR5/DTUG AEJFCBUvVHDggALDB3k+Ajh8CDGixIkUK1q8iDGjxo0cO3r8CDKkSJE6ggSB mCTIkIhFlDgcEiRJAJhF/wLkUNkwopAcDkueDFBSCEQiMSHeMIlUZgAeRSMm cQk0iFCHRZCa1OHw6A2LO5QGMNkjQEoiDlM6CUNUKVGoVa1iHRnSB5i59cB8 uWv3iw9a696pE9DOVTVVo0RpQjMIjeIzY8iMMTPmzJ8zaMiY6UNmDx8+e27x AQToDB/MZwIBGgSIkGk/ufjc2kPtHVyIPnjcGMHCRo0jL17UCPEiRo0lNYoT V4F8oHIOKjYYyTk7uvTp1Ktbv45do0+IO65m9SEEqw+iNU2SJfqTJVmHJnkE UBKkCPS0EGFaVVrybf2aNuM7ZGpVEG85EYR7FSmxUgBGxNdQSUM0VJVLKfEn RP8QOywVoIDZgQRGRD58MZcPYpDjF2CuWGOKYiqikYYZaJwBGRmS8fFHH5v5 gaMfnI32B2iCFDJIjnt0Vs061flwxQ5FlDBDDb0hp4Jxwy1xHHMHqWDDC0QY uGGXXn4JZphiXrTdUFLlQEQOTLkHxk0PVlgTehL5oMRUAVRVRA8w6RcAfQ7B F6BS8M1J1A47CCGEez605VYAPUh1UVU36KmhQxXe0J0QYTElxA7wkbVohnyO yVGHDs0FRj311LLOOOqkg441qoiChhppqIGGGZS9+McffvwRiCCC6KhZH6AR QogghADyB2edWWPkdT4AcUMRLdigG5Y2LJEllTYgVxD/BzYMoUQP85CKbrrq rsuuRGU+xEOFUu2w4EOA3hnEDT4c5cREazpEqUleOeSnWBkqlQN/ER2K1FYE ixrAUetVxLBJDjtUsRBGPHSUSUMYiF6j7XpkagCofrHqOuK4E5grLruMImKg DVIIkKL14ccgyfrCcyGC5NIaH66QE0YY0gZAi20u0KBbcTVg+60NMyBRQg46 mDty1lpvzXV1PSiRBJcTfZ1TuRQNcXHESehQMsASodr2TPqODbbYcH0dtkR4 283DU0B0jV3RqHZDuBindjPOyrCeqIopd6CRmiC+HHJIIpT/7Jor3QRgeHbz nHvCBx7AUETppeeAuhE/AM56heuuv47dDf1KF29YsN9eXdwRiZHqXLSQ+Gqs qnSySCPAAGP5Lq+hQwvnX34OTz0e/gAd7tZfj/31mkp3w8DZfz9dh6aGgao8 5CTuDh6wvNLKy9S0A4/z4M9Pf/32g6SE3SLlYPv9/s+Gqg8FYB7woEU3atGN VhlODEb7nwMfCMEIStAiAQEAOw== --= Multipart Boundary 0519022029-- From noreply@sourceforge.net Mon May 20 13:17:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 05:17:46 -0700 Subject: [Patches] [ python-Patches-554718 ] OpenBSD updates for build process Message-ID: Patches item #554718, was opened at 2002-05-10 20:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) >Summary: OpenBSD updates for build process Initial Comment: The following patches are currently in our packaging system. A brief summary: - Use 'cc -shared' to build shared libraries, as is strictly correct on OpenBSD. - Use -fPIC instead of -fpic. - Use OpenBSD threads. - Fix the test_fcntl test. Another patch item will be posted shortly for Python 2.2, for similar items. ---------------------------------------------------------------------- >Comment By: Matt Behrens (mattbehrens) Date: 2002-05-20 08:17 Message: Logged In: YES user_id=240525 Okay, well let's comment in this bug then. Changing the subject and closing out 554719. I'll put all patches on this bug. I am trying to verify most of this with brad@openbsd.org, who has contributed some parts of these patches. On cc -shared, this is my understanding: - All OpenBSD ELF architectures have always used cc -shared. - Before OpenBSD 2.8, a.out architectures used ld -Bshareable. - As of OpenBSD 2.8, cc -shared worked on a.out architectures as well, and ld -Bshareable became deprecated. On -fPIC: -fPIC has always worked. The difference between -fpic and -fPIC is simply that -fpic is less efficient. On threads, I am still waiting for an answer from brad@, this is his change. I'll ask him again today. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-12 12:49 Message: Logged In: YES user_id=21627 The -shared chunk looks frightening. What is the first BSD release where ld -Bshareable stops working? Could you rearrange this to integrate the version numbers into the OpenBSD* match? Also, what releases need the ELF test? Could that be restricted to the older releases, too? Would it be acceptable to stop supporting OpenBSD 0 and 1? Is usage of -fPIC correct on OpenBSD 0.x? If not, what is the first release that supports -fPIC? It looks like that 'OpenBSD threads' are 'POSIX threads'? Why does the existing test for Posix threads fail to detect their presence? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 From noreply@sourceforge.net Mon May 20 13:17:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 05:17:49 -0700 Subject: [Patches] [ python-Patches-554719 ] OpenBSD fixes for Python 2.2 Message-ID: Patches item #554719, was opened at 2002-05-10 20:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554719&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD fixes for Python 2.2 Initial Comment: The following patches are in our packaging tree. A brief summary: - Use 'cc -shared' to build shared libs, as is strictly correct on OpenBSD. - Use OpenBSD threads. - Fix the test_fcntl test. CVS HEAD patches are forthcoming. I am currently working on the shared libpython stuff etc. I also posted separate patches for Python 2.1 already. ---------------------------------------------------------------------- >Comment By: Matt Behrens (mattbehrens) Date: 2002-05-20 08:17 Message: Logged In: YES user_id=240525 Merging with 554718 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-12 12:51 Message: Logged In: YES user_id=21627 My comments for 554718 apply for this patch as well - I recommend that we actually first work on the 2.2 patch, and only then consider backporting it for 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554719&group_id=5470 From noreply@sourceforge.net Mon May 20 13:39:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 05:39:40 -0700 Subject: [Patches] [ python-Patches-554841 ] THREAD_STACK_SIZE for 2.1 Message-ID: Patches item #554841, was opened at 2002-05-11 16:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 Category: Core (C code) Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: THREAD_STACK_SIZE for 2.1 Initial Comment: I created this patch for OpenBSD packaging, so we could bump up the pthread stack size in the same way it is done for Python 2.2 -- by adding -DTHREAD_STACK_SIZE=0x20000 to OPT. (We need this so Zope doesn't crash with our shared libpython.) ---------------------------------------------------------------------- Comment By: Myroslav Opyr (interra) Date: 2002-05-20 15:39 Message: Logged In: YES user_id=327208 I have FreeBSD4, Python 2.1.3 and Zope 2.5.1 The patch was mandatory to make site using CMF and heavy ZPT work. Uptime is 5 days already. The bug should be eliminated in next 2.1.4 release. Can we increase priority? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 From noreply@sourceforge.net Mon May 20 19:14:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 11:14:29 -0700 Subject: [Patches] [ python-Patches-553108 ] Deprecate bsddb Message-ID: Patches item #553108, was opened at 2002-05-06 20:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Nobody/Anonymous (nobody) Summary: Deprecate bsddb Initial Comment: Large numbers of inserts break bsddb, as first discovered in Python 1.5 (bug 408271). According to Barry Warsaw, "trying to get the bsddb module that comes with Python to work is a hopeless cause." If it's broken, let's discourage people from using it. In particular, let's ensure that people importing shelve or anydbm don't end up using it by default. The submitted patch adds a DeprecationWarning to the bsddb module and removes bsddb from the list of db module candidates in anydbm. ---------------------------------------------------------------------- Comment By: Martin D Katz, Ph.D. (drbits) Date: 2002-05-20 11:14 Message: Logged In: YES user_id=276840 #!/bin/python # Test for Python bug report 553108 # This program shows that bsddb seems to work reliably with # the btopen database format. # This is based on the test program # in the discussion of bug report 445862 # This has been enhanced to perform read, modify, # write operations in random order. # This is only one of several tests I performed. # This included 4,000,000 read, modify, write operations to 90,909 records # (an average of 44,000 writes for each record). # Note: This program took approximately 50 hours to run # on my 930MHz Pentium 3 under Windows 2000 with # ActiveState Python version 2.1.1 build 212 import unittest, sys, os, math, time LIMIT=4000000 DISPLAY_AT_END=1 USE_RANDOM=100 # If set, number of keys is approximately LIMIT/USE_RANDOM AUTO_RANDOM=1 if USE_RANDOM and AUTO_RANDOM: USE_RANDOM=int(math.sqrt(math.sqrt(LIMIT))) if USE_RANDOM < 2: USE_RANDOM = 2 ## The format of the value string is ## count|hash|hash...|b ## Where ## count is an 8 byte hexadecimal count of the number of times ## this record has been written. ## hash is the md5 hash of the random value that created this record. ## It is the key for this record. It is appended once for each ## time the record is written (that is, it occurs count times). ## b is 129 '!' ## if USE_RANDOM is set, its value should be >= 2 class BreakDB(unittest.TestCase): def runTest(self): import md5, bsddb, os if USE_RANDOM: import random random.seed() max_key=int(LIMIT / USE_RANDOM) m = md5.new() b = "!" * 129 # small string to write db = bsddb.btopen(self.dbname, 'c') try: self.db = db for count in xrange(1, LIMIT+1): if count % 100==0: print >> sys.stderr, " %10d\r" % (count), if USE_RANDOM: r = random.randrange(0, max_key) m = md5.new(str(r)) key = m.hexdigest() if db.has_key(key): rec = db[key] old_count = int(rec[0:8], 16) should_be = '%08X|%s%s'% (old_count, ((key+'|') *old_count), b) if rec != should_be: self.fail("Mismatched data: db ["+repr(key)+"]="+ repr(db[key])+". Should be "+repr(should_be)) return 1 else: # New record rec = '00000000|'+b old_count = 0 new_count = old_count+1 new_rec = '%08X|%s%s'% (new_count, key, rec[8:], ) db[key] = new_rec else: m.update(str(count)) db[m.digest()] = b try: db.sync() except: pass if DISPLAY_AT_END: rec = db.first() count = 0 while 1: print >> sys.stderr, " count = %6i db[% s]=%s" % ( count, rec[0], rec[1], ) count += 1 try: rec = db.next() except KeyError: break finally: db.close() def unlinkDB(self): import os if os.path.exists(self.dbname): os.unlink(self.dbname) def setUp(self): self.dbname = 'test.db' self.unlinkDB() def tearDown(self): self.db.close() self.unlinkDB() if __name__ == '__main__': runner = unittest.TextTestRunner() runner.run(unittest.TestSuite([BreakDB()])) ---------------------------------------------------------------------- Comment By: Martin D Katz, Ph.D. (drbits) Date: 2002-05-16 16:10 Message: Logged In: YES user_id=276840 I am not sure there is a reason to deprecate bsddb. The btopen format appears to be stable enough for normal work. Maybe 2.3 should change dbhash to use btopen? ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2002-05-08 20:12 Message: Logged In: YES user_id=59803 Let's not turn a simple patch into something requiring a PEP, compulsory thrashing on comp.lang.python, SleepyCat being willing to change their distribution model, lawyers (to make sure the licences are compatible), and so on. I'd hate it if other people spent the kind of time I did trying to get shelve to work only to find that a known- broken bsddb was causing all the problems, and that a patch was there to gently guide them to gdbm, but it got jammed because of scope-creep. Let's get this one, very simple and necessary (bsddb IS broken) change out of the way, and THEN start negotiating, thrashing, and integrating. :) I firmly believe bsddb3 should be one of the included batteries. Let's do it, but let's guide people away from broken code first. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 02:01 Message: Logged In: YES user_id=21627 I'm in favour of this change, but I'd like simultaneously incorporate bsddb3. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553108&group_id=5470 From noreply@sourceforge.net Mon May 20 21:31:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 13:31:02 -0700 Subject: [Patches] [ python-Patches-558430 ] Prevent annoying space from readline Message-ID: Patches item #558430, was opened at 2002-05-20 20:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558430&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Holger P. Krekel (dannu) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent annoying space from readline Initial Comment: readline in all python versions is configured to append a 'space' character for a successful completion. More precisely the append character is not configured and that's why readline uses its default. For almost all python expressions 'space' is not wanted (see coding conventions e.g. PEP 8). For example if you have a function 'longfunction' and you type 'longf' you get 'longfunction ' as a completion. Note the unwanted space at the end. The patch fixes this behaviour by setting readline's append_character to '\0' which means don't append anything. This doesn't work with readline < 2.1 (AFAIK nowadays readline2.2 is in good use). Otherwise it works fine with the usual completers in python and InteractivePython. An alternative approach would be to make the append_character accessable from python so that modules like the rlcompleter.py can set it to '\0'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558430&group_id=5470 From noreply@sourceforge.net Mon May 20 21:33:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 13:33:55 -0700 Subject: [Patches] [ python-Patches-558432 ] Prevent Annoying ' ' from readline Message-ID: Patches item #558432, was opened at 2002-05-20 20:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558432&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Holger P. Krekel (dannu) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent Annoying ' ' from readline Initial Comment: readline in all python versions is configured to append a 'space' character for a successful completion. But for almost all python expressions 'space' is not wanted (see coding conventions PEP 8). For example if you have a function 'longfunction' and you type 'longf' you get 'longfunction ' as a completion. note the unwanted space at the end. The patch fixes this behaviour by setting readline's append_character to '\0' which means don't append anything. This doesn't work with readline < 2.1 (AFAIK nowadays readline2.2 is in good use). An alternative approach would be to make the append_character accessable from python so that modules like the rlcompleter.py can set it to '\0'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558432&group_id=5470 From noreply@sourceforge.net Mon May 20 21:35:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 13:35:07 -0700 Subject: [Patches] [ python-Patches-558430 ] Prevent annoying space from readline Message-ID: Patches item #558430, was opened at 2002-05-20 20:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558430&group_id=5470 Category: Modules Group: Python 2.3 >Status: Deleted Resolution: None Priority: 5 Submitted By: Holger P. Krekel (dannu) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent annoying space from readline Initial Comment: readline in all python versions is configured to append a 'space' character for a successful completion. More precisely the append character is not configured and that's why readline uses its default. For almost all python expressions 'space' is not wanted (see coding conventions e.g. PEP 8). For example if you have a function 'longfunction' and you type 'longf' you get 'longfunction ' as a completion. Note the unwanted space at the end. The patch fixes this behaviour by setting readline's append_character to '\0' which means don't append anything. This doesn't work with readline < 2.1 (AFAIK nowadays readline2.2 is in good use). Otherwise it works fine with the usual completers in python and InteractivePython. An alternative approach would be to make the append_character accessable from python so that modules like the rlcompleter.py can set it to '\0'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558430&group_id=5470 From noreply@sourceforge.net Mon May 20 23:47:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 15:47:13 -0700 Subject: [Patches] [ python-Patches-554718 ] OpenBSD updates for build process Message-ID: Patches item #554718, was opened at 2002-05-10 20:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD updates for build process Initial Comment: The following patches are currently in our packaging system. A brief summary: - Use 'cc -shared' to build shared libraries, as is strictly correct on OpenBSD. - Use -fPIC instead of -fpic. - Use OpenBSD threads. - Fix the test_fcntl test. Another patch item will be posted shortly for Python 2.2, for similar items. ---------------------------------------------------------------------- >Comment By: Matt Behrens (mattbehrens) Date: 2002-05-20 18:47 Message: Logged In: YES user_id=240525 >From brad@: > There isn't a test for -pthread option so Python will not correctly > compile with threads support. Testing for libc_r is NOT correct. So, the answer is no, the standard POSIX threads test does not work. ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2002-05-20 08:17 Message: Logged In: YES user_id=240525 Okay, well let's comment in this bug then. Changing the subject and closing out 554719. I'll put all patches on this bug. I am trying to verify most of this with brad@openbsd.org, who has contributed some parts of these patches. On cc -shared, this is my understanding: - All OpenBSD ELF architectures have always used cc -shared. - Before OpenBSD 2.8, a.out architectures used ld -Bshareable. - As of OpenBSD 2.8, cc -shared worked on a.out architectures as well, and ld -Bshareable became deprecated. On -fPIC: -fPIC has always worked. The difference between -fpic and -fPIC is simply that -fpic is less efficient. On threads, I am still waiting for an answer from brad@, this is his change. I'll ask him again today. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-12 12:49 Message: Logged In: YES user_id=21627 The -shared chunk looks frightening. What is the first BSD release where ld -Bshareable stops working? Could you rearrange this to integrate the version numbers into the OpenBSD* match? Also, what releases need the ELF test? Could that be restricted to the older releases, too? Would it be acceptable to stop supporting OpenBSD 0 and 1? Is usage of -fPIC correct on OpenBSD 0.x? If not, what is the first release that supports -fPIC? It looks like that 'OpenBSD threads' are 'POSIX threads'? Why does the existing test for Posix threads fail to detect their presence? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 From noreply@sourceforge.net Tue May 21 05:52:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 21:52:58 -0700 Subject: [Patches] [ python-Patches-558535 ] IDLE windows key binding for Select All Message-ID: Patches item #558535, was opened at 2002-05-20 23:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558535&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: IDLE windows key binding for Select All Initial Comment: The standard Windows binding for Edit Select All should be Control-A instead of Alt-A. 1 line patch attached. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558535&group_id=5470 From noreply@sourceforge.net Tue May 21 06:45:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 22:45:14 -0700 Subject: [Patches] [ python-Patches-558544 ] cmd.py: add instance-specific stdin/out Message-ID: Patches item #558544, was opened at 2002-05-21 15:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558544&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: cmd.py: add instance-specific stdin/out Initial Comment: The following patch adds stdin, stdout as optional arguments to the cmd.Cmd constructor (defaulting to sys.stdin, sys.stdout), and changes the Cmd methods throughout to use self.stdout.write() and self.stdin.foo for output and input. This allows much greater flexibility for using cmd - for instance, hooking it into a telnet server. And if the response is YAGNI, well, actually, IAGNI, because it's in use today (and for the last year). :) If this is acceptable, I'll provide a documentation patch as well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558544&group_id=5470 From noreply@sourceforge.net Tue May 21 07:07:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 23:07:08 -0700 Subject: [Patches] [ python-Patches-558547 ] ScoketServer: don't flush closed wfile Message-ID: Patches item #558547, was opened at 2002-05-21 16:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558547&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: ScoketServer: don't flush closed wfile Initial Comment: I've found the following patch (well, ok, subclassed, but the patch is the same) makes SocketServer more robust. If wfile is already closed (prior to the finish() method being called), don't try to flush() it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558547&group_id=5470 From noreply@sourceforge.net Tue May 21 07:25:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 20 May 2002 23:25:26 -0700 Subject: [Patches] [ python-Patches-558547 ] SocketServer: don't flush closed wfile Message-ID: Patches item #558547, was opened at 2002-05-21 16:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558547&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) >Summary: SocketServer: don't flush closed wfile Initial Comment: I've found the following patch (well, ok, subclassed, but the patch is the same) makes SocketServer more robust. If wfile is already closed (prior to the finish() method being called), don't try to flush() it. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-21 16:25 Message: Logged In: YES user_id=29957 mm. i typ reel gud sometimes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558547&group_id=5470 From noreply@sourceforge.net Tue May 21 08:21:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 00:21:25 -0700 Subject: [Patches] [ python-Patches-543222 ] IDLE Shell window RunScript warning Message-ID: Patches item #543222, was opened at 2002-04-12 16:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE Shell window RunScript warning Initial Comment: Alter IDLE's ScriptBinding.py to provide a warning if called from the shell window instead of a program window. Also, consider providing a warning for File Save or SaveAs from the shell window. The purpose of the warnings is handle a newbie problem of typing a program in the interpreter, trying to save it from there with File SaveAs mymprog.py, and trying to run it with F5 from the shell window. Here is an except of a dialogue on help@python.org: [beginner] '''I have several programs I've written and saved. I have saved them as ' save ' , ' save as ' , ' save copy '; but when I try to run the program I get the same response from the GUI, name error: name ' ' not defined. The exact procedure I use is: I bring up the GUI; click on file; click open; click the program I want to run. Then when that window opens I click Edit; then Run Script. When that opens I type ; filename ( ) to run the program and all I get is " filename not defined" which I'm assuming means I have to rewrite the entire program each time I want to use it.''' [helper] '''IDLE has an interpreted mode (indicated by the >>> prompt) -- that is not the place to write and save your program. Select File New to create a new blank page for your program. Type in the program (only once!) and select File SaveAs myprog.py. Next, press F5 which will run your program. ''' [beginner] ''' So, your saying WRITE the program on the blank screen , the one without the prompts, etc ? Then save it to file "save as" ? I never knew that was the way it's to be done. I've written every program I've done on the idle screen. I really appreciate your help ''' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 02:21 Message: Logged In: YES user_id=80475 The attached 5 line patch disables the shell window's menu and key bindings for script actions. It leaves them intact for other windows. This addresses a common beginner problem (there have been multiple requests on the python-help maillist) without otherwise impacting functionality. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 From noreply@sourceforge.net Tue May 21 08:27:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 00:27:15 -0700 Subject: [Patches] [ python-Patches-543222 ] IDLE Shell window RunScript warning Message-ID: Patches item #543222, was opened at 2002-04-12 16:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 >Category: IDLE >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Guido van Rossum (gvanrossum) Summary: IDLE Shell window RunScript warning Initial Comment: Alter IDLE's ScriptBinding.py to provide a warning if called from the shell window instead of a program window. Also, consider providing a warning for File Save or SaveAs from the shell window. The purpose of the warnings is handle a newbie problem of typing a program in the interpreter, trying to save it from there with File SaveAs mymprog.py, and trying to run it with F5 from the shell window. Here is an except of a dialogue on help@python.org: [beginner] '''I have several programs I've written and saved. I have saved them as ' save ' , ' save as ' , ' save copy '; but when I try to run the program I get the same response from the GUI, name error: name ' ' not defined. The exact procedure I use is: I bring up the GUI; click on file; click open; click the program I want to run. Then when that window opens I click Edit; then Run Script. When that opens I type ; filename ( ) to run the program and all I get is " filename not defined" which I'm assuming means I have to rewrite the entire program each time I want to use it.''' [helper] '''IDLE has an interpreted mode (indicated by the >>> prompt) -- that is not the place to write and save your program. Select File New to create a new blank page for your program. Type in the program (only once!) and select File SaveAs myprog.py. Next, press F5 which will run your program. ''' [beginner] ''' So, your saying WRITE the program on the blank screen , the one without the prompts, etc ? Then save it to file "save as" ? I never knew that was the way it's to be done. I've written every program I've done on the idle screen. I really appreciate your help ''' ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 02:21 Message: Logged In: YES user_id=80475 The attached 5 line patch disables the shell window's menu and key bindings for script actions. It leaves them intact for other windows. This addresses a common beginner problem (there have been multiple requests on the python-help maillist) without otherwise impacting functionality. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 From noreply@sourceforge.net Tue May 21 10:25:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 02:25:40 -0700 Subject: [Patches] [ python-Patches-554718 ] OpenBSD updates for build process Message-ID: Patches item #554718, was opened at 2002-05-11 02:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 Category: Build Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD updates for build process Initial Comment: The following patches are currently in our packaging system. A brief summary: - Use 'cc -shared' to build shared libraries, as is strictly correct on OpenBSD. - Use -fPIC instead of -fpic. - Use OpenBSD threads. - Fix the test_fcntl test. Another patch item will be posted shortly for Python 2.2, for similar items. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-21 11:25 Message: Logged In: YES user_id=21627 What architectures have been using ELF before OpenBSD 2.8? I'd still like to simplify this logic, perhaps by removing support for systems that nobody uses anymore. As for -pthread: the test for OpenBSD specifically should go. Instead, I propose to integrate this with the -Kpthread logic: there should be a sequence of options tested, and the first one shown to enable pthreads should be used. The set of options should be -Kpthread (for SysV), -pthread (for BSD and Linux), -pthreads (for gcc on Solaris). I'd be willing to accept a test-for-system for 2.1, since it does not have the -Kpthread test, but for 2.2 and 2.3, we should remove the set of tests used. Also, why does it AC_DEFINE _REENTRANT and _POSIX_THREADS? Those two should be implied by -pthread. Also, what OpenBSD releases could be deprecated without losing users? ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2002-05-21 00:47 Message: Logged In: YES user_id=240525 >From brad@: > There isn't a test for -pthread option so Python will not correctly > compile with threads support. Testing for libc_r is NOT correct. So, the answer is no, the standard POSIX threads test does not work. ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2002-05-20 14:17 Message: Logged In: YES user_id=240525 Okay, well let's comment in this bug then. Changing the subject and closing out 554719. I'll put all patches on this bug. I am trying to verify most of this with brad@openbsd.org, who has contributed some parts of these patches. On cc -shared, this is my understanding: - All OpenBSD ELF architectures have always used cc -shared. - Before OpenBSD 2.8, a.out architectures used ld -Bshareable. - As of OpenBSD 2.8, cc -shared worked on a.out architectures as well, and ld -Bshareable became deprecated. On -fPIC: -fPIC has always worked. The difference between -fpic and -fPIC is simply that -fpic is less efficient. On threads, I am still waiting for an answer from brad@, this is his change. I'll ask him again today. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-12 18:49 Message: Logged In: YES user_id=21627 The -shared chunk looks frightening. What is the first BSD release where ld -Bshareable stops working? Could you rearrange this to integrate the version numbers into the OpenBSD* match? Also, what releases need the ELF test? Could that be restricted to the older releases, too? Would it be acceptable to stop supporting OpenBSD 0 and 1? Is usage of -fPIC correct on OpenBSD 0.x? If not, what is the first release that supports -fPIC? It looks like that 'OpenBSD threads' are 'POSIX threads'? Why does the existing test for Posix threads fail to detect their presence? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 From noreply@sourceforge.net Tue May 21 13:01:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 05:01:13 -0700 Subject: [Patches] [ python-Patches-543222 ] IDLE Shell window RunScript warning Message-ID: Patches item #543222, was opened at 2002-04-12 17:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: IDLE Shell window RunScript warning Initial Comment: Alter IDLE's ScriptBinding.py to provide a warning if called from the shell window instead of a program window. Also, consider providing a warning for File Save or SaveAs from the shell window. The purpose of the warnings is handle a newbie problem of typing a program in the interpreter, trying to save it from there with File SaveAs mymprog.py, and trying to run it with F5 from the shell window. Here is an except of a dialogue on help@python.org: [beginner] '''I have several programs I've written and saved. I have saved them as ' save ' , ' save as ' , ' save copy '; but when I try to run the program I get the same response from the GUI, name error: name ' ' not defined. The exact procedure I use is: I bring up the GUI; click on file; click open; click the program I want to run. Then when that window opens I click Edit; then Run Script. When that opens I type ; filename ( ) to run the program and all I get is " filename not defined" which I'm assuming means I have to rewrite the entire program each time I want to use it.''' [helper] '''IDLE has an interpreted mode (indicated by the >>> prompt) -- that is not the place to write and save your program. Select File New to create a new blank page for your program. Type in the program (only once!) and select File SaveAs myprog.py. Next, press F5 which will run your program. ''' [beginner] ''' So, your saying WRITE the program on the blank screen , the one without the prompts, etc ? Then save it to file "save as" ? I never knew that was the way it's to be done. I've written every program I've done on the idle screen. I really appreciate your help ''' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 08:01 Message: Logged In: YES user_id=6380 Raymond, are you aware of the IDLEFORK project? http://idlefork.sourceforge.net/ It desperately needs developers. Maybe you can help out there? We will gladly add you as a developer. (I say this because the issue here is already addressed there, in a much different way, but that won't help us until the idle fork has been ported back...) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 03:21 Message: Logged In: YES user_id=80475 The attached 5 line patch disables the shell window's menu and key bindings for script actions. It leaves them intact for other windows. This addresses a common beginner problem (there have been multiple requests on the python-help maillist) without otherwise impacting functionality. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 From noreply@sourceforge.net Tue May 21 13:06:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 05:06:10 -0700 Subject: [Patches] [ python-Patches-558535 ] IDLE windows key binding for Select All Message-ID: Patches item #558535, was opened at 2002-05-21 00:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558535&group_id=5470 Category: IDLE Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: IDLE windows key binding for Select All Initial Comment: The standard Windows binding for Edit Select All should be Control-A instead of Alt-A. 1 line patch attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 08:06 Message: Logged In: YES user_id=6380 Please apply! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558535&group_id=5470 From noreply@sourceforge.net Tue May 21 13:30:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 05:30:47 -0700 Subject: [Patches] [ python-Patches-558535 ] IDLE windows key binding for Select All Message-ID: Patches item #558535, was opened at 2002-05-20 23:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558535&group_id=5470 Category: IDLE Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: IDLE windows key binding for Select All Initial Comment: The standard Windows binding for Edit Select All should be Control-A instead of Alt-A. 1 line patch attached. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 07:30 Message: Logged In: YES user_id=80475 Committed as keydefs.py 1.4 Closing patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 07:06 Message: Logged In: YES user_id=6380 Please apply! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558535&group_id=5470 From noreply@sourceforge.net Tue May 21 13:48:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 05:48:41 -0700 Subject: [Patches] [ python-Patches-543222 ] IDLE Shell window RunScript warning Message-ID: Patches item #543222, was opened at 2002-04-12 16:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: IDLE Shell window RunScript warning Initial Comment: Alter IDLE's ScriptBinding.py to provide a warning if called from the shell window instead of a program window. Also, consider providing a warning for File Save or SaveAs from the shell window. The purpose of the warnings is handle a newbie problem of typing a program in the interpreter, trying to save it from there with File SaveAs mymprog.py, and trying to run it with F5 from the shell window. Here is an except of a dialogue on help@python.org: [beginner] '''I have several programs I've written and saved. I have saved them as ' save ' , ' save as ' , ' save copy '; but when I try to run the program I get the same response from the GUI, name error: name ' ' not defined. The exact procedure I use is: I bring up the GUI; click on file; click open; click the program I want to run. Then when that window opens I click Edit; then Run Script. When that opens I type ; filename ( ) to run the program and all I get is " filename not defined" which I'm assuming means I have to rewrite the entire program each time I want to use it.''' [helper] '''IDLE has an interpreted mode (indicated by the >>> prompt) -- that is not the place to write and save your program. Select File New to create a new blank page for your program. Type in the program (only once!) and select File SaveAs myprog.py. Next, press F5 which will run your program. ''' [beginner] ''' So, your saying WRITE the program on the blank screen , the one without the prompts, etc ? Then save it to file "save as" ? I never knew that was the way it's to be done. I've written every program I've done on the idle screen. I really appreciate your help ''' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 07:48 Message: Logged In: YES user_id=80475 Yes, I follow the Idle-dev maillist but prefer to work on other Python projects for now (focusing on the Docs, clearing bugs, feeding slices to getitem, itertools, an observer pattern prototype, and generator attributes). Wanted this patch as a minimally invasive usabilty fix until the IDLEFORK guys have done the deeper magic. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 07:01 Message: Logged In: YES user_id=6380 Raymond, are you aware of the IDLEFORK project? http://idlefork.sourceforge.net/ It desperately needs developers. Maybe you can help out there? We will gladly add you as a developer. (I say this because the issue here is already addressed there, in a much different way, but that won't help us until the idle fork has been ported back...) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 02:21 Message: Logged In: YES user_id=80475 The attached 5 line patch disables the shell window's menu and key bindings for script actions. It leaves them intact for other windows. This addresses a common beginner problem (there have been multiple requests on the python-help maillist) without otherwise impacting functionality. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 From noreply@sourceforge.net Tue May 21 14:06:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 06:06:03 -0700 Subject: [Patches] [ python-Patches-557719 ] OSX build -- make python.app Message-ID: Patches item #557719, was opened at 2002-05-18 20:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557719&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) >Assigned to: Jack Jansen (jackjansen) Summary: OSX build -- make python.app Initial Comment: Some small improvements to OSX build: 1. When building from separate directory than the build directory, automatic --with-suffix code was not working. 2. Tk for Mac OS X is detected and built automatically. 3. WASTE is found more automatically. 4. Building of Python.app can be invoked from the main makefile. (via make python.app) 5. A .pth file is installed in the Python.framework so that Mac modules are found by default. Also, a change to the Python IDE: when it looks for and creates an "IDE Scripts" folder under OSX, it was breaking. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-05-21 15:06 Message: Logged In: YES user_id=45365 Grabbed responsibility for this patch. Tony, the one thing I don't like is the search for WASTE by going up the file tree. What is your reason for wanting this? (so, consider this also a note that I *do* like all the rest of your patch;-) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2002-05-18 20:47 Message: Logged In: YES user_id=24100 The new file python/dist/src/Mac/OSX/Mac.pth wasn't included in diff so I am attaching it now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557719&group_id=5470 From noreply@sourceforge.net Tue May 21 16:17:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 08:17:42 -0700 Subject: [Patches] [ python-Patches-549187 ] error about string formatting rewording? Message-ID: Patches item #549187, was opened at 2002-04-26 12:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Danny Yoo (dyoo) >Assigned to: Raymond Hettinger (rhettinger) Summary: error about string formatting rewording? Initial Comment: The error message that occurs during string formatting, when one passes more arguments than necessary, is this: TypeError: not all arguments converted It might be good to mention that this conversion is taking place as a result of string formatting. My suggestions is to add a little more to this message: TypeError: not all arguments converted during string formatting The reason is because string formatting uses the same operation as the modulus command, and also can take in a single integer argument, like: ziffer = note % 10 Newcomers to the language often mix up string and numbers, and the error message above can be very cryptic if one doesn't know about string formatting yet. With the reworded error message, there's less of chance of confusion. See: http://mail.python.org/pipermail/tutor/2002-April/014110.html for more details on why this might be nice. Thanks! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 10:17 Message: Logged In: YES user_id=80475 Committed as stringobject.c 2.163 and unicodeobject.c 2.148. Only put in Py2.3, left-out of release22-maint. Closing patch. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-13 00:13 Message: Logged In: YES user_id=29957 This seems fine to me, and is suitable for the 22 branch. The 21 branch is mostly only getting genuine bugs, rather than cosmetic fixes. I can't imagine anything would depend on the wording of the error messages... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-13 00:05 Message: Logged In: YES user_id=80475 Martin, is this okay to commit to MAIN and to backport to release22-maint? Review: ----------------------- This makes sense to me. The code runs fine. I grepped the objects directory and found that all instances of the message had been accounted for. Read the original email from an instructor and believe that the current error message was confusing to students. ---------------------------------------------------------------------- Comment By: Danny Yoo (dyoo) Date: 2002-04-27 22:39 Message: Logged In: YES user_id=49843 Ok, I wrote up a patch to add more to the error message. Here's what it does: >>> def isEven(n): return n % 2 == 0 ... >>> isEven(17) False >>> isEven("17") Traceback (most recent call last): File "", line 1, in ? File "", line 1, in isEven TypeError: not all arguments converted during string formatting ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=549187&group_id=5470 From noreply@sourceforge.net Tue May 21 16:56:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 08:56:01 -0700 Subject: [Patches] [ python-Patches-543222 ] IDLE Shell window RunScript warning Message-ID: Patches item #543222, was opened at 2002-04-12 17:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: IDLE Shell window RunScript warning Initial Comment: Alter IDLE's ScriptBinding.py to provide a warning if called from the shell window instead of a program window. Also, consider providing a warning for File Save or SaveAs from the shell window. The purpose of the warnings is handle a newbie problem of typing a program in the interpreter, trying to save it from there with File SaveAs mymprog.py, and trying to run it with F5 from the shell window. Here is an except of a dialogue on help@python.org: [beginner] '''I have several programs I've written and saved. I have saved them as ' save ' , ' save as ' , ' save copy '; but when I try to run the program I get the same response from the GUI, name error: name ' ' not defined. The exact procedure I use is: I bring up the GUI; click on file; click open; click the program I want to run. Then when that window opens I click Edit; then Run Script. When that opens I type ; filename ( ) to run the program and all I get is " filename not defined" which I'm assuming means I have to rewrite the entire program each time I want to use it.''' [helper] '''IDLE has an interpreted mode (indicated by the >>> prompt) -- that is not the place to write and save your program. Select File New to create a new blank page for your program. Type in the program (only once!) and select File SaveAs myprog.py. Next, press F5 which will run your program. ''' [beginner] ''' So, your saying WRITE the program on the blank screen , the one without the prompts, etc ? Then save it to file "save as" ? I never knew that was the way it's to be done. I've written every program I've done on the idle screen. I really appreciate your help ''' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 11:56 Message: Logged In: YES user_id=6380 OK, I see. This is a reasonable compromise. Go ahead and check it in. (I still think that IDLEFORK can really use your help more than Python -- Python has tons of developers, IDLEFORK has one left!!!) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 08:48 Message: Logged In: YES user_id=80475 Yes, I follow the Idle-dev maillist but prefer to work on other Python projects for now (focusing on the Docs, clearing bugs, feeding slices to getitem, itertools, an observer pattern prototype, and generator attributes). Wanted this patch as a minimally invasive usabilty fix until the IDLEFORK guys have done the deeper magic. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 08:01 Message: Logged In: YES user_id=6380 Raymond, are you aware of the IDLEFORK project? http://idlefork.sourceforge.net/ It desperately needs developers. Maybe you can help out there? We will gladly add you as a developer. (I say this because the issue here is already addressed there, in a much different way, but that won't help us until the idle fork has been ported back...) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 03:21 Message: Logged In: YES user_id=80475 The attached 5 line patch disables the shell window's menu and key bindings for script actions. It leaves them intact for other windows. This addresses a common beginner problem (there have been multiple requests on the python-help maillist) without otherwise impacting functionality. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 From noreply@sourceforge.net Tue May 21 17:10:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 09:10:47 -0700 Subject: [Patches] [ python-Patches-558745 ] GC: untrack simple objects Message-ID: Patches item #558745, was opened at 2002-05-21 16:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: GC: untrack simple objects Initial Comment: This patch makes the GC untrack tuples that contain no GC objects. Unfortunately it doesn't seem to help much. The time for the 'storetups' case of iterzip.py seems be about twice as fast (matching Daniel Dunbar result). Loading a number of complex MEMS Exchange web pages causes the size of gen2 to go up to 120000 instead of 134000 without the patch. This change doesn't seem to be worth making. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 From noreply@sourceforge.net Tue May 21 18:02:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 10:02:47 -0700 Subject: [Patches] [ python-Patches-543222 ] IDLE Shell window RunScript warning Message-ID: Patches item #543222, was opened at 2002-04-12 16:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: IDLE Shell window RunScript warning Initial Comment: Alter IDLE's ScriptBinding.py to provide a warning if called from the shell window instead of a program window. Also, consider providing a warning for File Save or SaveAs from the shell window. The purpose of the warnings is handle a newbie problem of typing a program in the interpreter, trying to save it from there with File SaveAs mymprog.py, and trying to run it with F5 from the shell window. Here is an except of a dialogue on help@python.org: [beginner] '''I have several programs I've written and saved. I have saved them as ' save ' , ' save as ' , ' save copy '; but when I try to run the program I get the same response from the GUI, name error: name ' ' not defined. The exact procedure I use is: I bring up the GUI; click on file; click open; click the program I want to run. Then when that window opens I click Edit; then Run Script. When that opens I type ; filename ( ) to run the program and all I get is " filename not defined" which I'm assuming means I have to rewrite the entire program each time I want to use it.''' [helper] '''IDLE has an interpreted mode (indicated by the >>> prompt) -- that is not the place to write and save your program. Select File New to create a new blank page for your program. Type in the program (only once!) and select File SaveAs myprog.py. Next, press F5 which will run your program. ''' [beginner] ''' So, your saying WRITE the program on the blank screen , the one without the prompts, etc ? Then save it to file "save as" ? I never knew that was the way it's to be done. I've written every program I've done on the idle screen. I really appreciate your help ''' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 12:02 Message: Logged In: YES user_id=80475 Committed as: EditorWindow.py 1.42 PyShell.py 1.37 ScriptBinding.py 1.12 Closing patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 10:56 Message: Logged In: YES user_id=6380 OK, I see. This is a reasonable compromise. Go ahead and check it in. (I still think that IDLEFORK can really use your help more than Python -- Python has tons of developers, IDLEFORK has one left!!!) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 07:48 Message: Logged In: YES user_id=80475 Yes, I follow the Idle-dev maillist but prefer to work on other Python projects for now (focusing on the Docs, clearing bugs, feeding slices to getitem, itertools, an observer pattern prototype, and generator attributes). Wanted this patch as a minimally invasive usabilty fix until the IDLEFORK guys have done the deeper magic. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 07:01 Message: Logged In: YES user_id=6380 Raymond, are you aware of the IDLEFORK project? http://idlefork.sourceforge.net/ It desperately needs developers. Maybe you can help out there? We will gladly add you as a developer. (I say this because the issue here is already addressed there, in a much different way, but that won't help us until the idle fork has been ported back...) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-21 02:21 Message: Logged In: YES user_id=80475 The attached 5 line patch disables the shell window's menu and key bindings for script actions. It leaves them intact for other windows. This addresses a common beginner problem (there have been multiple requests on the python-help maillist) without otherwise impacting functionality. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=543222&group_id=5470 From noreply@sourceforge.net Tue May 21 20:13:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 12:13:25 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 13:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 15:13 Message: Logged In: YES user_id=6380 I think there are actually two issues here: pydoc shows the docstrings for what it calls "data and non-method functions", which usually aren't helpful; and the docstrings for basic types are confusing when retrieved through an instance. For the pydoc issue, I have a different patch (pydoc2.diff). This suppresses the docstring completely unless the value is callable. (Now, I know that callable() is not 100% reliable, but it's close enough for pydoc.) For the other issue, I'm not sure *what* to do. Tim suggests that perhaps for the basic types, x.__doc__ should return None. Opinions? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-16 08:36 Message: Logged In: YES user_id=6380 I'm very sympathetic, but have no time to review this just yet. Please don't check in without my approval -- this is awfully deep shit (see the history of the __doc__ descriptor in typeobject.c). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-15 11:13 Message: Logged In: YES user_id=80475 Since this would also go into int, float, and other places, consider factoring it to abstract.c as PyObject_GenericGetNoneDoc or some such. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-15 08:51 Message: Logged In: YES user_id=11105 The attatched patch (stringobject.diff) implements this behaviour: The doc string of 'str' is unchanged, but string objects have a __doc__ attribute of None. The same could (and should) be done for int, float, and probably more types as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 13:08 Message: Logged In: YES user_id=11105 Or maybe add a __doc__ tp_member (or whatever) which always returns None? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 13:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 04:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Tue May 21 20:24:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 12:24:33 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 19:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-21 21:24 Message: Logged In: YES user_id=11105 > I think there are actually two issues here: pydoc shows the > docstrings for what it calls "data and non-method > functions", which usually aren't helpful; and the docstrings > for basic types are confusing when retrieved through an > instance. > > For the pydoc issue, I have a different patch > (pydoc2.diff). This suppresses the docstring completely > unless the value is callable. (Now, I know that callable() > is not 100% reliable, but it's close enough for pydoc.) Hm, I see no pydoc2.diff ;-) IMO, pydoc should try to document the _purpose_ of the special attributes (__doc__, __module__, ...) instead of their _value_. > For the other issue, I'm not sure *what* to do. Tim suggests > that perhaps for the basic types, x.__doc__ should return > None. Opinions? That's what my sample patch stringobject.diff does. +1 from me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 21:13 Message: Logged In: YES user_id=6380 I think there are actually two issues here: pydoc shows the docstrings for what it calls "data and non-method functions", which usually aren't helpful; and the docstrings for basic types are confusing when retrieved through an instance. For the pydoc issue, I have a different patch (pydoc2.diff). This suppresses the docstring completely unless the value is callable. (Now, I know that callable() is not 100% reliable, but it's close enough for pydoc.) For the other issue, I'm not sure *what* to do. Tim suggests that perhaps for the basic types, x.__doc__ should return None. Opinions? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-16 14:36 Message: Logged In: YES user_id=6380 I'm very sympathetic, but have no time to review this just yet. Please don't check in without my approval -- this is awfully deep shit (see the history of the __doc__ descriptor in typeobject.c). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-15 17:13 Message: Logged In: YES user_id=80475 Since this would also go into int, float, and other places, consider factoring it to abstract.c as PyObject_GenericGetNoneDoc or some such. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-15 14:51 Message: Logged In: YES user_id=11105 The attatched patch (stringobject.diff) implements this behaviour: The doc string of 'str' is unchanged, but string objects have a __doc__ attribute of None. The same could (and should) be done for int, float, and probably more types as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 19:08 Message: Logged In: YES user_id=11105 Or maybe add a __doc__ tp_member (or whatever) which always returns None? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 19:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 14:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Tue May 21 20:39:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 12:39:55 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 13:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 15:39 Message: Logged In: YES user_id=6380 > Hm, I see no pydoc2.diff ;-) Oops, here's pydoc2.diff > IMO, pydoc should try to document the _purpose_ of the > special attributes (__doc__, __module__, ...) instead > of their _value_. Maybe, but aren't there lots of these? Maybe this ought to be table-driven instead of an if-statement for each one. I'll call YAGNI on this one for now; at best it's a separate feature request. > > For the other issue, I'm not sure *what* to do. Tim suggests > > that perhaps for the basic types, x.__doc__ should return > > None. Opinions? > That's what my sample patch stringobject.diff does. > +1 from me. That's what I realized after looking at your string patch. :-) Raymond, do you want to work on finishing this? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-21 15:24 Message: Logged In: YES user_id=11105 > I think there are actually two issues here: pydoc shows the > docstrings for what it calls "data and non-method > functions", which usually aren't helpful; and the docstrings > for basic types are confusing when retrieved through an > instance. > > For the pydoc issue, I have a different patch > (pydoc2.diff). This suppresses the docstring completely > unless the value is callable. (Now, I know that callable() > is not 100% reliable, but it's close enough for pydoc.) Hm, I see no pydoc2.diff ;-) IMO, pydoc should try to document the _purpose_ of the special attributes (__doc__, __module__, ...) instead of their _value_. > For the other issue, I'm not sure *what* to do. Tim suggests > that perhaps for the basic types, x.__doc__ should return > None. Opinions? That's what my sample patch stringobject.diff does. +1 from me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 15:13 Message: Logged In: YES user_id=6380 I think there are actually two issues here: pydoc shows the docstrings for what it calls "data and non-method functions", which usually aren't helpful; and the docstrings for basic types are confusing when retrieved through an instance. For the pydoc issue, I have a different patch (pydoc2.diff). This suppresses the docstring completely unless the value is callable. (Now, I know that callable() is not 100% reliable, but it's close enough for pydoc.) For the other issue, I'm not sure *what* to do. Tim suggests that perhaps for the basic types, x.__doc__ should return None. Opinions? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-16 08:36 Message: Logged In: YES user_id=6380 I'm very sympathetic, but have no time to review this just yet. Please don't check in without my approval -- this is awfully deep shit (see the history of the __doc__ descriptor in typeobject.c). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-15 11:13 Message: Logged In: YES user_id=80475 Since this would also go into int, float, and other places, consider factoring it to abstract.c as PyObject_GenericGetNoneDoc or some such. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-15 08:51 Message: Logged In: YES user_id=11105 The attatched patch (stringobject.diff) implements this behaviour: The doc string of 'str' is unchanged, but string objects have a __doc__ attribute of None. The same could (and should) be done for int, float, and probably more types as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 13:08 Message: Logged In: YES user_id=11105 Or maybe add a __doc__ tp_member (or whatever) which always returns None? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 13:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 04:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Tue May 21 20:54:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 12:54:17 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 19:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-21 21:54 Message: Logged In: YES user_id=11105 Guido, after applying pydoc2.diff I'm happy. I retract the "feature request". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 21:39 Message: Logged In: YES user_id=6380 > Hm, I see no pydoc2.diff ;-) Oops, here's pydoc2.diff > IMO, pydoc should try to document the _purpose_ of the > special attributes (__doc__, __module__, ...) instead > of their _value_. Maybe, but aren't there lots of these? Maybe this ought to be table-driven instead of an if-statement for each one. I'll call YAGNI on this one for now; at best it's a separate feature request. > > For the other issue, I'm not sure *what* to do. Tim suggests > > that perhaps for the basic types, x.__doc__ should return > > None. Opinions? > That's what my sample patch stringobject.diff does. > +1 from me. That's what I realized after looking at your string patch. :-) Raymond, do you want to work on finishing this? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-21 21:24 Message: Logged In: YES user_id=11105 > I think there are actually two issues here: pydoc shows the > docstrings for what it calls "data and non-method > functions", which usually aren't helpful; and the docstrings > for basic types are confusing when retrieved through an > instance. > > For the pydoc issue, I have a different patch > (pydoc2.diff). This suppresses the docstring completely > unless the value is callable. (Now, I know that callable() > is not 100% reliable, but it's close enough for pydoc.) Hm, I see no pydoc2.diff ;-) IMO, pydoc should try to document the _purpose_ of the special attributes (__doc__, __module__, ...) instead of their _value_. > For the other issue, I'm not sure *what* to do. Tim suggests > that perhaps for the basic types, x.__doc__ should return > None. Opinions? That's what my sample patch stringobject.diff does. +1 from me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 21:13 Message: Logged In: YES user_id=6380 I think there are actually two issues here: pydoc shows the docstrings for what it calls "data and non-method functions", which usually aren't helpful; and the docstrings for basic types are confusing when retrieved through an instance. For the pydoc issue, I have a different patch (pydoc2.diff). This suppresses the docstring completely unless the value is callable. (Now, I know that callable() is not 100% reliable, but it's close enough for pydoc.) For the other issue, I'm not sure *what* to do. Tim suggests that perhaps for the basic types, x.__doc__ should return None. Opinions? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-16 14:36 Message: Logged In: YES user_id=6380 I'm very sympathetic, but have no time to review this just yet. Please don't check in without my approval -- this is awfully deep shit (see the history of the __doc__ descriptor in typeobject.c). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-15 17:13 Message: Logged In: YES user_id=80475 Since this would also go into int, float, and other places, consider factoring it to abstract.c as PyObject_GenericGetNoneDoc or some such. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-15 14:51 Message: Logged In: YES user_id=11105 The attatched patch (stringobject.diff) implements this behaviour: The doc string of 'str' is unchanged, but string objects have a __doc__ attribute of None. The same could (and should) be done for int, float, and probably more types as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 19:08 Message: Logged In: YES user_id=11105 Or maybe add a __doc__ tp_member (or whatever) which always returns None? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 19:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 14:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 16:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Tue May 21 21:58:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 13:58:22 -0700 Subject: [Patches] [ python-Patches-550290 ] __doc__ strings of builtin types Message-ID: Patches item #550290, was opened at 2002-04-29 13:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Guido van Rossum (gvanrossum) Summary: __doc__ strings of builtin types Initial Comment: pydoc creates a strange description for the __doc__ member: it prints the doc-string of 'str'. Example: C:\>c:\sf\python\dist\src\PCBuild\python.exe Python 2.3a0 (#29, Apr 15 2002, 18:33:31) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class O(object): ... "some text" ... >>> import pydoc >>> pydoc.help(O) Help on class O in module __main__: class O(__builtin__.object) | some text | | Data and non-method functions defined here: | | __dict__ = | | __doc__ = 'some text' | str(object) -> string | | Return a nice string representation of the object. | If the argument is a string, the return value is the same object. | The attached patch prints the following (also for the HTML output): | __doc__ = 'some text' | The documentation string | ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 16:58 Message: Logged In: YES user_id=6380 OK, I've checked in pydoc2.diff. I'm not sure if we need to do anything about the docstrings of basic objects; I'll close this bug report, if there's a desire for a change there, somebody can open a new bug report. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-21 15:54 Message: Logged In: YES user_id=11105 Guido, after applying pydoc2.diff I'm happy. I retract the "feature request". ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 15:39 Message: Logged In: YES user_id=6380 > Hm, I see no pydoc2.diff ;-) Oops, here's pydoc2.diff > IMO, pydoc should try to document the _purpose_ of the > special attributes (__doc__, __module__, ...) instead > of their _value_. Maybe, but aren't there lots of these? Maybe this ought to be table-driven instead of an if-statement for each one. I'll call YAGNI on this one for now; at best it's a separate feature request. > > For the other issue, I'm not sure *what* to do. Tim suggests > > that perhaps for the basic types, x.__doc__ should return > > None. Opinions? > That's what my sample patch stringobject.diff does. > +1 from me. That's what I realized after looking at your string patch. :-) Raymond, do you want to work on finishing this? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-21 15:24 Message: Logged In: YES user_id=11105 > I think there are actually two issues here: pydoc shows the > docstrings for what it calls "data and non-method > functions", which usually aren't helpful; and the docstrings > for basic types are confusing when retrieved through an > instance. > > For the pydoc issue, I have a different patch > (pydoc2.diff). This suppresses the docstring completely > unless the value is callable. (Now, I know that callable() > is not 100% reliable, but it's close enough for pydoc.) Hm, I see no pydoc2.diff ;-) IMO, pydoc should try to document the _purpose_ of the special attributes (__doc__, __module__, ...) instead of their _value_. > For the other issue, I'm not sure *what* to do. Tim suggests > that perhaps for the basic types, x.__doc__ should return > None. Opinions? That's what my sample patch stringobject.diff does. +1 from me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-21 15:13 Message: Logged In: YES user_id=6380 I think there are actually two issues here: pydoc shows the docstrings for what it calls "data and non-method functions", which usually aren't helpful; and the docstrings for basic types are confusing when retrieved through an instance. For the pydoc issue, I have a different patch (pydoc2.diff). This suppresses the docstring completely unless the value is callable. (Now, I know that callable() is not 100% reliable, but it's close enough for pydoc.) For the other issue, I'm not sure *what* to do. Tim suggests that perhaps for the basic types, x.__doc__ should return None. Opinions? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-16 08:36 Message: Logged In: YES user_id=6380 I'm very sympathetic, but have no time to review this just yet. Please don't check in without my approval -- this is awfully deep shit (see the history of the __doc__ descriptor in typeobject.c). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-15 11:13 Message: Logged In: YES user_id=80475 Since this would also go into int, float, and other places, consider factoring it to abstract.c as PyObject_GenericGetNoneDoc or some such. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-15 08:51 Message: Logged In: YES user_id=11105 The attatched patch (stringobject.diff) implements this behaviour: The doc string of 'str' is unchanged, but string objects have a __doc__ attribute of None. The same could (and should) be done for int, float, and probably more types as well. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 13:08 Message: Logged In: YES user_id=11105 Or maybe add a __doc__ tp_member (or whatever) which always returns None? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-07 13:06 Message: Logged In: YES user_id=11105 No, I cannot think of a better wording. The problem (as you know) is that we have to cover three cases: the str() function, the str type, and the string instances (same for all the other 'simple' types). Would it be worth to add a _doc field to the PyStringObject structure and add a __doc__ entry to tp_members? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 08:34 Message: Logged In: YES user_id=6380 The instance doc is supposed to be the same as the class doc, yes. I suppose the str() __doc__ is not particularly appropriate for string instances. Can you suggest a better wording? (This problem is widespread, I presume, so a generic solution may be in order.) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:50 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 10:49 Message: Logged In: YES user_id=11105 Please ignore my previous comments. It turns out that the problem is not in pydoc, it is in Python itself. "spam".__doc__ is the same as str.__doc__ (which describes what the callable 'str' does. Is this intended? The side-effect is that pydoc prints unexpected output for class variables. Execute this code to find out: class X: a = "a string" b = 42 import pydoc pydoc.help(X) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-30 04:24 Message: Logged In: YES user_id=11105 The same problem exists for the __module__ attribute. I can update the patch if needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=550290&group_id=5470 From noreply@sourceforge.net Wed May 22 02:33:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 21 May 2002 18:33:41 -0700 Subject: [Patches] [ python-Patches-536278 ] force gzip to open files with 'b' Message-ID: Patches item #536278, was opened at 2002-03-28 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=536278&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Neal Norwitz (nnorwitz) Summary: force gzip to open files with 'b' Initial Comment: It doesn't make sense that the gzip module should try to open a file in text mode. The attached patch forces a 'b' into the file open mode if it wasn't given. I also modified the test slightly to try and tickle this code, but I can't test it very effectively, because I don't do Windows... :-) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-05-21 20:33 Message: Logged In: YES user_id=44345 assigning to Neal for a final opinion. New patch includes test_gzip.py modification. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-04-09 11:30 Message: Logged In: YES user_id=44345 good point. updated patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-30 22:12 Message: Logged In: YES user_id=31435 I suggest fixing this via changing the test to if mode and 'b' not in mode: Then mode=None and mode='' will be left alone (as Neal says, the code already does the right thing for those). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-03-28 09:04 Message: Logged In: YES user_id=33168 There is a problem (sorry, I have an evil mind). :-) If '' is passed as the mode, before the patch, this would have been converted to 'rb'. After the patch, mode will become 'b' and that will raise an exception: >>> open('/dev/null', 'b') IOError: [Errno 22] Invalid argument: b If you add an (and mode) condition and that should be fine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=536278&group_id=5470 From noreply@sourceforge.net Wed May 22 16:56:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 08:56:26 -0700 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 11:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-22 15:56 Message: Logged In: YES user_id=6656 Jason, this is now your problem... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-02 14:31 Message: Logged In: YES user_id=6380 Giving Jason checkin permission is probably the best solution here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 14:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 19:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 15:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 14:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 15:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 15:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 15:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Wed May 22 16:59:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 08:59:54 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Wed May 22 17:23:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 09:23:12 -0700 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 02:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: Rejected Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:23 Message: Logged In: YES user_id=86216 Can I check this in? Please see my comments from 2002-04-30 11:53 for my reasoning. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 07:56 Message: Logged In: YES user_id=6656 Jason, this is now your problem... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-02 06:31 Message: Logged In: YES user_id=6380 Giving Jason checkin permission is probably the best solution here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 06:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 11:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 06:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 05:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 06:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Wed May 22 17:26:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 09:26:13 -0700 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 11:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-22 16:26 Message: Logged In: YES user_id=6656 Uh, yeah. It's not going to affect any platform other than cygwin is it? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 16:23 Message: Logged In: YES user_id=86216 Can I check this in? Please see my comments from 2002-04-30 11:53 for my reasoning. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 15:56 Message: Logged In: YES user_id=6656 Jason, this is now your problem... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-02 14:31 Message: Logged In: YES user_id=6380 Giving Jason checkin permission is probably the best solution here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 14:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 19:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 15:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 14:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 15:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 15:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 15:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Wed May 22 17:27:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 09:27:15 -0700 Subject: [Patches] [ python-Patches-555929 ] Cygwin AH_BOTTOM cleanup patch Message-ID: Patches item #555929, was opened at 2002-05-14 05:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin AH_BOTTOM cleanup patch Initial Comment: This patch complies with the following request found near the top of configure.in: # This is for stuff that absolutely must end up in pyconfig.h. # Please use pyport.h instead, if possible. I tested this patch under Cygwin, Win32, and Red Hat Linux. Python built and ran successfully on each of these platforms. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:27 Message: Logged In: YES user_id=86216 Any status Martin? Or, is it one strike and you're out? :,) Did you get a chance to try the latest patch under your Linux environment? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-16 04:26 Message: Logged In: YES user_id=86216 > Can you please explain why moving pyport.h is necessary? It's not. It seemed cleaner, albeit riskier. Attached is the second version of my patch. It's identical to the first version except for the Include/Python.h hunk. The changes to Include/Python.h leave the #include "pyport.h" in its original location. Instead, I moved the DL_IMPORT stuff to after the #include "pyport.h". I tested under Cygwin, Win32, and Linux (i.e., gcc 2.96) again without any problems. Please test under your Linux environment. If successful, should we have others test on other platforms to prevent a repeat of this "fiasco?" ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 02:28 Message: Logged In: YES user_id=21627 Can you please explain why moving pyport.h is necessary? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 11:24 Message: Logged In: YES user_id=86216 > How did you test this patch? I tested under Red Linux 7.1 configured with "--enable-shared". Note that my version of gcc is different than yours: $ gcc --version 2.96 > which come from pyport.h being included before limits.h. I was concerned about moving where pyport.h is included. I should have made this concern explicit. > Backing the patch out; No problem -- sorry for the trouble. > try again. Should I leave the #include "pyport.h" in its original location and move the DL_IMPORT stuff after it? Or, should I just try moving #include "pyport.h" to right after the #include ? Since I can't reproduce the problem, I'm afraid that my next attempt may cause problems too. Would you be willing to retry my first patch and just move the #include "pyport.h" below the #include ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 10:25 Message: Logged In: YES user_id=21627 How did you test this patch? When I build Python on Linux, I get tons of error messages In file included from /usr/include/limits.h:152, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:117, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-suse-linux/2.95.3/include/limits.h:11, from Include/Python.h:28, from Python/frozenmain.c:4: /usr/include/bits/xopen_lim.h:123: warning: `LONG_BIT' redefined which come from pyport.h being included before limits.h. Backing the patch out; try again. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-15 03:55 Message: Logged In: YES user_id=86216 Committed as: configure 1.306 configure.in 1.316 pyconfig.h.in 1.34 Include/Python.h 2.47 Include/pyport.h 2.48 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-14 14:03 Message: Logged In: YES user_id=21627 Sounds good; please install this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555929&group_id=5470 From noreply@sourceforge.net Wed May 22 17:30:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 09:30:15 -0700 Subject: [Patches] [ python-Patches-553702 ] Cygwin make install patch Message-ID: Patches item #553702, was opened at 2002-05-08 04:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553702&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin make install patch Initial Comment: This patch fixes make install for Cygwin. Specifically, it reverts to the previous behavior: o install libpython$(VERSION)$(SO) in $(BINDIR) o install $(LDLIBRARY) in $(LIBPL) It also begins to remove Cygwin's dependency on $(DLLLIBRARY) which I hope to take advantage of when I attempt to make Cygwin as similar as possible to the other Unix platforms (in other patches). I tested this patch under Red Hat Linux 7.1 without any ill effects. BTW, I'm not the happiest using the following test for Cygwin: test "$(SO)" = .dll I'm willing to update the patch to use: case "$(MACHDEP)" in cygwin* instead, but IMO that will look uglier. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:30 Message: Logged In: YES user_id=86216 Can I commit this one? Note that make install is busted under Cygwin without this patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=553702&group_id=5470 From noreply@sourceforge.net Wed May 22 17:34:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 09:34:45 -0700 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 02:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:34 Message: Logged In: YES user_id=86216 This patch will not affect any platform except for Cygwin. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 08:26 Message: Logged In: YES user_id=6656 Uh, yeah. It's not going to affect any platform other than cygwin is it? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:23 Message: Logged In: YES user_id=86216 Can I check this in? Please see my comments from 2002-04-30 11:53 for my reasoning. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 07:56 Message: Logged In: YES user_id=6656 Jason, this is now your problem... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-02 06:31 Message: Logged In: YES user_id=6380 Giving Jason checkin permission is probably the best solution here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 06:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 11:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 06:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 05:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 06:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Wed May 22 17:47:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 09:47:56 -0700 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 02:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:47 Message: Logged In: YES user_id=86216 Committed as setup.py 1.87. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:34 Message: Logged In: YES user_id=86216 This patch will not affect any platform except for Cygwin. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 08:26 Message: Logged In: YES user_id=6656 Uh, yeah. It's not going to affect any platform other than cygwin is it? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 08:23 Message: Logged In: YES user_id=86216 Can I check this in? Please see my comments from 2002-04-30 11:53 for my reasoning. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 07:56 Message: Logged In: YES user_id=6656 Jason, this is now your problem... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-02 06:31 Message: Logged In: YES user_id=6380 Giving Jason checkin permission is probably the best solution here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 06:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 11:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 06:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 05:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 06:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 06:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Wed May 22 18:07:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 10:07:08 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 19:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Wed May 22 18:09:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 10:09:11 -0700 Subject: [Patches] [ python-Patches-557946 ] Ebcdic compliancy in stringobject source Message-ID: Patches item #557946, was opened at 2002-05-19 16:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jean-Yves MENGANT (jymen) Assigned to: Nobody/Anonymous (nobody) Summary: Ebcdic compliancy in stringobject source Initial Comment: the printable character set test made inside strincgobject.c is not compliant with EBCDIC systems(OS390 or OS400) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 19:09 Message: Logged In: YES user_id=21627 Is it really worth fixing this? Python assumes that the character set of byte strings is an ASCII superset in many places. If there is any change made here, it should be based on C library functions, rather than on static knowledge of the operating system. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 From noreply@sourceforge.net Wed May 22 18:11:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 10:11:39 -0700 Subject: [Patches] [ python-Patches-491107 ] Cygwin setup.py import workaround patch Message-ID: Patches item #491107, was opened at 2001-12-10 03:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 Category: Distutils and setup.py Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: Cygwin setup.py import workaround patch Initial Comment: Sorry for submitting this in the 11th hour, but this patch re-enables clean building under Cygwin. See the following for details: http://cygwin.com/ml/cygwin/2001-12/msg00409.html Unfortunately, this patch is only a build workaround and does *not* solve the root cause which is Cygwin's problem with DLL address clashes during fork(). Hopefully, a yet to be instituted rebase tool will solve this problem for real. See the following for details: http://sources.redhat.com/ml/cygwin/2001-12/msg00446.html ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-22 10:11 Message: Logged In: NO Looks OK to me. (--Guido, not logged in to SF.) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 09:47 Message: Logged In: YES user_id=86216 Committed as setup.py 1.87. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 09:34 Message: Logged In: YES user_id=86216 This patch will not affect any platform except for Cygwin. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 09:26 Message: Logged In: YES user_id=6656 Uh, yeah. It's not going to affect any platform other than cygwin is it? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-05-22 09:23 Message: Logged In: YES user_id=86216 Can I check this in? Please see my comments from 2002-04-30 11:53 for my reasoning. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-22 08:56 Message: Logged In: YES user_id=6656 Jason, this is now your problem... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-02 07:31 Message: Logged In: YES user_id=6380 Giving Jason checkin permission is probably the best solution here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-02 07:04 Message: Logged In: YES user_id=6656 I can't test cygwin any more. Is there anyone who can? I know Tim can, but I'm not sure this is worth his time. If you're just looking for someone to check stuff in, I can do that, or we can add Jason as a developer & then he can do it (gets my vote!). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-04-30 12:53 Message: Logged In: YES user_id=86216 mwh wrote: > Jason, feel free to complain if you think this isn't > the right thing to do. I guess that I would like to complain and reopen this issue. :,) I cannot build a Python 2.2.1 with threads under Cygwin without this patch even though I'm using Michael's static _socket workaround. This is due to the Cygwin fork() problem with DLL base address conflicts that are triggered by importing many modules during the setup.py run. Similar problems can also be caused by regrtest.py. Even after my rebase patch is accepted into Cygwin's setup.exe, I feel that patch will still be necessary. This is because during the build process the shared extension (i.e., DLLs) will not be rebased yet. Hence, the potential for DLL base address conflicts will exist. One way to obviate this patch is to push the rebase functionality into Cygwin's ld. Unfortunately, I don't think this is likely to happen. Another possible way, is to use the yet to be defined and implemented unload module functionality: http://mail.python.org/pipermail/python-dev/2001-December/019028.html I have refreshed the patch against current CVS for convenience. Can this patch be accepted this time? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-12-12 07:25 Message: Logged In: YES user_id=86216 I'm not happy with my workaround, but I'm not happy that Python will not build OOTB under Cygwin until the fork() issue gets resolved. Choose your poison! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-12 06:40 Message: Logged In: YES user_id=6656 I'm rejecting this. Linking _socket statically is a better workaround until the issue actually gets sorted out at the cygwin end. Jason, feel free to complain if you think this isn't the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:34 Message: Logged In: YES user_id=6380 Sure. While the release candidate is officially scheduled for Wednesday this weel, I think it'll actually be Friday. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-12-10 07:21 Message: Logged In: YES user_id=6656 Well, it lets Python build, but the resulting Python doesn't work all that well. I've just noticed that linking _socket statically seems to cure the problem. Can we have a few more days to fiddle with this? I wouldn't recommend applying this patch at this stage. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-10 07:08 Message: Logged In: YES user_id=6380 Michael, can you review this ASAP? If not, please assign to Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=491107&group_id=5470 From noreply@sourceforge.net Wed May 22 18:34:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 10:34:57 -0700 Subject: [Patches] [ python-Patches-559288 ] Use builtin boolean if present Message-ID: Patches item #559288, was opened at 2002-05-22 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fredrik Lundh (effbot) Summary: Use builtin boolean if present Initial Comment: Now that Python has a boolean type, perhaps xmlrpclib should use it if available. Here's a patch that (I think) does what's necessary. The existing test case (which does manipulate a boolean) passes. Haven't tested it with a pre-bool version of Python though. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470 From noreply@sourceforge.net Wed May 22 18:46:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 10:46:01 -0700 Subject: [Patches] [ python-Patches-559288 ] Use builtin boolean if present Message-ID: Patches item #559288, was opened at 2002-05-22 12:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Fredrik Lundh (effbot) Summary: Use builtin boolean if present Initial Comment: Now that Python has a boolean type, perhaps xmlrpclib should use it if available. Here's a patch that (I think) does what's necessary. The existing test case (which does manipulate a boolean) passes. Haven't tested it with a pre-bool version of Python though. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-05-22 12:46 Message: Logged In: YES user_id=44345 new patch - don't know why running the test suite didn't catch the NameError... ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559288&group_id=5470 From noreply@sourceforge.net Wed May 22 20:59:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 12:59:44 -0700 Subject: [Patches] [ python-Patches-559344 ] hotshot logreader unreliable Message-ID: Patches item #559344, was opened at 2002-05-22 19:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559344&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: hotshot logreader unreliable Initial Comment: The hotshot logreader object does not refill the input buffer correctly and gets confused by certain profile log files. I have a log file that triggers this bug if anyone is interested. It can probably be reproduced by repeatedly profiling a program with lots of modules and functions and trying to read the log. Rather then try to fix the buffer refill I've removed it entirely. Using fgetc is much simpler and should perform as well or better (but who cares). I think this is a bugfix candidate. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559344&group_id=5470 From noreply@sourceforge.net Wed May 22 21:30:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 13:30:16 -0700 Subject: [Patches] [ python-Patches-476814 ] foreign-platform newline support Message-ID: Patches item #476814, was opened at 2001-10-31 11:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Barry Warsaw (bwarsaw) Summary: foreign-platform newline support Initial Comment: This patch enables Python to interpret all known newline conventions, CR, LF or CRLF, on all platforms. This support is enabled by configuring with --with-universal-newlines (so by default it is off, and everything should behave as usual). With universal newline support enabled two things happen: - When importing or otherwise parsing .py files any newline convention is accepted. - Python code can pass a new "t" mode parameter to open() which reads files with any newline convention. "t" cannot be combined with any other mode flags like "w" or "+", for obvious reasons. File objects have a new attribute "newlines" which contains the type of newlines encountered in the file (or None when no newline has been seen, or "mixed" if there were various types of newlines). Also included is a test script which tests both file I/O and parsing. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2002-05-22 16:30 Message: Logged In: YES user_id=12800 I'll be committing the documentation changes momentarily. You were pretty close, and fortunately I had Dr. Doco sitting next to me to clean up a few nits. I'm also going to check in a change to the builtin `file' docstring. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-14 16:15 Message: Logged In: YES user_id=45365 Barry, I've checked in the code fixes, but I don't dare check in the documentation fixes myself, as I have no TeX and hence no way to test them. Could you do this, please, and also check that I'm following all the relevant guidelines? Thanks! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-13 19:31 Message: Logged In: YES user_id=45365 A final tweaks: return a tuple of newline values in stead of 'mixed'. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-11 16:31 Message: Logged In: YES user_id=21627 What is the rationale for making this a compile-time option? It seems to complicate things, with no apparent advantage. If this is for backwards compatibility, don't make it an option: nobody will rebuild Python just to work around a compatibility problem. Apart from that, the patch looks goo.d ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-03-28 18:17 Message: Logged In: YES user_id=45365 New doc patch, and new version of the patch that mainly allows the U to be specified (no-op) in non-univ-newline-builds. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-25 16:07 Message: Logged In: YES user_id=6380 Thanks! But there's no documentation. Could I twist your arm for a separate doc patch? I'm tempted to give this a +1, but I'd like to hear from MvL and MAL to see if they foresee any interaction with their PEP 262 implemetation. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-03-13 17:44 Message: Logged In: YES user_id=45365 A new version of the patch. Main differences are that U is now the mode character to trigger universal newline input and --with-universal-newlines is default on. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-01-16 17:47 Message: Logged In: YES user_id=45365 This version of the patch addresses the bug in Py_UniversalNewlineFread and fixes up some minor details. Tim's other issues are addressed (at least: I think they are:-) in a forthcoming PEP. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-12-13 18:57 Message: Logged In: YES user_id=31435 Back to Jack -- and sorry for sitting on it so long. Clearly this isn't making it into 2.2 in the core. As I said on Python-Dev, I believe this needs a PEP: the design decisions are debatable, so *should* be debated outside the Mac community too. Note, though, that I can't stop you from adding it to the 2.2 Mac distribution (if you want it badly enough there). If a PEP won't be written, I suggest finding someone else to review it again; maybe Guido. Note that the patch needs doc changes too. The patch to regrtest.py doesn't belong here (I assume it just slipped in). There seems a lot of code in support of the f_newlinetypes member, and the value of that member isn't clear -- I can't imagine a good use for it (maybe it's a Mac thing?). The implementation of Py_UniversalNewlineFread appears incorrect to me: it reads n bytes *every* time around the outer loop, no matter how few characters are still required, and n doesn't change inside the loop. The business about the GIL may be due to the lack of docs: are, or are not, people supposed to release the GIL themselves around calls to these guys? It's not documented, and it appears your intent differed from my guess. Finally, it would be better to call ferror () after calling fread() instead of before it . ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-14 10:13 Message: Logged In: YES user_id=45365 Here's a new version of the patch. To address your issues one by one: - get_line and Py_UniversalNewlineFgets are too difficult to integrate, at leat, I don't see how I could do it. The storage management of get_line gets in the way. - The global lock comment I don't understand. The Universal... routines are replacements for fgets() and fread(), so have nothing to do with the interpreter lock. - The logic of all three routines (get_line too) has changed and I've put comments in. I hope this addresses some of the points. - If universal_newline is false for a certain PyFileObject we now immedeately take a quick exit via fgets() or fread(). There's also a new test script, that tests some more border cases (like lines longer than 100 characters, and a lone CR just before end of file). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-11-05 03:16 Message: Logged In: YES user_id=31435 It would be better if get_line just called Py_UniversalNewlineFgets (when appropriate) instead of duplicating its logic inline. Py_UniversalNewlineFgets and Py_UniversalNewlineFread should deal with releasing the global lock themselves -- the correct granularity for lock release/reacquire is around the C-level input routines (esp. for fread). The new routines never check for I/O errors! Why not? It seems essential. The new Fgets checks for EOF at the end of the loop instead of the top. This is surprising, and I stared a long time in vain trying to guess why. Setting newlinetypes |= NEWLINE_CR; immediately after seeing an '\r' would be as fast (instead of waiting to see EOF and then inferring the prior existence of '\r' indirectly from the state of the skipnextlf flag). Speaking of which , the fobj tests in the inner loop waste cycles. Set the local flag vrbls whether or not fobj is NULL. When you're *out* of the inner loop you can simply decline to store the new masks when fobj is NULL (and you're already doing the latter anyway). A test and branch inside the loop is much more expensive than or'ing in a flag bit inside the loop, ditto harder to understand. Floating the univ_newline test out of the loop (and duplicating the loop body, one way for univ_newline true and the other for it false) would also save a test and branch on every character. Doing fread one character at a time is very inefficient. Since you know you need to obtain n characters in the end, and that these transformations require reading at least n characters, you could very profitably read n characters in one gulp at the start, then switch to k at a time where k is the number of \r\n pairs seen since the last fread call. This is easier to code than it sounds . It would be fine by me if you included (and initialized) the new file-object fields all the time, whether or not universal newlines are configured. I'd rather waste a few bytes in a file object than see #ifdefs spread thru the code. I'll be damned if I can think of a quick way to do this stuff on Windows -- native Windows fgets() is still the only Windows handle we have on avoiding crushing thread overhead inside MS's C library. I'll think some more about it (the thrust still being to eliminate the 't' mode flag, as whined about on Python-Dev). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-10-31 12:38 Message: Logged In: YES user_id=6380 Tim, can you review this or pass it on to someone else who has time? Jack developed this patch after a discussion in which I was involved in some of the design, but I won't have time to look at it until December. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=476814&group_id=5470 From noreply@sourceforge.net Thu May 23 00:09:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 16:09:55 -0700 Subject: [Patches] [ python-Patches-536278 ] force gzip to open files with 'b' Message-ID: Patches item #536278, was opened at 2002-03-28 09:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=536278&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: force gzip to open files with 'b' Initial Comment: It doesn't make sense that the gzip module should try to open a file in text mode. The attached patch forces a 'b' into the file open mode if it wasn't given. I also modified the test slightly to try and tickle this code, but I can't test it very effectively, because I don't do Windows... :-) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-22 19:09 Message: Logged In: YES user_id=33168 Works for me, go ahead and check it in. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-05-21 21:33 Message: Logged In: YES user_id=44345 assigning to Neal for a final opinion. New patch includes test_gzip.py modification. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-04-09 12:30 Message: Logged In: YES user_id=44345 good point. updated patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-30 23:12 Message: Logged In: YES user_id=31435 I suggest fixing this via changing the test to if mode and 'b' not in mode: Then mode=None and mode='' will be left alone (as Neal says, the code already does the right thing for those). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-03-28 10:04 Message: Logged In: YES user_id=33168 There is a problem (sorry, I have an evil mind). :-) If '' is passed as the mode, before the patch, this would have been converted to 'rb'. After the patch, mode will become 'b' and that will raise an exception: >>> open('/dev/null', 'b') IOError: [Errno 22] Invalid argument: b If you add an (and mode) condition and that should be fine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=536278&group_id=5470 From noreply@sourceforge.net Thu May 23 02:50:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 22 May 2002 18:50:36 -0700 Subject: [Patches] [ python-Patches-536278 ] force gzip to open files with 'b' Message-ID: Patches item #536278, was opened at 2002-03-28 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=536278&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: force gzip to open files with 'b' Initial Comment: It doesn't make sense that the gzip module should try to open a file in text mode. The attached patch forces a 'b' into the file open mode if it wasn't given. I also modified the test slightly to try and tickle this code, but I can't test it very effectively, because I don't do Windows... :-) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-05-22 20:50 Message: Logged In: YES user_id=44345 gzip.py 1.33, test/test_gzip.py 1.9 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-22 18:09 Message: Logged In: YES user_id=33168 Works for me, go ahead and check it in. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-05-21 20:33 Message: Logged In: YES user_id=44345 assigning to Neal for a final opinion. New patch includes test_gzip.py modification. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-04-09 11:30 Message: Logged In: YES user_id=44345 good point. updated patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-30 22:12 Message: Logged In: YES user_id=31435 I suggest fixing this via changing the test to if mode and 'b' not in mode: Then mode=None and mode='' will be left alone (as Neal says, the code already does the right thing for those). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-03-28 09:04 Message: Logged In: YES user_id=33168 There is a problem (sorry, I have an evil mind). :-) If '' is passed as the mode, before the patch, this would have been converted to 'rb'. After the patch, mode will become 'b' and that will raise an exception: >>> open('/dev/null', 'b') IOError: [Errno 22] Invalid argument: b If you add an (and mode) condition and that should be fine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=536278&group_id=5470 From noreply@sourceforge.net Thu May 23 09:38:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 01:38:00 -0700 Subject: [Patches] [ python-Patches-557946 ] Ebcdic compliancy in stringobject source Message-ID: Patches item #557946, was opened at 2002-05-19 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jean-Yves MENGANT (jymen) Assigned to: Nobody/Anonymous (nobody) Summary: Ebcdic compliancy in stringobject source Initial Comment: the printable character set test made inside strincgobject.c is not compliant with EBCDIC systems(OS390 or OS400) ---------------------------------------------------------------------- >Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 08:38 Message: Logged In: YES user_id=513881 when porting to OS390(EBCDIC os) , the only place I found a bad ASCII asumption which leeds to further python's startup interpreter troubles is the one pointed here. When I fixed it I have been able to use the python interpreter kernel without troubles.Some modules like xmllib may make some ascii asumption but modules portability is a different story since those modules may be declared non EBCDIC compliant. On the second topic using a C library function I am 100% ok the only question is that I am persuaded that using for instance the isascii XPG C function will generate more complex and slower code when trying to keep it in compliancy both with EBCDIC/ASCII targets. Having a more generic #define like : #define EBCDIC inside the config.h set by ./configure when platform is EBCDIC is IMO the best compromise here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:09 Message: Logged In: YES user_id=21627 Is it really worth fixing this? Python assumes that the character set of byte strings is an ASCII superset in many places. If there is any change made here, it should be based on C library functions, rather than on static knowledge of the operating system. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 From noreply@sourceforge.net Thu May 23 10:52:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 02:52:07 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-23 09:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Thu May 23 10:54:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 02:54:57 -0700 Subject: [Patches] [ python-Patches-557946 ] Ebcdic compliancy in stringobject source Message-ID: Patches item #557946, was opened at 2002-05-19 16:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jean-Yves MENGANT (jymen) Assigned to: Nobody/Anonymous (nobody) Summary: Ebcdic compliancy in stringobject source Initial Comment: the printable character set test made inside strincgobject.c is not compliant with EBCDIC systems(OS390 or OS400) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-23 11:54 Message: Logged In: YES user_id=21627 I believe there are a number of places where the code assumes that 'a' .. 'z' covers all Latin letters, and only those, e.g. pypcre.c, regexpr.c, sre.py. ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 10:38 Message: Logged In: YES user_id=513881 when porting to OS390(EBCDIC os) , the only place I found a bad ASCII asumption which leeds to further python's startup interpreter troubles is the one pointed here. When I fixed it I have been able to use the python interpreter kernel without troubles.Some modules like xmllib may make some ascii asumption but modules portability is a different story since those modules may be declared non EBCDIC compliant. On the second topic using a C library function I am 100% ok the only question is that I am persuaded that using for instance the isascii XPG C function will generate more complex and slower code when trying to keep it in compliancy both with EBCDIC/ASCII targets. Having a more generic #define like : #define EBCDIC inside the config.h set by ./configure when platform is EBCDIC is IMO the best compromise here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 19:09 Message: Logged In: YES user_id=21627 Is it really worth fixing this? Python assumes that the character set of byte strings is an ASCII superset in many places. If there is any change made here, it should be based on C library functions, rather than on static knowledge of the operating system. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 From noreply@sourceforge.net Thu May 23 12:47:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 04:47:20 -0700 Subject: [Patches] [ python-Patches-557946 ] Ebcdic compliancy in stringobject source Message-ID: Patches item #557946, was opened at 2002-05-19 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jean-Yves MENGANT (jymen) Assigned to: Nobody/Anonymous (nobody) Summary: Ebcdic compliancy in stringobject source Initial Comment: the printable character set test made inside strincgobject.c is not compliant with EBCDIC systems(OS390 or OS400) ---------------------------------------------------------------------- >Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 11:47 Message: Logged In: YES user_id=513881 I am still 100% with you on that ,my only remark here is that those are mainly either modules or py lib which are not part of python basic kernel. And the idea here is to be able to get a running minimal python kernel on an EBCDIC machine. After that when the basic kernel is up in EBCDIC mode you'll need to deal with some module/lib EBCDIC portability and decide wether or not to adress them if you need to use them.... But the important idea here is to have the python kernel running in order not to be obliged to use REXX if you're prefering python :=) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-23 09:54 Message: Logged In: YES user_id=21627 I believe there are a number of places where the code assumes that 'a' .. 'z' covers all Latin letters, and only those, e.g. pypcre.c, regexpr.c, sre.py. ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 08:38 Message: Logged In: YES user_id=513881 when porting to OS390(EBCDIC os) , the only place I found a bad ASCII asumption which leeds to further python's startup interpreter troubles is the one pointed here. When I fixed it I have been able to use the python interpreter kernel without troubles.Some modules like xmllib may make some ascii asumption but modules portability is a different story since those modules may be declared non EBCDIC compliant. On the second topic using a C library function I am 100% ok the only question is that I am persuaded that using for instance the isascii XPG C function will generate more complex and slower code when trying to keep it in compliancy both with EBCDIC/ASCII targets. Having a more generic #define like : #define EBCDIC inside the config.h set by ./configure when platform is EBCDIC is IMO the best compromise here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:09 Message: Logged In: YES user_id=21627 Is it really worth fixing this? Python assumes that the character set of byte strings is an ASCII superset in many places. If there is any change made here, it should be based on C library functions, rather than on static knowledge of the operating system. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 From noreply@sourceforge.net Thu May 23 14:49:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 06:49:11 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:49 Message: Logged In: YES user_id=6656 Try this instead. Definitely a good call on the interface front. Still same caveats. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 09:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Thu May 23 14:56:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 06:56:30 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:56 Message: Logged In: YES user_id=6656 Hmm, I don't think I'm going to bother with sigaction. Most of the options just don't make sense given when Python signal handlers get run. So, docs and autoconf hackery (spit) to go... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:49 Message: Logged In: YES user_id=6656 Try this instead. Definitely a good call on the interface front. Still same caveats. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 09:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Thu May 23 21:18:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 13:18:56 -0700 Subject: [Patches] [ python-Patches-555085 ] timeout socket implementation Message-ID: Patches item #555085, was opened at 2002-05-12 08:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555085&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Gilfix (mgilfix) >Assigned to: Guido van Rossum (gvanrossum) Summary: timeout socket implementation Initial Comment: This implements bug #457114 and implements timed socket operations. If a timeout is set and the timeout period elaspes before the socket operation has finished, a socket.error exception is thrown. This patch integrates the functionality at two levels: the timeout capability is integrated at the C level in socketmodule.c. Socket.py was also modified to update fileobject creation on a win platform to handle the case of the underlying socket throwing an exception. The tex documentation was also updated and a new regression unit was provided as test_timeout.py. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-23 16:18 Message: Logged In: YES user_id=6380 For a detailed review, see http://mail.python.org/pipermail/python-dev/2002-May/024340.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=555085&group_id=5470 From noreply@sourceforge.net Thu May 23 21:52:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 13:52:22 -0700 Subject: [Patches] [ python-Patches-559833 ] Expose xrange type in builtins Message-ID: Patches item #559833, was opened at 2002-05-23 15:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559833&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Expose xrange type in builtins Initial Comment: The attached patch to rangeobject.c and bltinmodule.c exposes the xrange type in te builtins module instead of a function. The test suite passes. The one obvious problem I'm aware of is that I simply copied get_len_of_range from bltinmodule.c, so it's now duplicated (it's used by range_new() as well). I didn't want to create another _Py_* symbol just to share this little bit of code. I'll be happy to resolve this problem however seems best. Skip ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559833&group_id=5470 From lolita86@libero.it Thu May 23 17:21:04 2002 From: lolita86@libero.it (lolita) Date: Thu, 23 May 2002 23.19.22 +0200 Subject: [Patches] Eros e soldi:guadagna con internet 0,08 euro a clic Message-ID: sono lolita=2C voglio presentarti il mio nuovo sito affiliazione gratuita con guadagni immediati=3A erotismo=2C chat=2Cloghi e sonerie etc=2C etc=2C l'unico sito che paga cos=EC tanto 0=2C08 euro a clic =2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Eguarda bene la pg di affiliazione=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Ee buon divertimento=2E visita il sito=3A http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 From noreply@sourceforge.net Thu May 23 23:24:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 15:24:12 -0700 Subject: [Patches] [ python-Patches-502205 ] Fix webbrowser running on MachoPython Message-ID: Patches item #502205, was opened at 2002-01-11 07:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470 Category: Macintosh Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Steven J. Burr (sburrious) Assigned to: Jack Jansen (jackjansen) Summary: Fix webbrowser running on MachoPython Initial Comment: Allows webbrowser.open call in the Unix version of python running on Mac OS X to open a url in Internet Explorer. Presently, a call to webbrowser.open on this platform either runs a terminal-based browser, such as lynx, if available, or fails. The patch is a context diff against version 1.27 of webbrowser, which appears to be the latest version in CVS. It adds a MacOSX browser class and a test for Mac OS X systems running the Unix version of python. I have tested it successfully several times on my Mac OS X system. I included: assert url not in "'" from the 1.27 version in the MacOSX open method, even though the method calls os.popen rather than os.system to launch the browser. It seemed likely os.popen would raise similar security concerns. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-05-24 00:24 Message: Logged In: YES user_id=45365 Steven, I asked for clarification on various things in your patch on Feb 6, but you haven't replied yet, and I don't want to accept the patch as-is. I've set the state of the patch to "pending", so you now have 14 days to reply if you feel like doing so (otherwise sourceforge will close the patch). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-02-06 00:07 Message: Logged In: YES user_id=45365 Steven, there's a few problems with your patch that I'd like you to fix before I check it in (or convince me:-): - There's references to dillo that seem unrelated, could you take them out? - I'm not sure your code correctly handles the case of the Internet Config module being available on OSX. Does it? - The trick with running ps to see whether the finder is there is only half a solution (the finder may be running but you may still not have access to the window manager, for instance when you're ssh'd to someone else's machine) and it's expensive and error prone too. How about trying to send a noop appleevent to the finder and seeing whether that works? - You can probably get rid of the KCGErrorFailure messages by adding a 2>/dev/null the the applescript command. ---------------------------------------------------------------------- Comment By: Steven J. Burr (sburrious) Date: 2002-01-14 04:50 Message: Logged In: YES user_id=322368 I have submitted a new patch which adds the following functionality: -Uses default browser selected in System Preferences if no browser specified. -Allows user to choose any of the following installed browsers: OmniWeb, iCab, Netscape, Opera, Internet Explorer, links, lynx, w3m. -Tests for OS X running without window server as well as Darwin without OS X. (Note that even without this test, use of the module without the window server did not crash Python, but instead generated the following error message: "KCGErrorFailure: initCGDisplayState: No display interlock.") -Opens url in new window with open_new function or method, if the browser supports this behavior. -Adds support for the Unix Dillo browser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470 From noreply@sourceforge.net Fri May 24 04:47:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 20:47:23 -0700 Subject: [Patches] [ python-Patches-552060 ] Fix breakage of smtplib.starttls() Message-ID: Patches item #552060, was opened at 2002-05-03 23:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552060&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: Martin v. Löwis (loewis) Summary: Fix breakage of smtplib.starttls() Initial Comment: The introduction of socket.sendall in smtplib broke the STARTTLS support. This patch fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=552060&group_id=5470 From noreply@sourceforge.net Fri May 24 04:58:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 23 May 2002 20:58:49 -0700 Subject: [Patches] [ python-Patches-502205 ] Fix webbrowser running on MachoPython Message-ID: Patches item #502205, was opened at 2002-01-10 23:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470 Category: Macintosh Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Steven J. Burr (sburrious) Assigned to: Jack Jansen (jackjansen) Summary: Fix webbrowser running on MachoPython Initial Comment: Allows webbrowser.open call in the Unix version of python running on Mac OS X to open a url in Internet Explorer. Presently, a call to webbrowser.open on this platform either runs a terminal-based browser, such as lynx, if available, or fails. The patch is a context diff against version 1.27 of webbrowser, which appears to be the latest version in CVS. It adds a MacOSX browser class and a test for Mac OS X systems running the Unix version of python. I have tested it successfully several times on my Mac OS X system. I included: assert url not in "'" from the 1.27 version in the MacOSX open method, even though the method calls os.popen rather than os.system to launch the browser. It seemed likely os.popen would raise similar security concerns. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-05-23 16:24 Message: Logged In: YES user_id=45365 Steven, I asked for clarification on various things in your patch on Feb 6, but you haven't replied yet, and I don't want to accept the patch as-is. I've set the state of the patch to "pending", so you now have 14 days to reply if you feel like doing so (otherwise sourceforge will close the patch). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-02-05 16:07 Message: Logged In: YES user_id=45365 Steven, there's a few problems with your patch that I'd like you to fix before I check it in (or convince me:-): - There's references to dillo that seem unrelated, could you take them out? - I'm not sure your code correctly handles the case of the Internet Config module being available on OSX. Does it? - The trick with running ps to see whether the finder is there is only half a solution (the finder may be running but you may still not have access to the window manager, for instance when you're ssh'd to someone else's machine) and it's expensive and error prone too. How about trying to send a noop appleevent to the finder and seeing whether that works? - You can probably get rid of the KCGErrorFailure messages by adding a 2>/dev/null the the applescript command. ---------------------------------------------------------------------- Comment By: Steven J. Burr (sburrious) Date: 2002-01-13 20:50 Message: Logged In: YES user_id=322368 I have submitted a new patch which adds the following functionality: -Uses default browser selected in System Preferences if no browser specified. -Allows user to choose any of the following installed browsers: OmniWeb, iCab, Netscape, Opera, Internet Explorer, links, lynx, w3m. -Tests for OS X running without window server as well as Darwin without OS X. (Note that even without this test, use of the module without the window server did not crash Python, but instead generated the following error message: "KCGErrorFailure: initCGDisplayState: No display interlock.") -Opens url in new window with open_new function or method, if the browser supports this behavior. -Adds support for the Unix Dillo browser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470 From noreply@sourceforge.net Fri May 24 10:46:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 02:46:06 -0700 Subject: [Patches] [ python-Patches-560023 ] More docstrings Message-ID: Patches item #560023, was opened at 2002-05-24 04:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: More docstrings Initial Comment: This patch adds docstrings to MimeWriter.py dumbdbm.py, htmllib.py, and pickle.py. All of the text was taken from the current version of the docs. The comment style uses the triple double quotes with a summary header line and a trailing blank line. Each module was regression tested without exception. The whitespace has been normalized so the Timbot won't have to clean it up afterwards . ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 From noreply@sourceforge.net Fri May 24 11:55:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 03:55:22 -0700 Subject: [Patches] [ python-Patches-559833 ] Expose xrange type in builtins Message-ID: Patches item #559833, was opened at 2002-05-23 15:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559833&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Expose xrange type in builtins Initial Comment: The attached patch to rangeobject.c and bltinmodule.c exposes the xrange type in te builtins module instead of a function. The test suite passes. The one obvious problem I'm aware of is that I simply copied get_len_of_range from bltinmodule.c, so it's now duplicated (it's used by range_new() as well). I didn't want to create another _Py_* symbol just to share this little bit of code. I'll be happy to resolve this problem however seems best. Skip ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 05:55 Message: Logged In: YES user_id=80475 Looks good. Compiles okay on Win32. Regression tests (personal testfarm and python standard) run fine. Consider changing the line in types.py (even if it is going to be deprecated) from, XRangeType = type(xrange(0)), to XRangeType=xrange. Also, do you want to go all the way with this one and make the type subclassable like we did with enumerate()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559833&group_id=5470 From noreply@sourceforge.net Fri May 24 12:59:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 04:59:07 -0700 Subject: [Patches] [ python-Patches-560023 ] More docstrings Message-ID: Patches item #560023, was opened at 2002-05-24 04:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: More docstrings Initial Comment: This patch adds docstrings to MimeWriter.py dumbdbm.py, htmllib.py, and pickle.py. All of the text was taken from the current version of the docs. The comment style uses the triple double quotes with a summary header line and a trailing blank line. Each module was regression tested without exception. The whitespace has been normalized so the Timbot won't have to clean it up afterwards . ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 06:59 Message: Logged In: YES user_id=80475 Attached an extra patch to add docstrings for robotparser.py and rexec.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 From noreply@sourceforge.net Fri May 24 15:15:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 07:15:29 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-24 14:15 Message: Logged In: YES user_id=6656 I think I'm done now. The patch I'm attaching (a) does all the stuff my last patch did. (b) uses the presence of sigprocmask to assume that all the other posix-y stuff is there. I don't know if this is safe, but I don't know what would be. (c) adds tests (d) adds a Misc/NEWS segment. The patch I'll attach in a minute has the docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:56 Message: Logged In: YES user_id=6656 Hmm, I don't think I'm going to bother with sigaction. Most of the options just don't make sense given when Python signal handlers get run. So, docs and autoconf hackery (spit) to go... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:49 Message: Logged In: YES user_id=6656 Try this instead. Definitely a good call on the interface front. Still same caveats. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 09:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Fri May 24 15:22:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 07:22:56 -0700 Subject: [Patches] [ python-Patches-560023 ] More docstrings Message-ID: Patches item #560023, was opened at 2002-05-24 04:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: More docstrings Initial Comment: This patch adds docstrings to MimeWriter.py dumbdbm.py, htmllib.py, and pickle.py. All of the text was taken from the current version of the docs. The comment style uses the triple double quotes with a summary header line and a trailing blank line. Each module was regression tested without exception. The whitespace has been normalized so the Timbot won't have to clean it up afterwards . ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 09:22 Message: Logged In: YES user_id=80475 Attached a third patch to include docstrings for formatter.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 06:59 Message: Logged In: YES user_id=80475 Attached an extra patch to add docstrings for robotparser.py and rexec.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 From noreply@sourceforge.net Fri May 24 15:17:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 07:17:47 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Martin v. Löwis (loewis) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-24 14:17 Message: Logged In: YES user_id=6656 And here are the docs. I've even done a section for whatsnew! The table looks a bit wierd in the html, but I don't think it warrants concern. I think I'm done now. Assigning to Martin for review, but anyone with access to unices other than linux/x86 is encouraged to test! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 14:15 Message: Logged In: YES user_id=6656 I think I'm done now. The patch I'm attaching (a) does all the stuff my last patch did. (b) uses the presence of sigprocmask to assume that all the other posix-y stuff is there. I don't know if this is safe, but I don't know what would be. (c) adds tests (d) adds a Misc/NEWS segment. The patch I'll attach in a minute has the docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:56 Message: Logged In: YES user_id=6656 Hmm, I don't think I'm going to bother with sigaction. Most of the options just don't make sense given when Python signal handlers get run. So, docs and autoconf hackery (spit) to go... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:49 Message: Logged In: YES user_id=6656 Try this instead. Definitely a good call on the interface front. Still same caveats. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 09:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Fri May 24 16:21:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 08:21:38 -0700 Subject: [Patches] [ python-Patches-538395 ] ae* modules: handle type inheritance Message-ID: Patches item #538395, was opened at 2002-04-02 21:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=538395&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Donovan Preston (dsposx) Assigned to: Jack Jansen (jackjansen) Summary: ae* modules: handle type inheritance Initial Comment: The gensuitemodule script creates Python classes out of AppleScript types. It keeps track of properties in _propdict and elements in _elemdict. However, gensuitemodule does not accurately replicate the AppleScript inheritance heirarchy, and __getattr__ only looks in self._propdict and self._elemdict, therefore not finding elements and properties defined in superclasses. Attached is a patch which: 1) Correctly identifies an AppleScript type's superclasses, and defines the Python classes with these superclasses. Since not all names may be defined by the time a new class is defined, this is accomplished by setting a new class' __bases__ after all names are defined. 2) Changes __getattr__ to recurse superclasses while looking through _propdict and _elemdict. It also contains small usability enhancements which will automatically look for a .want or .which property when you are creating specifiers. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-05-24 17:21 Message: Logged In: YES user_id=45365 Donovan, I finally got started with your patch. Two more questions, just to make sure I understand things: - You've changed the way the resource file is opened (in gensuitemodule, processfile(). Why? - The getbaseclasses() function you generate seems prety static. Couldn't it be declared in aetools? Or maybe even be a class method of aetools.TalkTo? Don't bother fixing the patch, just let me know the answers and I'll hack it myself. (And, out of curiosity, where did you find info on the funny properties such as "c@#^"? I've never managed to find anything...) ---------------------------------------------------------------------- Comment By: Donovan Preston (dsposx) Date: 2002-05-02 22:47 Message: Logged In: YES user_id=111050 Hi Jack, I finally got around to reimplementing the functionality of the patch given your suggestions. I think it should be fairly bulletproof. Due to circular imports I ended up having to do more work in the package's __init__.py. The upshot of flattening the lookup dicts is that it gets done once, and then after that name lookups are lightning fast. In our production environment the speedup was impressive :-) Thanks for the suggestions. Donovan ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-03 23:16 Message: Logged In: YES user_id=45365 Donovan, two comments-on-your-comments: - You're absolutely right about the module names. Pickle also uses names, and it's probably the only way to do it. - You're also absolutely right about how to update the _elemdict and _propdict. Or, as Jean-Luc Picard would say: "Make it so!" :-) Oh yes, on the production code/merging problem: aside from Martin's comments here's another tip: make a copy of the subtree that contains the conflict section (why not the whole Mac subtree in your case) and make sure you keep the CVS directories. Start hacking in this copy. Once you're satisfied do a commit from there. As long as you keep the CVS directory with the files there's little that can go wrong. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-03 11:29 Message: Logged In: YES user_id=21627 cvs update will keep a copy of the original file (the one you edited) if it has to merge changes; it will name it .#.. So in no case cvs will destroy your changes. Normally, merging works quite well. If it finds a conflict, it will print a 'C' on update, and put a conflict marker in the file. The stuff above the ===== is your code, the one below is the CVS code. If you want to find out what cvs would do, use 'cvs status'. If you don't want cvs to do merging, the following procedure will work cvs diff -u >patches patch -p0 -R 1.22 by hand without doing a cvs update? I think a cvs update (plus some manual work;-) should solve this. Third: the passing of modules by name (to the decoding routines) seems error prone and not too elegant. Can't you pass the modules themselves in stead of their names? It would also save extra imports in the decoders. Fourth: assigning to __bases__ seems like rather a big hack. Can't we generate the classes with a helper class, similarly to the event helper class in the __init__.py modules: FooApp/Foo_Suite.py would contain the class foo sketched above, and FooApp.__init__.py would contain import othersuite.superfoo import Foo_Suite.foo class foo(Foo_Suite.foo, othersuite.superfoo): pass Fifth, and least important: you're manually iterating over the base classes for lookup. Couldn't we statically combine the _propdict and _elemdict's of the base classes during class declaration, so that at lookup time we'd need only a single dictionary lookup? The "class foo" body in __init__.py would then become something like _propdict = aetools.flatten_dicts( foosuite.foo._propdict, othersuite.superfoo._propdict) and similar for elemdict. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=538395&group_id=5470 From noreply@sourceforge.net Fri May 24 18:51:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 10:51:58 -0700 Subject: [Patches] [ python-Patches-560250 ] isinstance error message Message-ID: Patches item #560250, was opened at 2002-05-24 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance error message Initial Comment: isinstance now accepts a tuple containing classes and/or types as second argument. The patch abstract.diff implements a better error message: isinstance arg 2 must be a class, type or tuple of classes and types instead of isinstance arg 2 must be a class or type ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 From noreply@sourceforge.net Fri May 24 19:18:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 11:18:09 -0700 Subject: [Patches] [ python-Patches-560250 ] isinstance error message Message-ID: Patches item #560250, was opened at 2002-05-24 13:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance error message Initial Comment: isinstance now accepts a tuple containing classes and/or types as second argument. The patch abstract.diff implements a better error message: isinstance arg 2 must be a class, type or tuple of classes and types instead of isinstance arg 2 must be a class or type ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 14:18 Message: Logged In: YES user_id=33168 We should update the docstring too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 From noreply@sourceforge.net Fri May 24 19:20:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 11:20:51 -0700 Subject: [Patches] [ python-Patches-560250 ] isinstance error message Message-ID: Patches item #560250, was opened at 2002-05-24 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance error message Initial Comment: isinstance now accepts a tuple containing classes and/or types as second argument. The patch abstract.diff implements a better error message: isinstance arg 2 must be a class, type or tuple of classes and types instead of isinstance arg 2 must be a class or type ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-24 20:20 Message: Logged In: YES user_id=11105 The doc-string seems ok. Here is it from 2.2.1: isinstance(object, class-or-type-or-tuple) -> Boolean Return whether an object is an instance of a class or of a subclass thereof. With a type as second argument, return whether that is the object's type. The form using a tuple, isinstance(x, (A, B, ...)), is a shortcut for isinstance(x, A) or isinstance(x, B) or ... (etc.). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 20:18 Message: Logged In: YES user_id=33168 We should update the docstring too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 From noreply@sourceforge.net Fri May 24 19:28:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 11:28:33 -0700 Subject: [Patches] [ python-Patches-533008 ] specifying headers for extensions Message-ID: Patches item #533008, was opened at 2002-03-21 12:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=533008&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: specifying headers for extensions Initial Comment: This patch allows to specify that C header files are part of source files for dependency checking. The 'sources' list in Extension instances can be simple filenames as before, but they can also be SourceFile instances created by SourceFile("myfile.c", headers=["inc1.h", "inc2.h"]). Unfortunately not only changes to command.build_ext and command.build_clib had to be made, also all the ccompiler (sub)classes have to be changed because the ccompiler does the actual dependency checking. I updated all the ccompiler subclasses except mwerkscompiler.py, but only msvccompiler has actually been tested. The argument list which dep_util.newer_pairwise() now accepts has changed, the first arg must now be a sequence of SourceFile instances. This may be problematic, better would IMO be to move this function (with a new name?) into ccompiler. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-24 20:28 Message: Logged In: YES user_id=11105 Shouldn't holdup any release. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-25 19:13 Message: Logged In: YES user_id=11105 This patch has two problems: - it is too large, - it breaks custom subclasses of distutils' build command family. I have two of them in my setup scripts, there are probably more out in the world. Here is an idea for a totally different approach: The checking whether targets needs to be rebuild is done with the newer_group() and newer_pairwise() functions in distutils.dep_util. These methods could scan the source-files for include directives and user the timestamps of the include files as well. This patch would be fairly small. OTOH, I have no C-source scanner lying around, and also don't feel to write one. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-04 21:57 Message: Logged In: YES user_id=3066 Wow! That's certainly more patch than I'd expected, but the approach looks about right to me. I'd like to take another look at it in a few days (mail me if I don't take action soon) before we accept, just to make sure I understand it better. Thanks! ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-03-25 10:03 Message: Logged In: YES user_id=11105 Fred requested it this way: http://mail.python.org/pipermail/distutils-sig/2002- March/002806.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-24 23:05 Message: Logged In: YES user_id=6380 Why is this priority 7?????? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=533008&group_id=5470 From noreply@sourceforge.net Fri May 24 19:28:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 11:28:56 -0700 Subject: [Patches] [ python-Patches-560250 ] isinstance error message Message-ID: Patches item #560250, was opened at 2002-05-24 13:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance error message Initial Comment: isinstance now accepts a tuple containing classes and/or types as second argument. The patch abstract.diff implements a better error message: isinstance arg 2 must be a class, type or tuple of classes and types instead of isinstance arg 2 must be a class or type ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 14:28 Message: Logged In: YES user_id=33168 Sorry about that, 2.1.x was the last version where the docstring didn't have tuple. Patch looks good to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 14:20 Message: Logged In: YES user_id=11105 The doc-string seems ok. Here is it from 2.2.1: isinstance(object, class-or-type-or-tuple) -> Boolean Return whether an object is an instance of a class or of a subclass thereof. With a type as second argument, return whether that is the object's type. The form using a tuple, isinstance(x, (A, B, ...)), is a shortcut for isinstance(x, A) or isinstance(x, B) or ... (etc.). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 14:18 Message: Logged In: YES user_id=33168 We should update the docstring too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 From noreply@sourceforge.net Fri May 24 19:27:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 11:27:48 -0700 Subject: [Patches] [ python-Patches-541031 ] context sensitive help/keyword search Message-ID: Patches item #541031, was opened at 2002-04-08 16:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=541031&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: context sensitive help/keyword search Initial Comment: This script/module looks up keywords in the Python manuals. It is usable as CGI script - a version is online at http://starship.python.net/crew/theller/cgi- bin/pyhelp.cgi It can also by used from the command line: python pyhelp.py keyword It can also be used to implement context sensitive help in IDLE or Xemacs (for example) by simply selecting a word and pressing F1. It can use the online version of the manuals at www.python.org/doc/, or it can use local installed html pages. The script/module scans the index pages of the docs for hyperlinks, and pickles the results to disk. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-24 20:27 Message: Logged In: YES user_id=11105 Retracting. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-04-18 09:04 Message: Logged In: YES user_id=11105 Uploaded new version (Rev 1.19 in my local CVS). The online version moved to http://starship.python.net/crew/theller/pyhelp.cgi ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-15 03:06 Message: Logged In: YES user_id=6380 Maybe Fred finds this interesting? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=541031&group_id=5470 From noreply@sourceforge.net Fri May 24 20:09:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 12:09:55 -0700 Subject: [Patches] [ python-Patches-559833 ] Expose xrange type in builtins Message-ID: Patches item #559833, was opened at 2002-05-23 13:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559833&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Expose xrange type in builtins Initial Comment: The attached patch to rangeobject.c and bltinmodule.c exposes the xrange type in te builtins module instead of a function. The test suite passes. The one obvious problem I'm aware of is that I simply copied get_len_of_range from bltinmodule.c, so it's now duplicated (it's used by range_new() as well). I didn't want to create another _Py_* symbol just to share this little bit of code. I'll be happy to resolve this problem however seems best. Skip ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-24 12:09 Message: Logged In: NO The xrange type should be as minimalistic as possible, so making it subclassable is not high on my list. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 03:55 Message: Logged In: YES user_id=80475 Looks good. Compiles okay on Win32. Regression tests (personal testfarm and python standard) run fine. Consider changing the line in types.py (even if it is going to be deprecated) from, XRangeType = type(xrange(0)), to XRangeType=xrange. Also, do you want to go all the way with this one and make the type subclassable like we did with enumerate()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559833&group_id=5470 From noreply@sourceforge.net Fri May 24 21:50:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 13:50:04 -0700 Subject: [Patches] [ python-Patches-560311 ] os.uname() on Darwin space in machine Message-ID: Patches item #560311, was opened at 2002-05-24 20:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560311&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Carlson (timcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: os.uname() on Darwin space in machine Initial Comment: os.uname() on Darwin (Mac OS X) returns a string for "machine" of "Power MacIntosh" which can cause problems. Getting rid of the space might be a good thing ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560311&group_id=5470 From noreply@sourceforge.net Sat May 25 02:07:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 18:07:03 -0700 Subject: [Patches] [ python-Patches-560379 ] Karatsuba multiplication Message-ID: Patches item #560379, was opened at 2002-05-24 21:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Karatsuba multiplication Initial Comment: Adds Karatsuba multiplication to Python. Patches longobject.c to use Karatsuba multiplication in place of gradeschool math. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 From noreply@sourceforge.net Sat May 25 04:23:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 20:23:18 -0700 Subject: [Patches] [ python-Patches-560379 ] Karatsuba multiplication Message-ID: Patches item #560379, was opened at 2002-05-25 03:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Karatsuba multiplication Initial Comment: Adds Karatsuba multiplication to Python. Patches longobject.c to use Karatsuba multiplication in place of gradeschool math. ---------------------------------------------------------------------- Comment By: Christian Tismer (tismer) Date: 2002-05-25 05:23 Message: Logged In: YES user_id=105700 Hmm, not bad. Q: You set the split fence at 40. Where does this number come from? I think this could be optimzed per compiler/platform. You say that you split based on the smaller number. Why this? My intuitive guess would certainly be to always split on the larger number. I just checked my Python implementation which does this. Open question: how to handle very small by very long the best way? Probably the highschool version is better here, and that might have led you to investigate the smaller one. I'd say bosh should be checked. good work! - cheers chris ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 From noreply@sourceforge.net Sat May 25 06:53:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 24 May 2002 22:53:32 -0700 Subject: [Patches] [ python-Patches-560379 ] Karatsuba multiplication Message-ID: Patches item #560379, was opened at 2002-05-24 21:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Karatsuba multiplication Initial Comment: Adds Karatsuba multiplication to Python. Patches longobject.c to use Karatsuba multiplication in place of gradeschool math. ---------------------------------------------------------------------- >Comment By: Christopher A. Craig (ccraig) Date: 2002-05-25 01:53 Message: Logged In: YES user_id=135050 I got 40 from testing. Basically I generated 250 random numbers each for a series of sizes between 5 and 2990 bits long at 15 bit intervals (i.e. the word size), and stored it in a dictionary. Then timed 249 multiplies at each size for a bunch of fence values and used gdchart to make a pretty graph. It cerntainly could be optimized better per compiler/platform, but I don't know how much gain you'ld see. I split on the smaller number because I guessed it would be better. My thought was that if I split on the smaller number I'm guaranteed to reach the fence, at which point I can use the gradeschool method at a near linear cost (since it's O(n*m) and one of those two is at most the fence size). If I split on the larger number, I may run into a condition where the smaller number is less than half the larger, but I haven't reached the fence yet, and then gradeschool could be much more expensive. ---------------------------------------------------------------------- Comment By: Christian Tismer (tismer) Date: 2002-05-24 23:23 Message: Logged In: YES user_id=105700 Hmm, not bad. Q: You set the split fence at 40. Where does this number come from? I think this could be optimzed per compiler/platform. You say that you split based on the smaller number. Why this? My intuitive guess would certainly be to always split on the larger number. I just checked my Python implementation which does this. Open question: how to handle very small by very long the best way? Probably the highschool version is better here, and that might have led you to investigate the smaller one. I'd say bosh should be checked. good work! - cheers chris ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 From noreply@sourceforge.net Sat May 25 17:06:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 25 May 2002 09:06:32 -0700 Subject: [Patches] [ python-Patches-560023 ] More docstrings Message-ID: Patches item #560023, was opened at 2002-05-24 04:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: More docstrings Initial Comment: This patch adds docstrings to MimeWriter.py dumbdbm.py, htmllib.py, and pickle.py. All of the text was taken from the current version of the docs. The comment style uses the triple double quotes with a summary header line and a trailing blank line. Each module was regression tested without exception. The whitespace has been normalized so the Timbot won't have to clean it up afterwards . ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-25 11:06 Message: Logged In: YES user_id=80475 Added gzip.py and cmd.py. Combined all patches into one. Please approve before the source changes. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 09:22 Message: Logged In: YES user_id=80475 Attached a third patch to include docstrings for formatter.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 06:59 Message: Logged In: YES user_id=80475 Attached an extra patch to add docstrings for robotparser.py and rexec.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 From noreply@sourceforge.net Sat May 25 17:16:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 25 May 2002 09:16:57 -0700 Subject: [Patches] [ python-Patches-560379 ] Karatsuba multiplication Message-ID: Patches item #560379, was opened at 2002-05-24 21:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Karatsuba multiplication Initial Comment: Adds Karatsuba multiplication to Python. Patches longobject.c to use Karatsuba multiplication in place of gradeschool math. ---------------------------------------------------------------------- >Comment By: Christopher A. Craig (ccraig) Date: 2002-05-25 12:16 Message: Logged In: YES user_id=135050 I just uploaded a graph with some sample timings in it. Red is a fence of 20. Green is a fence of 40. Blue is a fence of 60. Black is done with unmodified Python 2.2.1. ---------------------------------------------------------------------- Comment By: Christopher A. Craig (ccraig) Date: 2002-05-25 01:53 Message: Logged In: YES user_id=135050 I got 40 from testing. Basically I generated 250 random numbers each for a series of sizes between 5 and 2990 bits long at 15 bit intervals (i.e. the word size), and stored it in a dictionary. Then timed 249 multiplies at each size for a bunch of fence values and used gdchart to make a pretty graph. It cerntainly could be optimized better per compiler/platform, but I don't know how much gain you'ld see. I split on the smaller number because I guessed it would be better. My thought was that if I split on the smaller number I'm guaranteed to reach the fence, at which point I can use the gradeschool method at a near linear cost (since it's O(n*m) and one of those two is at most the fence size). If I split on the larger number, I may run into a condition where the smaller number is less than half the larger, but I haven't reached the fence yet, and then gradeschool could be much more expensive. ---------------------------------------------------------------------- Comment By: Christian Tismer (tismer) Date: 2002-05-24 23:23 Message: Logged In: YES user_id=105700 Hmm, not bad. Q: You set the split fence at 40. Where does this number come from? I think this could be optimzed per compiler/platform. You say that you split based on the smaller number. Why this? My intuitive guess would certainly be to always split on the larger number. I just checked my Python implementation which does this. Open question: how to handle very small by very long the best way? Probably the highschool version is better here, and that might have led you to investigate the smaller one. I'd say bosh should be checked. good work! - cheers chris ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 From noreply@sourceforge.net Sun May 26 00:41:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 25 May 2002 16:41:30 -0700 Subject: [Patches] [ python-Patches-560379 ] Karatsuba multiplication Message-ID: Patches item #560379, was opened at 2002-05-24 21:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christopher A. Craig (ccraig) Assigned to: Nobody/Anonymous (nobody) Summary: Karatsuba multiplication Initial Comment: Adds Karatsuba multiplication to Python. Patches longobject.c to use Karatsuba multiplication in place of gradeschool math. ---------------------------------------------------------------------- >Comment By: Christopher A. Craig (ccraig) Date: 2002-05-25 19:41 Message: Logged In: YES user_id=135050 I made the needed changes to make to split on the bigger number (basically chaged to split on bigger number, and changed all of the places that need to check to see if there are no bits left), and the new one is a little bit faster, so I'm uploading it too. I had been thinking about fixed precision numbers when I wrote it, so I honestly didn't consider the fact that I could just shift the smaller number to 0 and throw it away... :-) ---------------------------------------------------------------------- Comment By: Christopher A. Craig (ccraig) Date: 2002-05-25 12:16 Message: Logged In: YES user_id=135050 I just uploaded a graph with some sample timings in it. Red is a fence of 20. Green is a fence of 40. Blue is a fence of 60. Black is done with unmodified Python 2.2.1. ---------------------------------------------------------------------- Comment By: Christopher A. Craig (ccraig) Date: 2002-05-25 01:53 Message: Logged In: YES user_id=135050 I got 40 from testing. Basically I generated 250 random numbers each for a series of sizes between 5 and 2990 bits long at 15 bit intervals (i.e. the word size), and stored it in a dictionary. Then timed 249 multiplies at each size for a bunch of fence values and used gdchart to make a pretty graph. It cerntainly could be optimized better per compiler/platform, but I don't know how much gain you'ld see. I split on the smaller number because I guessed it would be better. My thought was that if I split on the smaller number I'm guaranteed to reach the fence, at which point I can use the gradeschool method at a near linear cost (since it's O(n*m) and one of those two is at most the fence size). If I split on the larger number, I may run into a condition where the smaller number is less than half the larger, but I haven't reached the fence yet, and then gradeschool could be much more expensive. ---------------------------------------------------------------------- Comment By: Christian Tismer (tismer) Date: 2002-05-24 23:23 Message: Logged In: YES user_id=105700 Hmm, not bad. Q: You set the split fence at 40. Where does this number come from? I think this could be optimzed per compiler/platform. You say that you split based on the smaller number. Why this? My intuitive guess would certainly be to always split on the larger number. I just checked my Python implementation which does this. Open question: how to handle very small by very long the best way? Probably the highschool version is better here, and that might have led you to investigate the smaller one. I'd say bosh should be checked. good work! - cheers chris ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560379&group_id=5470 From noreply@sourceforge.net Sun May 26 16:25:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 May 2002 08:25:24 -0700 Subject: [Patches] [ python-Patches-560736 ] Optimize list iteration Message-ID: Patches item #560736, was opened at 2002-05-26 10:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560736&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: Optimize list iteration Initial Comment: Filled listobject's tp_iter slot with it's own iterator. Speeds looping 5 to 10% (YMMV). Only half of the speed-up comes from using tp_iter. The rest came from code tweaking: -- eliminate the it variable -- invert the limit test to avoid jumps -- bypass the GET_ITEM macro to allow index++ to be combined with the lookup. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560736&group_id=5470 From noreply@sourceforge.net Sun May 26 17:38:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 26 May 2002 09:38:48 -0700 Subject: [Patches] [ python-Patches-557946 ] Ebcdic compliancy in stringobject source Message-ID: Patches item #557946, was opened at 2002-05-19 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jean-Yves MENGANT (jymen) Assigned to: Nobody/Anonymous (nobody) Summary: Ebcdic compliancy in stringobject source Initial Comment: the printable character set test made inside strincgobject.c is not compliant with EBCDIC systems(OS390 or OS400) ---------------------------------------------------------------------- >Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-26 16:38 Message: Logged In: YES user_id=513881 The last attached diff files contains a more robust patch by defining the HAVE_EBCDIC inside the pyconfig.h and using this file inside the stringobject.c ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 11:47 Message: Logged In: YES user_id=513881 I am still 100% with you on that ,my only remark here is that those are mainly either modules or py lib which are not part of python basic kernel. And the idea here is to be able to get a running minimal python kernel on an EBCDIC machine. After that when the basic kernel is up in EBCDIC mode you'll need to deal with some module/lib EBCDIC portability and decide wether or not to adress them if you need to use them.... But the important idea here is to have the python kernel running in order not to be obliged to use REXX if you're prefering python :=) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-23 09:54 Message: Logged In: YES user_id=21627 I believe there are a number of places where the code assumes that 'a' .. 'z' covers all Latin letters, and only those, e.g. pypcre.c, regexpr.c, sre.py. ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 08:38 Message: Logged In: YES user_id=513881 when porting to OS390(EBCDIC os) , the only place I found a bad ASCII asumption which leeds to further python's startup interpreter troubles is the one pointed here. When I fixed it I have been able to use the python interpreter kernel without troubles.Some modules like xmllib may make some ascii asumption but modules portability is a different story since those modules may be declared non EBCDIC compliant. On the second topic using a C library function I am 100% ok the only question is that I am persuaded that using for instance the isascii XPG C function will generate more complex and slower code when trying to keep it in compliancy both with EBCDIC/ASCII targets. Having a more generic #define like : #define EBCDIC inside the config.h set by ./configure when platform is EBCDIC is IMO the best compromise here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:09 Message: Logged In: YES user_id=21627 Is it really worth fixing this? Python assumes that the character set of byte strings is an ASCII superset in many places. If there is any change made here, it should be based on C library functions, rather than on static knowledge of the operating system. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 From noreply@sourceforge.net Mon May 27 14:31:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 May 2002 06:31:15 -0700 Subject: [Patches] [ python-Patches-560311 ] os.uname() on Darwin space in machine Message-ID: Patches item #560311, was opened at 2002-05-24 22:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560311&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Carlson (timcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: os.uname() on Darwin space in machine Initial Comment: os.uname() on Darwin (Mac OS X) returns a string for "machine" of "Power MacIntosh" which can cause problems. Getting rid of the space might be a good thing ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-27 15:31 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560311&group_id=5470 From noreply@sourceforge.net Mon May 27 14:33:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 May 2002 06:33:17 -0700 Subject: [Patches] [ python-Patches-560250 ] isinstance error message Message-ID: Patches item #560250, was opened at 2002-05-24 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance error message Initial Comment: isinstance now accepts a tuple containing classes and/or types as second argument. The patch abstract.diff implements a better error message: isinstance arg 2 must be a class, type or tuple of classes and types instead of isinstance arg 2 must be a class or type ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-27 15:33 Message: Logged In: YES user_id=21627 Isn't there a komma missing between "type" and "or"? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 20:28 Message: Logged In: YES user_id=33168 Sorry about that, 2.1.x was the last version where the docstring didn't have tuple. Patch looks good to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 20:20 Message: Logged In: YES user_id=11105 The doc-string seems ok. Here is it from 2.2.1: isinstance(object, class-or-type-or-tuple) -> Boolean Return whether an object is an instance of a class or of a subclass thereof. With a type as second argument, return whether that is the object's type. The form using a tuple, isinstance(x, (A, B, ...)), is a shortcut for isinstance(x, A) or isinstance(x, B) or ... (etc.). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 20:18 Message: Logged In: YES user_id=33168 We should update the docstring too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 From noreply@sourceforge.net Mon May 27 15:24:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 May 2002 07:24:13 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 17:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-27 16:24 Message: Logged In: YES user_id=21627 The patch looks good; please apply it. It would be good if you copy the doc strings into libsignal.tex. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 16:17 Message: Logged In: YES user_id=6656 And here are the docs. I've even done a section for whatsnew! The table looks a bit wierd in the html, but I don't think it warrants concern. I think I'm done now. Assigning to Martin for review, but anyone with access to unices other than linux/x86 is encouraged to test! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 16:15 Message: Logged In: YES user_id=6656 I think I'm done now. The patch I'm attaching (a) does all the stuff my last patch did. (b) uses the presence of sigprocmask to assume that all the other posix-y stuff is there. I don't know if this is safe, but I don't know what would be. (c) adds tests (d) adds a Misc/NEWS segment. The patch I'll attach in a minute has the docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 15:56 Message: Logged In: YES user_id=6656 Hmm, I don't think I'm going to bother with sigaction. Most of the options just don't make sense given when Python signal handlers get run. So, docs and autoconf hackery (spit) to go... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 15:49 Message: Logged In: YES user_id=6656 Try this instead. Definitely a good call on the interface front. Still same caveats. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 11:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 19:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Mon May 27 15:31:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 May 2002 07:31:47 -0700 Subject: [Patches] [ python-Patches-560250 ] isinstance error message Message-ID: Patches item #560250, was opened at 2002-05-24 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance error message Initial Comment: isinstance now accepts a tuple containing classes and/or types as second argument. The patch abstract.diff implements a better error message: isinstance arg 2 must be a class, type or tuple of classes and types instead of isinstance arg 2 must be a class or type ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-27 16:31 Message: Logged In: YES user_id=11105 Right. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-27 15:33 Message: Logged In: YES user_id=21627 Isn't there a komma missing between "type" and "or"? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 20:28 Message: Logged In: YES user_id=33168 Sorry about that, 2.1.x was the last version where the docstring didn't have tuple. Patch looks good to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 20:20 Message: Logged In: YES user_id=11105 The doc-string seems ok. Here is it from 2.2.1: isinstance(object, class-or-type-or-tuple) -> Boolean Return whether an object is an instance of a class or of a subclass thereof. With a type as second argument, return whether that is the object's type. The form using a tuple, isinstance(x, (A, B, ...)), is a shortcut for isinstance(x, A) or isinstance(x, B) or ... (etc.). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 20:18 Message: Logged In: YES user_id=33168 We should update the docstring too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 From noreply@sourceforge.net Mon May 27 15:33:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 May 2002 07:33:02 -0700 Subject: [Patches] [ python-Patches-560250 ] isinstance error message Message-ID: Patches item #560250, was opened at 2002-05-24 19:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance error message Initial Comment: isinstance now accepts a tuple containing classes and/or types as second argument. The patch abstract.diff implements a better error message: isinstance arg 2 must be a class, type or tuple of classes and types instead of isinstance arg 2 must be a class or type ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-05-27 16:33 Message: Logged In: YES user_id=11105 I've attached a new patch. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-27 16:31 Message: Logged In: YES user_id=11105 Right. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-27 15:33 Message: Logged In: YES user_id=21627 Isn't there a komma missing between "type" and "or"? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 20:28 Message: Logged In: YES user_id=33168 Sorry about that, 2.1.x was the last version where the docstring didn't have tuple. Patch looks good to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-05-24 20:20 Message: Logged In: YES user_id=11105 The doc-string seems ok. Here is it from 2.2.1: isinstance(object, class-or-type-or-tuple) -> Boolean Return whether an object is an instance of a class or of a subclass thereof. With a type as second argument, return whether that is the object's type. The form using a tuple, isinstance(x, (A, B, ...)), is a shortcut for isinstance(x, A) or isinstance(x, B) or ... (etc.). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-24 20:18 Message: Logged In: YES user_id=33168 We should update the docstring too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560250&group_id=5470 From noreply@sourceforge.net Mon May 27 16:11:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 May 2002 08:11:42 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-27 15:11 Message: Logged In: YES user_id=6656 OK, this is checked in as: configure.in 1.318 configure 1.308 pyconfig.h.in 1.36 Modules/signalmodule.c 2.67 Lib/test/test_signal.py 1.10 Doc/whatnew/whatsnew23.tex 1.15 Misc/NEWS 1.410 Doc/lib/libsignal.tex 1.24 Not sure what you meant about copying docstrings into libsignal.tex -- did you not see my doc diff? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-27 14:24 Message: Logged In: YES user_id=21627 The patch looks good; please apply it. It would be good if you copy the doc strings into libsignal.tex. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 14:17 Message: Logged In: YES user_id=6656 And here are the docs. I've even done a section for whatsnew! The table looks a bit wierd in the html, but I don't think it warrants concern. I think I'm done now. Assigning to Martin for review, but anyone with access to unices other than linux/x86 is encouraged to test! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 14:15 Message: Logged In: YES user_id=6656 I think I'm done now. The patch I'm attaching (a) does all the stuff my last patch did. (b) uses the presence of sigprocmask to assume that all the other posix-y stuff is there. I don't know if this is safe, but I don't know what would be. (c) adds tests (d) adds a Misc/NEWS segment. The patch I'll attach in a minute has the docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:56 Message: Logged In: YES user_id=6656 Hmm, I don't think I'm going to bother with sigaction. Most of the options just don't make sense given when Python signal handlers get run. So, docs and autoconf hackery (spit) to go... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:49 Message: Logged In: YES user_id=6656 Try this instead. Definitely a good call on the interface front. Still same caveats. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 09:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Mon May 27 16:11:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 May 2002 08:11:08 -0700 Subject: [Patches] [ python-Patches-559250 ] more POSIX signal stuff Message-ID: Patches item #559250, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: more POSIX signal stuff Initial Comment: I got annoyed with Python not having sigsuspend et al, so I wrote this. It's not finished yet: it doesn't do autoconf checks, so if you don't have posix signal handling, it ain't gonna compile) it doesn't do docs. it doesn't do full-on sigaction (because that's not what I was after). but first I thought I'd see if any of the more unix savvy Pythoneers (Martin? Barry?) could see any enormous flaws in the approach... It does seem to work, so far. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-27 15:11 Message: Logged In: YES user_id=6656 OK, this is checked in as: configure.in 1.318 configure 1.308 pyconfig.h.in 1.36 Modules/signalmodule.c 2.67 Lib/test/test_signal.py 1.10 Doc/whatnew/whatsnew23.tex 1.15 Misc/NEWS 1.410 Doc/lib/libsignal.tex 1.24 Not sure what you meant about copying docstrings into libsignal.tex -- did you not see my doc diff? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-27 14:24 Message: Logged In: YES user_id=21627 The patch looks good; please apply it. It would be good if you copy the doc strings into libsignal.tex. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 14:17 Message: Logged In: YES user_id=6656 And here are the docs. I've even done a section for whatsnew! The table looks a bit wierd in the html, but I don't think it warrants concern. I think I'm done now. Assigning to Martin for review, but anyone with access to unices other than linux/x86 is encouraged to test! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-24 14:15 Message: Logged In: YES user_id=6656 I think I'm done now. The patch I'm attaching (a) does all the stuff my last patch did. (b) uses the presence of sigprocmask to assume that all the other posix-y stuff is there. I don't know if this is safe, but I don't know what would be. (c) adds tests (d) adds a Misc/NEWS segment. The patch I'll attach in a minute has the docs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:56 Message: Logged In: YES user_id=6656 Hmm, I don't think I'm going to bother with sigaction. Most of the options just don't make sense given when Python signal handlers get run. So, docs and autoconf hackery (spit) to go... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 13:49 Message: Logged In: YES user_id=6656 Try this instead. Definitely a good call on the interface front. Still same caveats. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-23 09:52 Message: Logged In: YES user_id=6656 Hmm, fair point. I just got carried away :) Patch later. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 17:07 Message: Logged In: YES user_id=21627 I wonder whether we have to expose the API for signal sets. Couldn't we just use lists/tuples of integers? This ought to be similar to the processing of FD_SETs in select. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559250&group_id=5470 From noreply@sourceforge.net Mon May 27 22:33:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 May 2002 14:33:41 -0700 Subject: [Patches] [ python-Patches-561244 ] Micro optimizations Message-ID: Patches item #561244, was opened at 2002-05-27 17:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Micro optimizations Initial Comment: This is stuff I've had sitting around for a while. I was attempting to improve performance in some paths. * Most of the changes are from a loop -> memset. * intobject changes are to initialize small ints at startup, so smallints don't have to be checked for each new int * other misc very small clean-ups Please review and test to see if there are any problems. Also feedback whether this improves performance for various platforms (tested on Linux) or if this patch is even worth it. Files modified are: Include/intobject.h Python/{ceval,pythonrun}.c Objects/{tuple,list,int,frame,}object.c All changes are independant, except for the int changes which affect: Include/intobject.h, Python/pythonrun.c, and Objects/intobject.c. It may also be useful to define the small negative int (NSMALLNEGINTS) to be 5 or so instead of 1. There are several uses -2, -3, ... in the standard library. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&group_id=5470 From noreply@sourceforge.net Mon May 27 22:38:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 27 May 2002 14:38:42 -0700 Subject: [Patches] [ python-Patches-474274 ] Pure Python strptime() (PEP 42) Message-ID: Patches item #474274, was opened at 2001-10-23 16:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Pure Python strptime() (PEP 42) Initial Comment: The attached file contains a pure Python version of strptime(). It attempts to operate as much like time.strptime() within reason. Where vagueness or obvious platform dependence existed, I tried to standardize and be reasonable. PEP 42 makes a request for a portable, consistent version of time.strptime(): - Add a portable implementation of time.strptime() that works in clearly defined ways on all platforms. This module attempts to close that feature request. The code has been tested thoroughly by myself as well as some other people who happened to have caught the post I made to c.l.p a while back and used the module. It is available at the Python Cookbook (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/56036). It has been approved by the editors there and thus is listed as approved. It is also being considered for inclusion in the book (thanks, Alex, for encouraging this submission). A PyUnit testing suite for the module is available at http://www.ocf.berkeley.edu/~bac/Askewed_Thoughts/HTML/code/index.php3#strptime along with the code for the function itself. Localization has been handled in a modular way using regexes. All of it is self-explanatory in the doc strings. It is very straight-forward to include your own localization settings or modify the two languages included in the module (English and Swedish). If the code needs to have its license changed, I am quite happy to do it (I have already given the OK to the Python Cookbook). -Brett Cannon ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2002-05-27 14:38 Message: Logged In: YES user_id=357491 Version 2 of strptime() has now been uploaded. This nearly complete rewrite includes the removal of the need to input locale-specific time info. All need locale info is gleaned from time.strftime(). This makes it able to behave exactly like time.strptime(). ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-24 15:15 Message: Logged In: YES user_id=35752 Go ahead and reuse this item. I'll wait for the updated version. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-03-24 15:01 Message: Logged In: YES user_id=357491 Oops. I thought I had removed the clause. Feel free to remove it. I am going to be cleaning up the module, though, so if you would rather not bother reviewing this version and wait on the cleaned-up one, go ahead. Speaking of which, should I just reply to this bugfix when I get around to the update, or start a new patch? ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-03-23 14:41 Message: Logged In: YES user_id=35752 I'm pretty sure this code needs a different license before it can be accepted. The current license contains the "BSD advertising clause". See http://www.gnu.org/philosophy/bsd.html. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 From noreply@sourceforge.net Tue May 28 10:58:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 28 May 2002 02:58:09 -0700 Subject: [Patches] [ python-Patches-557946 ] Ebcdic compliancy in stringobject source Message-ID: Patches item #557946, was opened at 2002-05-19 16:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jean-Yves MENGANT (jymen) Assigned to: Nobody/Anonymous (nobody) Summary: Ebcdic compliancy in stringobject source Initial Comment: the printable character set test made inside strincgobject.c is not compliant with EBCDIC systems(OS390 or OS400) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-05-28 11:58 Message: Logged In: YES user_id=21627 Modifying pyconfig.h.in (alone) is a mistake: this is a generated file, edit configure.in instead. When producing patches, please produce a single file containing all changes (e.g. with diff -r); this makes processing the patch simpler. I'm still opposed to singling-out a specific encoding; instead, I believe that the approach taken in patch #479898 is more general and ought to solve your problem as well. Can you please study this patch, and see whether you can make it work on your system? ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-26 18:38 Message: Logged In: YES user_id=513881 The last attached diff files contains a more robust patch by defining the HAVE_EBCDIC inside the pyconfig.h and using this file inside the stringobject.c ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 13:47 Message: Logged In: YES user_id=513881 I am still 100% with you on that ,my only remark here is that those are mainly either modules or py lib which are not part of python basic kernel. And the idea here is to be able to get a running minimal python kernel on an EBCDIC machine. After that when the basic kernel is up in EBCDIC mode you'll need to deal with some module/lib EBCDIC portability and decide wether or not to adress them if you need to use them.... But the important idea here is to have the python kernel running in order not to be obliged to use REXX if you're prefering python :=) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-23 11:54 Message: Logged In: YES user_id=21627 I believe there are a number of places where the code assumes that 'a' .. 'z' covers all Latin letters, and only those, e.g. pypcre.c, regexpr.c, sre.py. ---------------------------------------------------------------------- Comment By: Jean-Yves MENGANT (jymen) Date: 2002-05-23 10:38 Message: Logged In: YES user_id=513881 when porting to OS390(EBCDIC os) , the only place I found a bad ASCII asumption which leeds to further python's startup interpreter troubles is the one pointed here. When I fixed it I have been able to use the python interpreter kernel without troubles.Some modules like xmllib may make some ascii asumption but modules portability is a different story since those modules may be declared non EBCDIC compliant. On the second topic using a C library function I am 100% ok the only question is that I am persuaded that using for instance the isascii XPG C function will generate more complex and slower code when trying to keep it in compliancy both with EBCDIC/ASCII targets. Having a more generic #define like : #define EBCDIC inside the config.h set by ./configure when platform is EBCDIC is IMO the best compromise here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-22 19:09 Message: Logged In: YES user_id=21627 Is it really worth fixing this? Python assumes that the character set of byte strings is an ASCII superset in many places. If there is any change made here, it should be based on C library functions, rather than on static knowledge of the operating system. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=557946&group_id=5470 From noreply@sourceforge.net Tue May 28 12:20:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 28 May 2002 04:20:04 -0700 Subject: [Patches] [ python-Patches-561478 ] webchecker chokes at charsets. Message-ID: Patches item #561478, was opened at 2002-05-28 13:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561478&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: webchecker chokes at charsets. Initial Comment: This little patch allowes webchecker.py to handle Content-Type headers like 'text/html; charset=iso-8859-1'. -- Maximillian Dornseif ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561478&group_id=5470 From noreply@sourceforge.net Tue May 28 12:21:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 28 May 2002 04:21:29 -0700 Subject: [Patches] [ python-Patches-561478 ] webchecker chokes at charsets. Message-ID: Patches item #561478, was opened at 2002-05-28 13:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561478&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None >Priority: 3 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: webchecker chokes at charsets. Initial Comment: This little patch allowes webchecker.py to handle Content-Type headers like 'text/html; charset=iso-8859-1'. -- Maximillian Dornseif ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561478&group_id=5470 From noreply@sourceforge.net Tue May 28 16:41:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 28 May 2002 08:41:55 -0700 Subject: [Patches] [ python-Patches-472523 ] Reminder: 2.3 should check tp_compare Message-ID: Patches item #472523, was opened at 2001-10-18 15:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472523&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: Reminder: 2.3 should check tp_compare Initial Comment: In 2.3, the outcome of tp_compare should be required to be -1, 0 or 1; other values should be considered *illegal*. (In 2.2, the docs were changed to stress this but for backwards compatibility this isn't enforced.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-08 03:46 Message: Logged In: YES user_id=21627 I think warning the user is the best thing we can offer; making it an error would break extensions - users can disable the warning if they want to. Hopefully, they will report the problem to the extension author, and hopefully, the extension author tests his code with the new Python release, to notice the problem before his users do. Instances are exempted from the warnings because they already use the "target result set": -1,0,1 for regular outcome; -2 for exceptions. The original rationale for this tightening of the result set is to let -2 indicate exceptions in future Python releases. Perhaps it should also check that, if an exception occured, that the result value is -2. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-08 03:20 Message: Logged In: YES user_id=80475 Here are a few thoughts from my review: Patch needs to diff from current version, 2.173 of object.c Patch compiles okay. Code passes regrtest.py without generating warnings. Code agrees with docs. Scanned remaining code base and found no other direct calls to tp_compare in other *.c or *.h files. If this were an error rather than a warning, convention would indicate a BadInternalCall since this can only be generated by an extension writer. I'm wondering if we are warning the wrong person. An old extension recompiled for Py2.3 will compile fine but then warn an end-user (not the extension writer) about a mysterious tp_compare that they can neither see, nor touch. In try_3way_compare, the warning is not given for instances. Are we exempting instances from the warnings? In try_3way_compare, the warning is given in the section, "v's comparison" but is omitted in "w's comparison" which follows. I think the priority should be raised on this patch because it needs to be in-place for Py2.3a so that we get the earliest possible notice if the warning clashes with use in one of the popular extensions. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-09 06:54 Message: Logged In: YES user_id=21627 Attached is a patch that implements this test, producing a warning if tp_compare does not follow that restriction. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-09 06:54 Message: Logged In: YES user_id=21627 Attached is a patch that implements this test, producing a warning if tp_compare does not follow that restriction. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=472523&group_id=5470 From noreply@sourceforge.net Wed May 29 00:01:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 28 May 2002 16:01:32 -0700 Subject: [Patches] [ python-Patches-561724 ] README additions for Cray T3E Message-ID: Patches item #561724, was opened at 2002-05-29 11:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561724&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Mark Hadfield (hadfield) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: README additions for Cray T3E Initial Comment: As a result of my experience building Python 2.2.1 on NIWA's Cray T3E (see comp.lang.python thread entitled "Building Python on Cray T3E") I have added some info to the appropriate section in README. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561724&group_id=5470 From noreply@sourceforge.net Wed May 29 08:24:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 00:24:25 -0700 Subject: [Patches] [ python-Patches-561832 ] Class attributes for string object Message-ID: Patches item #561832, was opened at 2002-05-29 09:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561832&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Class attributes for string object Initial Comment: This patch attaches the following class attributes to stringobject: whitespace, lowercase, ascii_lowercase, uppercase, ascii_uppercase, letters, ascii_letters, digits, hexdigits, octdigits, punctuation, printable. The implementation is nearly trivial, OTOH I didn't find a place where PyString_Type is initialized, so I did it lazily in the tp_getattro function. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561832&group_id=5470 From noreply@sourceforge.net Wed May 29 11:34:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 03:34:39 -0700 Subject: [Patches] [ python-Patches-561724 ] README additions for Cray T3E Message-ID: Patches item #561724, was opened at 2002-05-28 23:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561724&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Mark Hadfield (hadfield) >Assigned to: Michael Hudson (mwh) Summary: README additions for Cray T3E Initial Comment: As a result of my experience building Python 2.2.1 on NIWA's Cray T3E (see comp.lang.python thread entitled "Building Python on Cray T3E") I have added some info to the appropriate section in README. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-05-29 10:34 Message: Logged In: YES user_id=6656 I think I'll wait until the sre patch gets resolved before checking this in. I just checked in the md5 patch, so that's one paragraph that can get deleted (don't worry about supplying a new patch, though). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561724&group_id=5470 From noreply@sourceforge.net Wed May 29 15:48:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 07:48:59 -0700 Subject: [Patches] [ python-Patches-559344 ] hotshot logreader unreliable Message-ID: Patches item #559344, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559344&group_id=5470 Category: Modules Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Neil Schemenauer (nascheme) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: hotshot logreader unreliable Initial Comment: The hotshot logreader object does not refill the input buffer correctly and gets confused by certain profile log files. I have a log file that triggers this bug if anyone is interested. It can probably be reproduced by repeatedly profiling a program with lots of modules and functions and trying to read the log. Rather then try to fix the buffer refill I've removed it entirely. Using fgetc is much simpler and should perform as well or better (but who cares). I think this is a bugfix candidate. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559344&group_id=5470 From noreply@sourceforge.net Wed May 29 16:16:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 08:16:51 -0700 Subject: [Patches] [ python-Patches-561928 ] Implement Pending (Silent) Deprecation Message-ID: Patches item #561928, was opened at 2002-05-29 11:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Implement Pending (Silent) Deprecation Initial Comment: This patch should implement most of what is necessary to support pending deprecations. I called it PendingDeprecationWarning, rather than SilentDeprecationWarning as briefly discussed on python-dev. It seems to describe what it is, rather than what it does. Includes code & doc changes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 From noreply@sourceforge.net Wed May 29 16:30:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 08:30:30 -0700 Subject: [Patches] [ python-Patches-561928 ] Implement Pending (Silent) Deprecation Message-ID: Patches item #561928, was opened at 2002-05-29 10:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Implement Pending (Silent) Deprecation Initial Comment: This patch should implement most of what is necessary to support pending deprecations. I called it PendingDeprecationWarning, rather than SilentDeprecationWarning as briefly discussed on python-dev. It seems to describe what it is, rather than what it does. Includes code & doc changes. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-29 10:30 Message: Logged In: YES user_id=80475 +1 Is there a way to keep PendingDeprecations silent but still visible (audible?) to PyChecker? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 From noreply@sourceforge.net Wed May 29 16:33:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 08:33:58 -0700 Subject: [Patches] [ python-Patches-561928 ] Implement Pending (Silent) Deprecation Message-ID: Patches item #561928, was opened at 2002-05-29 11:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Implement Pending (Silent) Deprecation Initial Comment: This patch should implement most of what is necessary to support pending deprecations. I called it PendingDeprecationWarning, rather than SilentDeprecationWarning as briefly discussed on python-dev. It seems to describe what it is, rather than what it does. Includes code & doc changes. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-29 11:33 Message: Logged In: YES user_id=33168 Yes, the warnings can be enabled/disabled. And I intend to do that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-29 11:30 Message: Logged In: YES user_id=80475 +1 Is there a way to keep PendingDeprecations silent but still visible (audible?) to PyChecker? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 From noreply@sourceforge.net Wed May 29 16:47:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 08:47:47 -0700 Subject: [Patches] [ python-Patches-561928 ] Implement Pending (Silent) Deprecation Message-ID: Patches item #561928, was opened at 2002-05-29 11:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: Implement Pending (Silent) Deprecation Initial Comment: This patch should implement most of what is necessary to support pending deprecations. I called it PendingDeprecationWarning, rather than SilentDeprecationWarning as briefly discussed on python-dev. It seems to describe what it is, rather than what it does. Includes code & doc changes. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-29 11:47 Message: Logged In: YES user_id=6380 Cool! I agree with the name change. Check it in! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-29 11:33 Message: Logged In: YES user_id=33168 Yes, the warnings can be enabled/disabled. And I intend to do that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-29 11:30 Message: Logged In: YES user_id=80475 +1 Is there a way to keep PendingDeprecations silent but still visible (audible?) to PyChecker? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 From noreply@sourceforge.net Wed May 29 16:48:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 08:48:46 -0700 Subject: [Patches] [ python-Patches-559344 ] hotshot logreader unreliable Message-ID: Patches item #559344, was opened at 2002-05-22 15:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559344&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 7 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: hotshot logreader unreliable Initial Comment: The hotshot logreader object does not refill the input buffer correctly and gets confused by certain profile log files. I have a log file that triggers this bug if anyone is interested. It can probably be reproduced by repeatedly profiling a program with lots of modules and functions and trying to read the log. Rather then try to fix the buffer refill I've removed it entirely. Using fgetc is much simpler and should perform as well or better (but who cares). I think this is a bugfix candidate. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-29 11:48 Message: Logged In: YES user_id=3066 Looks good; please check this into the trunk and 2.2-maint branch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559344&group_id=5470 From noreply@sourceforge.net Wed May 29 16:51:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 08:51:24 -0700 Subject: [Patches] [ python-Patches-560023 ] More docstrings Message-ID: Patches item #560023, was opened at 2002-05-24 05:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: More docstrings Initial Comment: This patch adds docstrings to MimeWriter.py dumbdbm.py, htmllib.py, and pickle.py. All of the text was taken from the current version of the docs. The comment style uses the triple double quotes with a summary header line and a trailing blank line. Each module was regression tested without exception. The whitespace has been normalized so the Timbot won't have to clean it up afterwards . ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-29 11:51 Message: Logged In: YES user_id=3066 Looks good! Check it in. 2.2 candidate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-25 12:06 Message: Logged In: YES user_id=80475 Added gzip.py and cmd.py. Combined all patches into one. Please approve before the source changes. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 10:22 Message: Logged In: YES user_id=80475 Attached a third patch to include docstrings for formatter.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 07:59 Message: Logged In: YES user_id=80475 Attached an extra patch to add docstrings for robotparser.py and rexec.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 From noreply@sourceforge.net Wed May 29 17:24:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 09:24:20 -0700 Subject: [Patches] [ python-Patches-560023 ] More docstrings Message-ID: Patches item #560023, was opened at 2002-05-24 04:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: More docstrings Initial Comment: This patch adds docstrings to MimeWriter.py dumbdbm.py, htmllib.py, and pickle.py. All of the text was taken from the current version of the docs. The comment style uses the triple double quotes with a summary header line and a trailing blank line. Each module was regression tested without exception. The whitespace has been normalized so the Timbot won't have to clean it up afterwards . ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-29 11:24 Message: Logged In: YES user_id=80475 Checked in. Closing patch. MimeWriter 1.8 cmd.py 1.29 dumbdbm.py 1.18 formatter.py 1.20 gzip.py 1.34 htmllib.py 1.19 pickle.py 1.64 rexec.py 1.35 robotparser.py 1.15 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-29 10:51 Message: Logged In: YES user_id=3066 Looks good! Check it in. 2.2 candidate. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-25 11:06 Message: Logged In: YES user_id=80475 Added gzip.py and cmd.py. Combined all patches into one. Please approve before the source changes. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 09:22 Message: Logged In: YES user_id=80475 Attached a third patch to include docstrings for formatter.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-24 06:59 Message: Logged In: YES user_id=80475 Attached an extra patch to add docstrings for robotparser.py and rexec.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=560023&group_id=5470 From noreply@sourceforge.net Wed May 29 17:51:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 09:51:36 -0700 Subject: [Patches] [ python-Patches-561832 ] Class attributes for string object Message-ID: Patches item #561832, was opened at 2002-05-29 02:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561832&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Class attributes for string object Initial Comment: This patch attaches the following class attributes to stringobject: whitespace, lowercase, ascii_lowercase, uppercase, ascii_uppercase, letters, ascii_letters, digits, hexdigits, octdigits, punctuation, printable. The implementation is nearly trivial, OTOH I didn't find a place where PyString_Type is initialized, so I did it lazily in the tp_getattro function. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-29 11:51 Message: Logged In: YES user_id=80475 I understand that these are being put in to provide alternatives to the string module but had always thought they should have been mappings rather that strings. Is now a good time to make the switch before this all gets set in stone? if c not in str.printable: c='*' # works faster as a mapping ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561832&group_id=5470 From noreply@sourceforge.net Wed May 29 19:50:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 11:50:21 -0700 Subject: [Patches] [ python-Patches-559344 ] hotshot logreader unreliable Message-ID: Patches item #559344, was opened at 2002-05-22 19:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559344&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: hotshot logreader unreliable Initial Comment: The hotshot logreader object does not refill the input buffer correctly and gets confused by certain profile log files. I have a log file that triggers this bug if anyone is interested. It can probably be reproduced by repeatedly profiling a program with lots of modules and functions and trying to read the log. Rather then try to fix the buffer refill I've removed it entirely. Using fgetc is much simpler and should perform as well or better (but who cares). I think this is a bugfix candidate. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2002-05-29 18:50 Message: Logged In: YES user_id=35752 Commited as _hotshot.c 1.17 and on 22-maint branch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-29 15:48 Message: Logged In: YES user_id=3066 Looks good; please check this into the trunk and 2.2-maint branch. Thanks! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=559344&group_id=5470 From noreply@sourceforge.net Wed May 29 21:50:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 13:50:10 -0700 Subject: [Patches] [ python-Patches-432401 ] unicode encoding error callbacks Message-ID: Patches item #432401, was opened at 2001-06-12 15:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Postponed Priority: 6 Submitted By: Walter Dörwald (doerwalter) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode encoding error callbacks Initial Comment: This patch adds unicode error handling callbacks to the encode functionality. With this patch it's possible to not only pass 'strict', 'ignore' or 'replace' as the errors argument to encode, but also a callable function, that will be called with the encoding name, the original unicode object and the position of the unencodable character. The callback must return a replacement unicode object that will be encoded instead of the original character. For example replacing unencodable characters with XML character references can be done in the following way. u"aäoöuüß".encode( "ascii", lambda enc, uni, pos: u"&#x%x;" % ord(uni[pos]) ) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-05-29 22:50 Message: Logged In: YES user_id=89016 This new version diff10.txt fixes a memory overwrite/reallocation bug in PyUnicode_EncodeCharmap and moves the error handling out of PyUnicode_EncodeCharmap. A new version of the test script is included too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-16 21:06 Message: Logged In: YES user_id=89016 OK, PyUnicode_TranslateCharmap is finished too. As the errors argument is again not exposed to Python it can't really be tested. Should we add errors as an optional argument to unicode.translate? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-01 19:57 Message: Logged In: YES user_id=89016 OK, PyUnicode_EncodeDecimal is done (diff8.txt), but as the errors argument can't be accessed from Python code, there's not much testing for this. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-20 17:34 Message: Logged In: YES user_id=89016 A new idea for the interface between the codec and the callback: Maybe we could have new exception classes UnicodeEncodeError, UnicodeDecodeError and UnicodeTranslateError derived from UnicodeError. They have all the attributes that are passed as an argument tuple in the current version: string: the original string start: the start position of the unencodable characters/undecodable bytes end: the end position+1 of the unencodable characters/undecodable bytes. reason: the a string, that explains, why the encoding/decoding doesn't work. There is no data object, because when a codec wants to pass extended information to the callback it can do this via a derived class. It might be better to move these attributes to the base class UnicodeError, but this might have backwards compatibility problems. With this method we really can have one global registry for all callbacks, because for callback names that must work with encoding *and* decoding *and* translating (i.e. "strict", "replace" and "ignore"), the callback can check which type of exception was passed, so "replace" can e.g. look like this: def replace(exc): if isinstance(exc, UnicodeDecodeError): return ("?", exc.end) else: return (u"?"*(exc.end-exc.start), exc.end) Another possibility would be to do the commucation callback->codec by assigning to attributes of the exception object. The resyncronisation position could even be preassigned to end, so the callback only needs to specify the replacement in most cases: def replace(exc): if isinstance(exc, UnicodeDecodeError): exc.replacement = "?" else: exc.replacement = u"?"*(exc.end-exc.start) As many of the assignments can now be done on the C level without having to allocate Python objects (except for the replacement string and the reason), this version might even be faster, especially if we allow the codec to reuse the exception object for the next call to the callback. Does this make sense, or is this to fancy? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-18 21:24 Message: Logged In: YES user_id=89016 And here is the test script (test_codeccallbacks.py) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-18 21:22 Message: Logged In: YES user_id=89016 OK, here is the current version of the patch (diff7.txt). PyUnicode_EncodeDecimal and PyUnicode_TranslateCharmap are still missing. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-17 22:50 Message: Logged In: YES user_id=89016 > About the difference between encoding > and decoding: you shouldn't just look > at the case where you work with Unicode > and strings, e.g. take the rot-13 codec > which works on strings only or other > codecs which translate objects into > strings and vice-versa. unicode.encode encodes to str and str.decode decodes to unicode, even for rot-13: >>> u"gürk".encode("rot13") 't\xfcex' >>> "gürk".decode("rot13") u't\xfcex' >>> u"gürk".decode("rot13") Traceback (most recent call last): File "", line 1, in ? AttributeError: 'unicode' object has no attribute 'decode' >>> "gürk".encode("rot13") Traceback (most recent call last): File "", line 1, in ? File "/home/walter/Python-current- readonly/dist/src/Lib/encodings/rot_13.py", line 18, in encode return codecs.charmap_encode(input,errors,encoding_map) UnicodeError: ASCII decoding error: ordinal not in range (128) Here the str is converted to unicode first, before encode is called, but the conversion to unicode fails. Is there an example where something else happens? > Error handling has to be flexible enough > to handle all these situations. Since > the codecs know best how to handle the > situations, I'd make this an implementation > detail of the codec and leave the > behaviour undefined in the general case. OK, but we should suggest, that for encoding unencodable characters are collected and for decoding seperate byte sequences that are considered broken by the codec are passed to the callback: i.e for decoding the handler will never get all broken data in one call, e.g. for "\u30\Uffffffff".decode("unicode-escape") the handler will be called twice (once for "\u30" and "truncated \u escape" as the reason and once for "\Uffffffff" and "illegal character" as the reason.) > For the existing codecs, backward > compatibility should be maintained, > if at all possible. If the patch gets > overly complicated because of this, > we may have to provide a downgrade solution > for this particular problem (I don't think > replace is used in any computational context, > though, since you can never be sure how > many replacement character do get > inserted, so the case may not be > that realistic). > > Raising an exception for the charmap codec > is the right way to go, IMHO. I would > consider the current behaviour a bug. OK, this is implemented in PyUnicode_EncodeCharmap now, and collecting unencodable characters works too. I completely changed the implementation, because the stack approach would have gotten much more complicated when unencodable characters are collected. > For new codecs, I think we should > suggest that replace tries to collect > as much illegal data as possible before > invoking the error handler. The handler > should be aware of the fact that it > won't necessarily get all the broken > data in one call. OK for encoders, for decoders see above. > About the codec error handling > registry: You seem to be using a > Unicode specific approach here. > I'd rather like to see a generic > approach which uses the API > we discussed earlier. Would that be possible? The handlers in the registry are all Unicode specific. and they are different for encoding and for decoding. I renamed the function because of your comment from 2001-06-13 10:05 (which becomes exceedingly difficult to find on this long page! ;)). > In that case, the codec API should > probably be called > codecs.register_error('myhandler', myhandler). > > Does that make sense ? We could require that unique names are used for custom handlers, but for the standard handlers we do have name collisions. To prevent them, we could either remove them from the registry and require that the codec implements the error handling for those itself, or we could to some fiddling, so that u"üöä".encode("ascii", "replace") becomes u"üöä".encode("ascii", "unicodeencodereplace") behind the scenes. But I think two unicode specific registries are much simpler to handle. > BTW, the patch which uses the callback > registry does not seem to be available > on this SF page (the last patch still > converts the errors argument to a > PyObject, which shouldn't be needed > anymore with the new approach). > Can you please upload your > latest version? OK, I'll upload a preliminary version tomorrow. PyUnicode_EncodeDecimal and PyUnicode_TranslateCharmap are still missing, but otherwise the patch seems to be finished. All decoders work and the encoders collect unencodable characters and implement the handling of known callback handler names themselves. As PyUnicode_EncodeDecimal is only used by the int, long, float, and complex constructors, I'd love to get rid of the errors argument, but for completeness sake, I'll implement the callback functionality. > Note that the highlighting codec > would make a nice example > for the new feature. This could be part of the codec callback test script, which I've started to write. We could kill two birds with one stone here: 1. Test the implementation. 2. Document and advocate what is possible with the patch. Another idea: we could have as an example a decoding handler that relaxes the UTF-8 minimal encoding restriction, e.g. def relaxedutf8(enc, uni, startpos, endpos, reason, data): if uni[startpos:startpos+2] == u"\xc0\x80": return (u"\x00", startpos+2) else: raise UnicodeError(...) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-04-17 21:40 Message: Logged In: YES user_id=38388 Sorry for the late response. About the difference between encoding and decoding: you shouldn't just look at the case where you work with Unicode and strings, e.g. take the rot-13 codec which works on strings only or other codecs which translate objects into strings and vice-versa. Error handling has to be flexible enough to handle all these situations. Since the codecs know best how to handle the situations, I'd make this an implementation detail of the codec and leave the behaviour undefined in the general case. For the existing codecs, backward compatibility should be maintained, if at all possible. If the patch gets overly complicated because of this, we may have to provide a downgrade solution for this particular problem (I don't think replace is used in any computational context, though, since you can never be sure how many replacement character do get inserted, so the case may not be that realistic). Raising an exception for the charmap codec is the right way to go, IMHO. I would consider the current behaviour a bug. For new codecs, I think we should suggest that replace tries to collect as much illegal data as possible before invoking the error handler. The handler should be aware of the fact that it won't necessarily get all the broken data in one call. About the codec error handling registry: You seem to be using a Unicode specific approach here. I'd rather like to see a generic approach which uses the API we discussed earlier. Would that be possible ? In that case, the codec API should probably be called codecs.register_error('myhandler', myhandler). Does that make sense ? BTW, the patch which uses the callback registry does not seem to be available on this SF page (the last patch still converts the errors argument to a PyObject, which shouldn't be needed anymore with the new approach). Can you please upload your latest version ? Note that the highlighting codec would make a nice example for the new feature. Thanks. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-04-17 12:21 Message: Logged In: YES user_id=89016 Another note: the patch will change the meaning of charmap encoding slightly: currently "replace" will put a ? into the output, even if ? is not in the mapping, i.e. codecs.charmap_encode(u"c", "replace", {ord("a"): ord ("b")}) will return ('?', 1). With the patch the above example will raise an exception. Off course with the patch many more replace characters can appear, so it is vital that for the replacement string the mapping is done. Is this semantic change OK? (I guess all of the existing codecs have a mapping ord("?")->ord("?")) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-15 18:19 Message: Logged In: YES user_id=89016 So this means that the encoder can collect illegal characters and pass it to the callback. "replace" will replace this with (end-start)*u"?". Decoders don't collect all illegal byte sequences, but call the callback once for every byte sequence that has been found illegal and "replace" will replace it with u"?". Does this make sense? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-15 18:06 Message: Logged In: YES user_id=89016 For encoding it's always (end-start)*u"?": >>> u"ää".encode("ascii", "replace") '??' But for decoding, it is neither nor: >>> "\Ux\U".decode("unicode-escape", "replace") u'\ufffd\ufffd' i.e. a sequence of 5 illegal characters was replace by two replacement characters. This might mean that decoders can't collect all the illegal characters and call the callback once. They might have to call the callback for every single illegal byte sequence to get the old behaviour. (It seems that this patch would be much, much simpler, if we only change the encoders) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-08 19:36 Message: Logged In: YES user_id=38388 Hmm, whatever it takes to maintain backwards compatibility. Do you have an example ? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-08 18:31 Message: Logged In: YES user_id=89016 What should replace do: Return u"?" or (end-start)*u"?" ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-08 16:15 Message: Logged In: YES user_id=38388 Sounds like a good idea. Please keep the encoder and decoder APIs symmetric, though, ie. add the slice information to both APIs. The slice should use the same format as Python's standard slices, that is left inclusive, right exclusive. I like the highlighting feature ! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-08 00:09 Message: Logged In: YES user_id=89016 I'm think about extending the API a little bit: Consider the following example: >>> "\u1".decode("unicode-escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 2: truncated \uXXXX escape The error message is a lie: Not the '1' in position 2 is the problem, but the complete truncated sequence '\u1'. For this the decoder should pass a start and an end position to the handler. For encoding this would be useful too: Suppose I want to have an encoder that colors the unencodable character via an ANSI escape sequences. Then I could do the following: >>> import codecs >>> def color(enc, uni, pos, why, sta): ... return (u"\033[1m<%d>\033[0m" % ord(uni[pos]), pos+1) ... >>> codecs.register_unicodeencodeerrorhandler("color", color) >>> u"aäüöo".encode("ascii", "color") 'a\x1b[1m<228>\x1b[0m\x1b[1m<252>\x1b[0m\x1b[1m<246>\x1b [0mo' But here the sequences "\x1b[0m\x1b[1m" are not needed. To fix this problem the encoder could collect as many unencodable characters as possible and pass those to the error callback in one go (passing a start and end+1 position). This fixes the above problem and reduces the number of calls to the callback, so it should speed up the algorithms in case of custom encoding names. (And it makes the implementation very interesting ;)) What do you think? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-03-07 02:29 Message: Logged In: YES user_id=89016 I started from scratch, and the current state is this: Encoding mostly works (except that I haven't changed TranslateCharmap and EncodeDecimal yet) and most of the decoding stuff works (DecodeASCII and DecodeCharmap are still unchanged) and the decoding callback helper isn't optimized for the "builtin" names yet (i.e. it still calls the handler). For encoding the callback helper knows how to handle "strict", "replace", "ignore" and "xmlcharrefreplace" itself and won't call the callback. This should make the encoder fast enough. As callback name string comparison results are cached it might even be faster than the original. The patch so far didn't require any changes to unicodeobject.h, stringobject.h or stringobject.c ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-03-05 17:49 Message: Logged In: YES user_id=38388 Walter, are you making any progress on the new scheme we discussed on the mailing list (adding an error handler registry much like the codec registry itself instead of trying to redo the complete codec API) ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-09-20 12:38 Message: Logged In: YES user_id=38388 I am postponing this patch until the PEP process has started. This feature won't make it into Python 2.2. Walter, you may want to reference this patch in the PEP. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-08-16 12:53 Message: Logged In: YES user_id=38388 I think we ought to summarize these changes in a PEP to get some more feedback and testing from others as well. I'll look into this after I'm back from vacation on the 10.09. Given the release schedule I am not sure whether this feature will make it into 2.2. The size of the patch is huge and probably needs a lot of testing first. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-27 05:55 Message: Logged In: YES user_id=89016 Changing the decoding API is done now. There are new functions codec.register_unicodedecodeerrorhandler and codec.lookup_unicodedecodeerrorhandler. Only the standard handlers for 'strict', 'ignore' and 'replace' are preregistered. There may be many reasons for decoding errors in the byte string, so I added an additional argument to the decoding API: reason, which gives the reason for the failure, e.g.: >>> "\U1111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 8: truncated \UXXXXXXXX escape >>> "\U11111111".decode("unicode_escape") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'unicodeescape' can't decode byte 0x31 in position 9: illegal Unicode character For symmetry I added this to the encoding API too: >>> u"\xff".encode("ascii") Traceback (most recent call last): File "", line 1, in ? UnicodeError: encoding 'ascii' can't decode byte 0xff in position 0: ordinal not in range(128) The parameters passed to the callbacks now are: encoding, unicode, position, reason, state. The encoding and decoding API for strings has been adapted too, so now the new API should be usable everywhere: >>> unicode("a\xffb\xffc", "ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' >>> "a\xffb\xffc".decode("ascii", ... lambda enc, uni, pos, rea, sta: (u"", pos+1)) u'abc' I had a problem with the decoding API: all the functions in _codecsmodule.c used the t# format specifier. I changed that to O! with &PyString_Type, because otherwise we would have the problem that the decoding API would must pass buffer object around instead of strings, and the callback would have to call str() on the buffer anyway to access a specific character, so this wouldn't be any faster than calling str() on the buffer before decoding. It seems that buffers aren't used anyway. I changed all the old function to call the new ones so bugfixes don't have to be done in two places. There are two exceptions: I didn't change PyString_AsEncodedString and PyString_AsDecodedString because they are documented as deprecated anyway (although they are called in a few spots) This means that I duplicated part of their functionality in PyString_AsEncodedObjectEx and PyString_AsDecodedObjectEx. There are still a few spots that call the old API: E.g. PyString_Format still calls PyUnicode_Decode (but with strict decoding) because it passes the rest of the format string to PyUnicode_Format when it encounters a Unicode object. Should we switch to the new API everywhere even if strict encoding/decoding is used? The size of this patch begins to scare me. I guess we need an extensive test script for all the new features and documentation. I hope you have time to do that, as I'll be busy with other projects in the next weeks. (BTW, I have't touched PyUnicode_TranslateCharmap yet.) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-23 19:03 Message: Logged In: YES user_id=89016 New version of the patch with the error handling callback registry. > > OK, done, now there's a > > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > > codecs.escapereplace_unicodeencode_errors > > that uses \u (or \U if x>0xffff (with a wide build > > of Python)). > > Great! Now PyCodec_EscapeReplaceUnicodeEncodeErrors uses \x in addition to \u and \U where appropriate. > > [...] > > But for special one-shot error handlers, it might still be > > useful to pass the error handler directly, so maybe we > > should leave error as PyObject *, but implement the > > registry anyway? > > Good idea ! > > One minor nit: codecs.registerError() should be named > codecs.register_errorhandler() to be more inline with > the Python coding style guide. OK, but these function are specific to unicode encoding, so now the functions are called: codecs.register_unicodeencodeerrorhandler codecs.lookup_unicodeencodeerrorhandler Now all callbacks (including the new ones: "xmlcharrefreplace" and "escapereplace") are registered in the codecs.c/_PyCodecRegistry_Init so using them is really simple: u"gürk".encode("ascii", "xmlcharrefreplace") ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-13 13:26 Message: Logged In: YES user_id=38388 > > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > > with \uxxxx replacement callback. > > > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > > I'd rather leave the special encoder in place, > > > > since it is being used a lot in Python and > > > > probably some applications too. > > > > > > It would be a slowdown. But callbacks open many > > > possiblities. > > > > True, but in this case I believe that we should stick with > > the native implementation for "unicode-escape". Having > > a standard callback error handler which does the \uXXXX > > replacement would be nice to have though, since this would > > also be usable with lots of other codecs (e.g. all the > > code page ones). > > OK, done, now there's a > PyCodec_EscapeReplaceUnicodeEncodeErrors/ > codecs.escapereplace_unicodeencode_errors > that uses \u (or \U if x>0xffff (with a wide build > of Python)). Great ! > > [...] > > > Should the old TranslateCharmap map to the new > > > TranslateCharmapEx and inherit the > > > "multicharacter replacement" feature, > > > or should I leave it as it is? > > > > If possible, please also add the multichar replacement > > to the old API. I think it is very useful and since the > > old APIs work on raw buffers it would be a benefit to have > > the functionality in the old implementation too. > > OK! I will try to find the time to implement that in the > next days. Good. > > [Decoding error callbacks] > > > > About the return value: > > > > I'd suggest to always use the same tuple interface, e.g. > > > > callback(encoding, input_data, input_position, > state) -> > > (output_to_be_appended, new_input_position) > > > > (I think it's better to use absolute values for the > > position rather than offsets.) > > > > Perhaps the encoding callbacks should use the same > > interface... what do you think ? > > This would make the callback feature hypergeneric and a > little slower, because tuples have to be created, but it > (almost) unifies the encoding and decoding API. ("almost" > because, for the encoder output_to_be_appended will be > reencoded, for the decoder it will simply be appended.), > so I'm for it. That's the point. Note that I don't think the tuple creation will hurt much (see the make_tuple() API in codecs.c) since small tuples are cached by Python internally. > I implemented this and changed the encoders to only > lookup the error handler on the first error. The UCS1 > encoder now no longer uses the two-item stack strategy. > (This strategy only makes sense for those encoder where > the encoding itself is much more complicated than the > looping/callback etc.) So now memory overflow tests are > only done, when an unencodable error occurs, so now the > UCS1 encoder should be as fast as it was without > error callbacks. > > Do we want to enforce new_input_position>input_position, > or should jumping back be allowed? No; moving backwards should be allowed (this may be useful in order to resynchronize with the input data). > Here's is the current todo list: > 1. implement a new TranslateCharmap and fix the old. > 2. New encoding API for string objects too. > 3. Decoding > 4. Documentation > 5. Test cases > > I'm thinking about a different strategy for implementing > callbacks > (see http://mail.python.org/pipermail/i18n-sig/2001- > July/001262.html) > > We coould have a error handler registry, which maps names > to error handlers, then it would be possible to keep the > errors argument as "const char *" instead of "PyObject *". > Currently PyCodec_UnicodeEncodeHandlerForObject is a > backwards compatibility hack that will never go away, > because > it's always more convenient to type > u"...".encode("...", "strict") > instead of > import codecs > u"...".encode("...", codecs.raise_encode_errors) > > But with an error handler registry this function would > become the official lookup method for error handlers. > (PyCodec_LookupUnicodeEncodeErrorHandler?) > Python code would look like this: > --- > def xmlreplace(encoding, unicode, pos, state): > return (u"&#%d;" % ord(uni[pos]), pos+1) > > import codec > > codec.registerError("xmlreplace",xmlreplace) > --- > and then the following call can be made: > u"äöü".encode("ascii", "xmlreplace") > As soon as the first error is encountered, the encoder uses > its builtin error handling method if it recognizes the name > ("strict", "replace" or "ignore") or looks up the error > handling function in the registry if it doesn't. In this way > the speed for the backwards compatible features is the same > as before and "const char *error" can be kept as the > parameter to all encoding functions. For speed common error > handling names could even be implemented in the encoder > itself. > > But for special one-shot error handlers, it might still be > useful to pass the error handler directly, so maybe we > should leave error as PyObject *, but implement the > registry anyway? Good idea ! One minor nit: codecs.registerError() should be named codecs.register_errorhandler() to be more inline with the Python coding style guide. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-07-12 13:03 Message: Logged In: YES user_id=89016 > > [...] > > so I guess we could change the replace handler > > to always return u'?'. This would make the > > implementation a little bit simpler, but the > > explanation of the callback feature *a lot* > > simpler. > > Go for it. OK, done! > [...] > > > Could you add these docs to the Misc/unicode.txt > > > file ? I will eventually take that file and turn > > > it into a PEP which will then serve as general > > > documentation for these things. > > > > I could, but first we should work out how the > > decoding callback API will work. > > Ok. BTW, Barry Warsaw already did the work of converting > the unicode.txt to PEP 100, so the docs should eventually > go there. OK. I guess it would be best to do this when everything is finished. > > > > BTW, I guess PyUnicode_EncodeUnicodeEscape > > > > could be reimplemented as PyUnicode_EncodeASCII > > > > with \uxxxx replacement callback. > > > > > > Hmm, wouldn't that result in a slowdown ? If so, > > > I'd rather leave the special encoder in place, > > > since it is being used a lot in Python and > > > probably some applications too. > > > > It would be a slowdown. But callbacks open many > > possiblities. > > True, but in this case I believe that we should stick with > the native implementation for "unicode-escape". Having > a standard callback error handler which does the \uXXXX > replacement would be nice to have though, since this would > also be usable with lots of other codecs (e.g. all the > code page ones). OK, done, now there's a PyCodec_EscapeReplaceUnicodeEncodeErrors/ codecs.escapereplace_unicodeencode_errors that uses \u (or \U if x>0xffff (with a wide build of Python)). > > For example: > > > > Why can't I print u"gürk"? > > > > is probably one of the most frequently asked > > questions in comp.lang.python. For printing > > Unicode stuff, print could be extended the use an > > error handling callback for Unicode strings (or > > objects where __str__ or tp_str returns a Unicode > > object) instead of using str() which always > > returns an 8bit string and uses strict encoding. > > There might even be a > > sys.setprintencodehandler()/sys.getprintencodehandler () > > There already is a print callback in Python (forgot the > name of the hook though), so this should be possible by > providing the encoding logic in the hook. True: sys.displayhook > [...] > > Should the old TranslateCharmap map to the new > > TranslateCharmapEx and inherit the > > "multicharacter replacement" feature, > > or should I leave it as it is? > > If possible, please also add the multichar replacement > to the old API. I think it is very useful and since the > old APIs work on raw buffers it would be a benefit to have > the functionality in the old implementation too. OK! I will try to find the time to implement that in the next days. > [Decoding error callbacks] > > About the return value: > > I'd suggest to always use the same tuple interface, e.g. > > callback(encoding, input_data, input_position, state) -> > (output_to_be_appended, new_input_position) > > (I think it's better to use absolute values for the > position rather than offsets.) > > Perhaps the encoding callbacks should use the same > interface... what do you think ? This would make the callback feature hypergeneric and a little slower, because tuples have to be created, but it (almost) unifies the encoding and decoding API. ("almost" because, for the encoder output_to_be_appended will be reencoded, for the decoder it will simply be appended.), so I'm for it. I implemented this and changed the encoders to only lookup the error handler on the first error. The UCS1 encoder now no longer uses the two-item stack strategy. (This strategy only makes sense for those encoder where the encoding itself is much more complicated than the looping/callback etc.) So now memory overflow tests are only done, when an unencodable error occurs, so now the UCS1 encoder should be as fast as it was without error callbacks. Do we want to enforce new_input_position>input_position, or should jumping back be allowed? > > > > One additional note: It is vital that errors > > > > is an assignable attribute of the StreamWriter. > > > > > > It is already ! > > > > I know, but IMHO it should be documented that an > > assignable errors attribute must be supported > > as part of the official codec API. > > > > Misc/unicode.txt is not clear on that: > > """ > > It is not required by the Unicode implementation > > to use these base classes, only the interfaces must > > match; this allows writing Codecs as extension types. > > """ > > Good point. I'll add that to the PEP 100. OK. Here's is the current todo list: 1. implement a new TranslateCharmap and fix the old. 2. New encoding API for string objects too. 3. Decoding 4. Documentation 5. Test cases I'm thinking about a different strategy for implementing callbacks (see http://mail.python.org/pipermail/i18n-sig/2001- July/001262.html) We coould have a error handler registry, which maps names to error handlers, then it would be possible to keep the errors argument as "const char *" instead of "PyObject *". Currently PyCodec_UnicodeEncodeHandlerForObject is a backwards compatibility hack that will never go away, because it's always more convenient to type u"...".encode("...", "strict") instead of import codecs u"...".encode("...", codecs.raise_encode_errors) But with an error handler registry this function would become the official lookup method for error handlers. (PyCodec_LookupUnicodeEncodeErrorHandler?) Python code would look like this: --- def xmlreplace(encoding, unicode, pos, state): return (u"&#%d;" % ord(uni[pos]), pos+1) import codec codec.registerError("xmlreplace",xmlreplace) --- and then the following call can be made: u"äöü".encode("ascii", "xmlreplace") As soon as the first error is encountered, the encoder uses its builtin error handling method if it recognizes the name ("strict", "replace" or "ignore") or looks up the error handling function in the registry if it doesn't. In this way the speed for the backwards compatible features is the same as before and "const char *error" can be kept as the parameter to all encoding functions. For speed common error handling names could even be implemented in the encoder itself. But for special one-shot error handlers, it might still be useful to pass the error handler directly, so maybe we should leave error as PyObject *, but implement the registry anyway? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-07-10 14:29 Message: Logged In: YES user_id=38388 Ok, here we go... > > > raise an exception). U+FFFD characters in the > replacement > > > string will be replaced with a character that the > encoder > > > chooses ('?' in all cases). > > > > Nice. > > But the special casing of U+FFFD makes the interface > somewhat > less clean than it could be. It was only done to be 100% > backwards compatible. With the original "replace" > error > handling the codec chose the replacement character. But as > far as I can tell none of the codecs uses anything other > than '?', True. > so I guess we could change the replace handler > to always return u'?'. This would make the implementation a > little bit simpler, but the explanation of the callback > feature *a lot* simpler. Go for it. > And if you still want to handle > an unencodable U+FFFD, you can write a special callback for > that, e.g. > > def FFFDreplace(enc, uni, pos): > if uni[pos] == "\ufffd": > return u"?" > else: > raise UnicodeError(...) > > > ...docs... > > > > Could you add these docs to the Misc/unicode.txt file ? I > > will eventually take that file and turn it into a PEP > which > > will then serve as general documentation for these things. > > I could, but first we should work out how the decoding > callback API will work. Ok. BTW, Barry Warsaw already did the work of converting the unicode.txt to PEP 100, so the docs should eventually go there. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > > replacement callback. > > > > Hmm, wouldn't that result in a slowdown ? If so, I'd > rather > > leave the special encoder in place, since it is being > used a > > lot in Python and probably some applications too. > > It would be a slowdown. But callbacks open many > possiblities. True, but in this case I believe that we should stick with the native implementation for "unicode-escape". Having a standard callback error handler which does the \uXXXX replacement would be nice to have though, since this would also be usable with lots of other codecs (e.g. all the code page ones). > For example: > > Why can't I print u"gürk"? > > is probably one of the most frequently asked questions in > comp.lang.python. For printing Unicode stuff, print could be > extended the use an error handling callback for Unicode > strings (or objects where __str__ or tp_str returns a > Unicode object) instead of using str() which always returns > an 8bit string and uses strict encoding. There might even > be a > sys.setprintencodehandler()/sys.getprintencodehandler() There already is a print callback in Python (forgot the name of the hook though), so this should be possible by providing the encoding logic in the hook. > > > I have not touched PyUnicode_TranslateCharmap yet, > > > should this function also support error callbacks? Why > > > would one want the insert None into the mapping to > call > > > the callback? > > > > 1. Yes. > > 2. The user may want to e.g. restrict usage of certain > > character ranges. In this case the codec would be used to > > verify the input and an exception would indeed be useful > > (e.g. say you want to restrict input to Hangul + ASCII). > > OK, do we want TranslateCharmap to work exactly like > encoding, > i.e. in case of an error should the returned replacement > string again be mapped through the translation mapping or > should it be copied to the output directly? The former would > be more in line with encoding, but IMHO the latter would > be much more useful. It's better to take the second approach (copy the callback output directly to the output string) to avoid endless recursion and other pitfalls. I suppose this will also simplify the implementation somewhat. > BTW, when I implement it I can implement patch #403100 > ("Multicharacter replacements in > PyUnicode_TranslateCharmap") > along the way. I've seen it; will comment on it later. > Should the old TranslateCharmap map to the new > TranslateCharmapEx > and inherit the "multicharacter replacement" feature, > or > should I leave it as it is? If possible, please also add the multichar replacement to the old API. I think it is very useful and since the old APIs work on raw buffers it would be a benefit to have the functionality in the old implementation too. [Decoding error callbacks] > > > A remaining problem is how to implement decoding error > > > callbacks. In Python 2.1 encoding and decoding errors > are > > > handled in the same way with a string value. But with > > > callbacks it doesn't make sense to use the same > callback > > > for encoding and decoding (like > codecs.StreamReaderWriter > > > and codecs.StreamRecoder do). Decoding callbacks have > a > > > different API. Which arguments should be passed to the > > > decoding callback, and what is the decoding callback > > > supposed to do? > > > > I'd suggest adding another set of PyCodec_UnicodeDecode... > () > > APIs for this. We'd then have to augment the base classes > of > > the StreamCodecs to provide two attributes for .errors > with > > a fallback solution for the string case (i.s. "strict" > can > > still be used for both directions). > > Sounds good. Now what is the decoding callback supposed to > do? > I guess it will be called in the same way as the encoding > callback, i.e. with encoding name, original string and > position of the error. It might returns a Unicode string > (i.e. an object of the decoding target type), that will be > emitted from the codec instead of the one offending byte. Or > it might return a tuple with replacement Unicode object and > a resynchronisation offset, i.e. returning (u"?", 1) > means > emit a '?' and skip the offending character. But to make > the offset really useful the callback has to know something > about the encoding, perhaps the codec should be allowed to > pass an additional state object to the callback? > > Maybe the same should be added to the encoding callbacks to? > Maybe the encoding callback should be able to tell the > encoder if the replacement returned should be reencoded > (in which case it's a Unicode object), or directly emitted > (in which case it's an 8bit string)? I like the idea of having an optional state object (basically this should be a codec-defined arbitrary Python object) which then allow the callback to apply additional tricks. The object should be documented to be modifyable in place (simplifies the interface). About the return value: I'd suggest to always use the same tuple interface, e.g. callback(encoding, input_data, input_position, state) -> (output_to_be_appended, new_input_position) (I think it's better to use absolute values for the position rather than offsets.) Perhaps the encoding callbacks should use the same interface... what do you think ? > > > One additional note: It is vital that errors is an > > > assignable attribute of the StreamWriter. > > > > It is already ! > > I know, but IMHO it should be documented that an assignable > errors attribute must be supported as part of the official > codec API. > > Misc/unicode.txt is not clear on that: > """ > It is not required by the Unicode implementation to use > these base classes, only the interfaces must match; this > allows writing Codecs as extension types. > """ Good point. I'll add that to the PEP 100. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-22 22:51 Message: Logged In: YES user_id=38388 Sorry to keep you waiting, Walter. I will look into this again next week -- this week was way too busy... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 19:00 Message: Logged In: YES user_id=38388 On your comment about the non-Unicode codecs: let's keep this separated from the current patch. Don't have much time today. I'll comment on the other things tomorrow. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 17:49 Message: Logged In: YES user_id=89016 Guido van Rossum wrote in python-dev: > True, the "codec" pattern can be used for other > encodings than Unicode. But it seems to me that the > entire codecs architecture is rather strongly geared > towards en/decoding Unicode, and it's not clear > how well other codecs fit in this pattern (e.g. I > noticed that all the non-Unicode codecs ignore the > error handling parameter or assert that > it is set to 'strict'). I noticed that too. asserting that errors=='strict' would mean that the encoder is not able to deal in any other way with unencodable stuff than by raising an error. But that is not the problem here, because for zlib, base64, quopri, hex and uu encoding there can be no unencodable characters. The encoders can simply ignore the errors parameter. Should I remove the asserts from those codecs and change the docstrings accordingly, or will this be done separately? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-13 15:57 Message: Logged In: YES user_id=89016 > > [...] > > raise an exception). U+FFFD characters in the replacement > > string will be replaced with a character that the encoder > > chooses ('?' in all cases). > > Nice. But the special casing of U+FFFD makes the interface somewhat less clean than it could be. It was only done to be 100% backwards compatible. With the original "replace" error handling the codec chose the replacement character. But as far as I can tell none of the codecs uses anything other than '?', so I guess we could change the replace handler to always return u'?'. This would make the implementation a little bit simpler, but the explanation of the callback feature *a lot* simpler. And if you still want to handle an unencodable U+FFFD, you can write a special callback for that, e.g. def FFFDreplace(enc, uni, pos): if uni[pos] == "\ufffd": return u"?" else: raise UnicodeError(...) > > The implementation of the loop through the string is done > > in the following way. A stack with two strings is kept > > and the loop always encodes a character from the string > > at the stacktop. If an error is encountered and the stack > > has only one entry (during encoding of the original string) > > the callback is called and the unicode object returned is > > pushed on the stack, so the encoding continues with the > > replacement string. If the stack has two entries when an > > error is encountered, the replacement string itself has > > an unencodable character and a normal exception raised. > > When the encoder has reached the end of it's current string > > there are two possibilities: when the stack contains two > > entries, this was the replacement string, so the replacement > > string will be poppep from the stack and encoding continues > > with the next character from the original string. If the > > stack had only one entry, encoding is finished. > > Very elegant solution ! I'll put it as a comment in the source. > > (I hope that's enough explanation of the API and > implementation) > > Could you add these docs to the Misc/unicode.txt file ? I > will eventually take that file and turn it into a PEP which > will then serve as general documentation for these things. I could, but first we should work out how the decoding callback API will work. > > I have renamed the static ...121 function to all lowercase > > names. > > Ok. > > > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > > replacement callback. > > Hmm, wouldn't that result in a slowdown ? If so, I'd rather > leave the special encoder in place, since it is being used a > lot in Python and probably some applications too. It would be a slowdown. But callbacks open many possiblities. For example: Why can't I print u"gürk"? is probably one of the most frequently asked questions in comp.lang.python. For printing Unicode stuff, print could be extended the use an error handling callback for Unicode strings (or objects where __str__ or tp_str returns a Unicode object) instead of using str() which always returns an 8bit string and uses strict encoding. There might even be a sys.setprintencodehandler()/sys.getprintencodehandler() > [...] > I think it would be worthwhile to rename the callbacks to > include "Unicode" somewhere, e.g. > PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but > then it points out the application field of the callback > rather well. Same for the callbacks exposed through the > _codecsmodule. OK, done (and PyCodec_XMLCharRefReplaceUnicodeEncodeErrors really is a long name ;)) > > I have not touched PyUnicode_TranslateCharmap yet, > > should this function also support error callbacks? Why > > would one want the insert None into the mapping to call > > the callback? > > 1. Yes. > 2. The user may want to e.g. restrict usage of certain > character ranges. In this case the codec would be used to > verify the input and an exception would indeed be useful > (e.g. say you want to restrict input to Hangul + ASCII). OK, do we want TranslateCharmap to work exactly like encoding, i.e. in case of an error should the returned replacement string again be mapped through the translation mapping or should it be copied to the output directly? The former would be more in line with encoding, but IMHO the latter would be much more useful. BTW, when I implement it I can implement patch #403100 ("Multicharacter replacements in PyUnicode_TranslateCharmap") along the way. Should the old TranslateCharmap map to the new TranslateCharmapEx and inherit the "multicharacter replacement" feature, or should I leave it as it is? > > A remaining problem is how to implement decoding error > > callbacks. In Python 2.1 encoding and decoding errors are > > handled in the same way with a string value. But with > > callbacks it doesn't make sense to use the same callback > > for encoding and decoding (like codecs.StreamReaderWriter > > and codecs.StreamRecoder do). Decoding callbacks have a > > different API. Which arguments should be passed to the > > decoding callback, and what is the decoding callback > > supposed to do? > > I'd suggest adding another set of PyCodec_UnicodeDecode... () > APIs for this. We'd then have to augment the base classes of > the StreamCodecs to provide two attributes for .errors with > a fallback solution for the string case (i.s. "strict" can > still be used for both directions). Sounds good. Now what is the decoding callback supposed to do? I guess it will be called in the same way as the encoding callback, i.e. with encoding name, original string and position of the error. It might returns a Unicode string (i.e. an object of the decoding target type), that will be emitted from the codec instead of the one offending byte. Or it might return a tuple with replacement Unicode object and a resynchronisation offset, i.e. returning (u"?", 1) means emit a '?' and skip the offending character. But to make the offset really useful the callback has to know something about the encoding, perhaps the codec should be allowed to pass an additional state object to the callback? Maybe the same should be added to the encoding callbacks to? Maybe the encoding callback should be able to tell the encoder if the replacement returned should be reencoded (in which case it's a Unicode object), or directly emitted (in which case it's an 8bit string)? > > One additional note: It is vital that errors is an > > assignable attribute of the StreamWriter. > > It is already ! I know, but IMHO it should be documented that an assignable errors attribute must be supported as part of the official codec API. Misc/unicode.txt is not clear on that: """ It is not required by the Unicode implementation to use these base classes, only the interfaces must match; this allows writing Codecs as extension types. """ ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-13 10:05 Message: Logged In: YES user_id=38388 > How the callbacks work: > > A PyObject * named errors is passed in. This may by NULL, > Py_None, 'strict', u'strict', 'ignore', u'ignore', > 'replace', u'replace' or a callable object. > PyCodec_EncodeHandlerForObject maps all of these objects to > one of the three builtin error callbacks > PyCodec_RaiseEncodeErrors (raises an exception), > PyCodec_IgnoreEncodeErrors (returns an empty replacement > string, in effect ignoring the error), > PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode > replacement character to signify to the encoder that it > should choose a suitable replacement character) or directly > returns errors if it is a callable object. When an > unencodable character is encounterd the error handling > callback will be called with the encoding name, the original > unicode object and the error position and must return a > unicode object that will be encoded instead of the offending > character (or the callback may of course raise an > exception). U+FFFD characters in the replacement string will > be replaced with a character that the encoder chooses ('?' > in all cases). Nice. > The implementation of the loop through the string is done in > the following way. A stack with two strings is kept and the > loop always encodes a character from the string at the > stacktop. If an error is encountered and the stack has only > one entry (during encoding of the original string) the > callback is called and the unicode object returned is pushed > on the stack, so the encoding continues with the replacement > string. If the stack has two entries when an error is > encountered, the replacement string itself has an > unencodable character and a normal exception raised. When > the encoder has reached the end of it's current string there > are two possibilities: when the stack contains two entries, > this was the replacement string, so the replacement string > will be poppep from the stack and encoding continues with > the next character from the original string. If the stack > had only one entry, encoding is finished. Very elegant solution ! > (I hope that's enough explanation of the API and implementation) Could you add these docs to the Misc/unicode.txt file ? I will eventually take that file and turn it into a PEP which will then serve as general documentation for these things. > I have renamed the static ...121 function to all lowercase > names. Ok. > BTW, I guess PyUnicode_EncodeUnicodeEscape could be > reimplemented as PyUnicode_EncodeASCII with a \uxxxx > replacement callback. Hmm, wouldn't that result in a slowdown ? If so, I'd rather leave the special encoder in place, since it is being used a lot in Python and probably some applications too. > PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, > PyCodec_ReplaceEncodeErrors are globally visible because > they have to be available in _codecsmodule.c to wrap them as > Python function objects, but they can't be implemented in > _codecsmodule, because they need to be available to the > encoders in unicodeobject.c (through > PyCodec_EncodeHandlerForObject), but importing the codecs > module might result in an endless recursion, because > importing a module requires unpickling of the bytecode, > which might require decoding utf8, which ... (but this will > only happen, if we implement the same mechanism for the > decoding API) I think that codecs.c is the right place for these APIs. _codecsmodule.c is only meant as Python access wrapper for the internal codecs and nothing more. One thing I noted about the callbacks: they assume that they will always get Unicode objects as input. This is certainly not true in the general case (it is for the codecs you touch in the patch). I think it would be worthwhile to rename the callbacks to include "Unicode" somewhere, e.g. PyCodec_UnicodeReplaceEncodeErrors(). It's a long name, but then it points out the application field of the callback rather well. Same for the callbacks exposed through the _codecsmodule. > I have not touched PyUnicode_TranslateCharmap yet, > should this function also support error callbacks? Why would > one want the insert None into the mapping to call the callback? 1. Yes. 2. The user may want to e.g. restrict usage of certain character ranges. In this case the codec would be used to verify the input and an exception would indeed be useful (e.g. say you want to restrict input to Hangul + ASCII). > A remaining problem is how to implement decoding error > callbacks. In Python 2.1 encoding and decoding errors are > handled in the same way with a string value. But with > callbacks it doesn't make sense to use the same callback for > encoding and decoding (like codecs.StreamReaderWriter and > codecs.StreamRecoder do). Decoding callbacks have a > different API. Which arguments should be passed to the > decoding callback, and what is the decoding callback > supposed to do? I'd suggest adding another set of PyCodec_UnicodeDecode...() APIs for this. We'd then have to augment the base classes of the StreamCodecs to provide two attributes for .errors with a fallback solution for the string case (i.s. "strict" can still be used for both directions). > One additional note: It is vital that errors is an > assignable attribute of the StreamWriter. It is already ! > Consider the XML example: For writing an XML DOM tree one > StreamWriter object is used. When a text node is written, > the error handling has to be set to > codecs.xmlreplace_encode_errors, but inside a comment or > processing instruction replacing unencodable characters with > charrefs is not possible, so here codecs.raise_encode_errors > should be used (or better a custom error handler that raises > an error that says "sorry, you can't have unencodable > characters inside a comment") Sure. > BTW, should we continue the discussion in the i18n SIG > mailing list? An email program is much more comfortable than > a HTML textarea! ;) I'd rather keep the discussions on this patch here -- forking it off to the i18n sig will make it very hard to follow up on it. (This HTML area is indeed damn small ;-) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 21:18 Message: Logged In: YES user_id=89016 One additional note: It is vital that errors is an assignable attribute of the StreamWriter. Consider the XML example: For writing an XML DOM tree one StreamWriter object is used. When a text node is written, the error handling has to be set to codecs.xmlreplace_encode_errors, but inside a comment or processing instruction replacing unencodable characters with charrefs is not possible, so here codecs.raise_encode_errors should be used (or better a custom error handler that raises an error that says "sorry, you can't have unencodable characters inside a comment") BTW, should we continue the discussion in the i18n SIG mailing list? An email program is much more comfortable than a HTML textarea! ;) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 20:59 Message: Logged In: YES user_id=89016 How the callbacks work: A PyObject * named errors is passed in. This may by NULL, Py_None, 'strict', u'strict', 'ignore', u'ignore', 'replace', u'replace' or a callable object. PyCodec_EncodeHandlerForObject maps all of these objects to one of the three builtin error callbacks PyCodec_RaiseEncodeErrors (raises an exception), PyCodec_IgnoreEncodeErrors (returns an empty replacement string, in effect ignoring the error), PyCodec_ReplaceEncodeErrors (returns U+FFFD, the Unicode replacement character to signify to the encoder that it should choose a suitable replacement character) or directly returns errors if it is a callable object. When an unencodable character is encounterd the error handling callback will be called with the encoding name, the original unicode object and the error position and must return a unicode object that will be encoded instead of the offending character (or the callback may of course raise an exception). U+FFFD characters in the replacement string will be replaced with a character that the encoder chooses ('?' in all cases). The implementation of the loop through the string is done in the following way. A stack with two strings is kept and the loop always encodes a character from the string at the stacktop. If an error is encountered and the stack has only one entry (during encoding of the original string) the callback is called and the unicode object returned is pushed on the stack, so the encoding continues with the replacement string. If the stack has two entries when an error is encountered, the replacement string itself has an unencodable character and a normal exception raised. When the encoder has reached the end of it's current string there are two possibilities: when the stack contains two entries, this was the replacement string, so the replacement string will be poppep from the stack and encoding continues with the next character from the original string. If the stack had only one entry, encoding is finished. (I hope that's enough explanation of the API and implementation) I have renamed the static ...121 function to all lowercase names. BTW, I guess PyUnicode_EncodeUnicodeEscape could be reimplemented as PyUnicode_EncodeASCII with a \uxxxx replacement callback. PyCodec_RaiseEncodeErrors, PyCodec_IgnoreEncodeErrors, PyCodec_ReplaceEncodeErrors are globally visible because they have to be available in _codecsmodule.c to wrap them as Python function objects, but they can't be implemented in _codecsmodule, because they need to be available to the encoders in unicodeobject.c (through PyCodec_EncodeHandlerForObject), but importing the codecs module might result in an endless recursion, because importing a module requires unpickling of the bytecode, which might require decoding utf8, which ... (but this will only happen, if we implement the same mechanism for the decoding API) I have not touched PyUnicode_TranslateCharmap yet, should this function also support error callbacks? Why would one want the insert None into the mapping to call the callback? A remaining problem is how to implement decoding error callbacks. In Python 2.1 encoding and decoding errors are handled in the same way with a string value. But with callbacks it doesn't make sense to use the same callback for encoding and decoding (like codecs.StreamReaderWriter and codecs.StreamRecoder do). Decoding callbacks have a different API. Which arguments should be passed to the decoding callback, and what is the decoding callback supposed to do? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 20:00 Message: Logged In: YES user_id=38388 About the Py_UNICODE*data, int size APIs: Ok, point taken. In general, I think we ought to keep the callback feature as open as possible, so passing in pointers and sizes would not be very useful. BTW, could you summarize how the callback works in a few lines ? About _Encode121: I'd name this _EncodeUCS1 since that's what it is ;-) About the new functions: I was referring to the new static functions which you gave PyUnicode_... names. If these are not supposed to turn into non-static functions, I'd rather have them use lower case names (since that's how the Python internals work too -- most of the times). ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 18:56 Message: Logged In: YES user_id=89016 > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. Another problem is, that the callback requires a Python object, so in the PyObject *version, the refcount is incref'd and the object is passed to the callback. The Py_UNICODE*/int version would have to create a new Unicode object from the data. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2001-06-12 18:32 Message: Logged In: YES user_id=89016 > * please don't place more than one C statement on one line > like in: > """ > + unicode = unicode2; unicodepos = > unicode2pos; > + unicode2 = NULL; unicode2pos = 0; > """ OK, done! > * Comments should start with a capital letter and be > prepended > to the section they apply to Fixed! > * There should be spaces between arguments in compares > (a == b) not (a==b) Fixed! > * Where does the name "...Encode121" originate ? encode one-to-one, it implements both ASCII and latin-1 encoding. > * module internal APIs should use lower case names (you > converted some of these to PyUnicode_...() -- this is > normally reserved for APIs which are either marked as > potential candidates for the public API or are very > prominent in the code) Which ones? I introduced a new function for every old one, that had a "const char *errors" argument, and a few new ones in codecs.h, of those PyCodec_EncodeHandlerForObject is vital, because it is used to map for old string arguments to the new function objects. PyCodec_RaiseEncodeErrors can be used in the encoder implementation to raise an encode error, but it could be made static in unicodeobject.h so only those encoders implemented there have access to it. > One thing which I don't like about your API change is that > you removed the Py_UNICODE*data, int size style arguments > -- > this makes it impossible to use the new APIs on non-Python > data or data which is not available as Unicode object. I look through the code and found no situation where the Py_UNICODE*/int version is really used and having two (PyObject *)s (the original and the replacement string), instead of UNICODE*/int and PyObject * made the implementation a little easier, but I can fix that. > Please separate the errors.c patch from this patch -- it > seems totally unrelated to Unicode. PyCodec_RaiseEncodeErrors uses this the have a \Uxxxx with four hex digits. I removed it. I'll upload a revised patch as soon as it's done. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-06-12 16:29 Message: Logged In: YES user_id=38388 Thanks for the patch -- it looks very impressive !. I'll give it a try later this week. Some first cosmetic tidbits: * please don't place more than one C statement on one line like in: """ + unicode = unicode2; unicodepos = unicode2pos; + unicode2 = NULL; unicode2pos = 0; """ * Comments should start with a capital letter and be prepended to the section they apply to * There should be spaces between arguments in compares (a == b) not (a==b) * Where does the name "...Encode121" originate ? * module internal APIs should use lower case names (you converted some of these to PyUnicode_...() -- this is normally reserved for APIs which are either marked as potential candidates for the public API or are very prominent in the code) One thing which I don't like about your API change is that you removed the Py_UNICODE*data, int size style arguments -- this makes it impossible to use the new APIs on non-Python data or data which is not available as Unicode object. Please separate the errors.c patch from this patch -- it seems totally unrelated to Unicode. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Wed May 29 22:21:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 29 May 2002 14:21:53 -0700 Subject: [Patches] [ python-Patches-562100 ] Installation database patch Message-ID: Patches item #562100, was opened at 2002-05-29 17:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Installation database patch Initial Comment: The attached patch implements an installation database. This patch is not yet correct; don't bother proofreading it yet. I simply wanted to create a patch number so I could put it in PEP 262. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470 From noreply@sourceforge.net Thu May 30 13:00:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 May 2002 05:00:25 -0700 Subject: [Patches] [ python-Patches-558432 ] Prevent Annoying ' ' from readline Message-ID: Patches item #558432, was opened at 2002-05-20 20:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558432&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Holger P. Krekel (dannu) >Assigned to: Guido van Rossum (gvanrossum) Summary: Prevent Annoying ' ' from readline Initial Comment: readline in all python versions is configured to append a 'space' character for a successful completion. But for almost all python expressions 'space' is not wanted (see coding conventions PEP 8). For example if you have a function 'longfunction' and you type 'longf' you get 'longfunction ' as a completion. note the unwanted space at the end. The patch fixes this behaviour by setting readline's append_character to '\0' which means don't append anything. This doesn't work with readline < 2.1 (AFAIK nowadays readline2.2 is in good use). An alternative approach would be to make the append_character accessable from python so that modules like the rlcompleter.py can set it to '\0'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558432&group_id=5470 From noreply@sourceforge.net Thu May 30 13:28:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 May 2002 05:28:33 -0700 Subject: [Patches] [ python-Patches-561928 ] Implement Pending (Silent) Deprecation Message-ID: Patches item #561928, was opened at 2002-05-29 11:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: Implement Pending (Silent) Deprecation Initial Comment: This patch should implement most of what is necessary to support pending deprecations. I called it PendingDeprecationWarning, rather than SilentDeprecationWarning as briefly discussed on python-dev. It seems to describe what it is, rather than what it does. Includes code & doc changes. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-29 11:47 Message: Logged In: YES user_id=6380 Cool! I agree with the name change. Check it in! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-29 11:33 Message: Logged In: YES user_id=33168 Yes, the warnings can be enabled/disabled. And I intend to do that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-29 11:30 Message: Logged In: YES user_id=80475 +1 Is there a way to keep PendingDeprecations silent but still visible (audible?) to PyChecker? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561928&group_id=5470 From noreply@sourceforge.net Thu May 30 13:40:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 May 2002 05:40:20 -0700 Subject: [Patches] [ python-Patches-561832 ] Class attributes for string object Message-ID: Patches item #561832, was opened at 2002-05-29 03:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561832&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Class attributes for string object Initial Comment: This patch attaches the following class attributes to stringobject: whitespace, lowercase, ascii_lowercase, uppercase, ascii_uppercase, letters, ascii_letters, digits, hexdigits, octdigits, punctuation, printable. The implementation is nearly trivial, OTOH I didn't find a place where PyString_Type is initialized, so I did it lazily in the tp_getattro function. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-30 08:40 Message: Logged In: YES user_id=33168 Based on the recent discussion on python-dev, it seems better to dynamically init lowercase, uppercase, letters, and whitespace; so the locale is used. Probably punctuation and printable should be done this way too, but I'm not sure. Here's the end of the discussion: http://mail.python.org/pipermail/python-dev/2002-May/024655.html Some other notes: * class_attrs should be static (before struct). * you could make #defines for the letters (like "ABC" ...) and re-use them to init the class_attrs to avoid some duplication (this is not important, but could be easier). * The getattro seems hacky, but I don't know if there is a better way. * The // comment would need to be removed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-29 12:51 Message: Logged In: YES user_id=80475 I understand that these are being put in to provide alternatives to the string module but had always thought they should have been mappings rather that strings. Is now a good time to make the switch before this all gets set in stone? if c not in str.printable: c='*' # works faster as a mapping ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561832&group_id=5470 From noreply@sourceforge.net Thu May 30 15:00:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 May 2002 07:00:23 -0700 Subject: [Patches] [ python-Patches-561832 ] Class attributes for string object Message-ID: Patches item #561832, was opened at 2002-05-29 03:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561832&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Class attributes for string object Initial Comment: This patch attaches the following class attributes to stringobject: whitespace, lowercase, ascii_lowercase, uppercase, ascii_uppercase, letters, ascii_letters, digits, hexdigits, octdigits, punctuation, printable. The implementation is nearly trivial, OTOH I didn't find a place where PyString_Type is initialized, so I did it lazily in the tp_getattro function. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-30 10:00 Message: Logged In: YES user_id=6380 I believe that we shouldn't expose these sets as variables at all; we should expose them through methods like islower(). Therefore I'm rejecting this patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-05-30 08:40 Message: Logged In: YES user_id=33168 Based on the recent discussion on python-dev, it seems better to dynamically init lowercase, uppercase, letters, and whitespace; so the locale is used. Probably punctuation and printable should be done this way too, but I'm not sure. Here's the end of the discussion: http://mail.python.org/pipermail/python-dev/2002-May/024655.html Some other notes: * class_attrs should be static (before struct). * you could make #defines for the letters (like "ABC" ...) and re-use them to init the class_attrs to avoid some duplication (this is not important, but could be easier). * The getattro seems hacky, but I don't know if there is a better way. * The // comment would need to be removed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-29 12:51 Message: Logged In: YES user_id=80475 I understand that these are being put in to provide alternatives to the string module but had always thought they should have been mappings rather that strings. Is now a good time to make the switch before this all gets set in stone? if c not in str.printable: c='*' # works faster as a mapping ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561832&group_id=5470 From noreply@sourceforge.net Thu May 30 15:18:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 May 2002 07:18:22 -0700 Subject: [Patches] [ python-Patches-562373 ] Getting rid of string, types and stat Message-ID: Patches item #562373, was opened at 2002-05-30 16:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=562373&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Getting rid of string, types and stat Initial Comment: This patch gets rid of some of the "import string", "import types" or "import stat" statements in the standard library (many still remain, I didn't touch the tools or Demos directory). I hope I didn't touch any of the modules that must stay backwards compatible (like inspect, distutils, sre, anything else?) Maybe the rest of the function in stat should be made methods too? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=562373&group_id=5470 From noreply@sourceforge.net Thu May 30 15:22:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 May 2002 07:22:51 -0700 Subject: [Patches] [ python-Patches-561478 ] webchecker chokes at charsets. Message-ID: Patches item #561478, was opened at 2002-05-28 13:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561478&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None Priority: 3 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: webchecker chokes at charsets. Initial Comment: This little patch allowes webchecker.py to handle Content-Type headers like 'text/html; charset=iso-8859-1'. -- Maximillian Dornseif ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-30 16:22 Message: Logged In: YES user_id=89016 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=561478&group_id=5470 From noreply@sourceforge.net Thu May 30 16:38:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 May 2002 08:38:12 -0700 Subject: [Patches] [ python-Patches-562416 ] Add unittest for shelve.py Message-ID: Patches item #562416, was opened at 2002-05-30 10:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=562416&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: Add unittest for shelve.py Initial Comment: Regression test for shelve.py. Nothing fancy, just verifies the basic documented operation. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=562416&group_id=5470 From noreply@sourceforge.net Thu May 30 16:42:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 May 2002 08:42:26 -0700 Subject: [Patches] [ python-Patches-558432 ] Prevent Annoying ' ' from readline Message-ID: Patches item #558432, was opened at 2002-05-20 16:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558432&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Holger P. Krekel (dannu) Assigned to: Guido van Rossum (gvanrossum) Summary: Prevent Annoying ' ' from readline Initial Comment: readline in all python versions is configured to append a 'space' character for a successful completion. But for almost all python expressions 'space' is not wanted (see coding conventions PEP 8). For example if you have a function 'longfunction' and you type 'longf' you get 'longfunction ' as a completion. note the unwanted space at the end. The patch fixes this behaviour by setting readline's append_character to '\0' which means don't append anything. This doesn't work with readline < 2.1 (AFAIK nowadays readline2.2 is in good use). An alternative approach would be to make the append_character accessable from python so that modules like the rlcompleter.py can set it to '\0'. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-30 11:42 Message: Logged In: YES user_id=6380 Thanks! Checked in. If you want to pursue the alternative, please supply a (new) patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=558432&group_id=5470 From noreply@sourceforge.net Thu May 30 17:06:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 30 May 2002 09:06:36 -0700 Subject: [Patches] [ python-Patches-545096 ] Janitoring in ConfigParser Message-ID: Patches item #545096, was opened at 2002-04-17 06:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=545096&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Janitoring in ConfigParser Initial Comment: The first patch fixes a bug, implements some speed improvements, some memory consumption improvements, enforces the usage of the already available global variables, and extends the allowed chars in option names to be very permissive. The second one, if used, is supposed to be applied over the first one, and implements a walk() generator method for walking trough the options of a section. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-05-30 12:06 Message: Logged In: YES user_id=3066 Two comments: - "section in self.__sections.keys()" can be written (still more efficiently) as "section in self.__sections", *but* the use of the sections() method is done to be subclass-friendly. I'm not sure how important this is since I can't imagine anyone actually subclassing from such a mass of messy code. Perhaps these could be modified to use the has_section() method, which is relatively new. - MAX_INTERPOLATION_DEPTH was not "honored" in the code since it's really a safety net; there's no intention that client code be able to change it. (The sanity of the value is not checked before use.) I'm inclined to retain the use of the constant in the interpolation code, and add a comment above the constant the it exists for informational purposes only. Otherwise, I'm fine with the patch. ;-) Sorry for the delay in responding to this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-22 13:55 Message: Logged In: YES user_id=6380 I'm assigning this to Fred Drake, who has some opinions on ConfigParser. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-04-18 13:07 Message: Logged In: YES user_id=7887 I'd rather explain here the patch that changes behavior, since it's pretty small. This line in the regular expression OPTCRE: r'(?P