From noreply@sourceforge.net Mon Sep 2 07:30:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Sep 2002 23:30:22 -0700 Subject: [Patches] [ python-Patches-601456 ] expose PYTHON_API_VERSION via sys Message-ID: Patches item #601456, was opened at 2002-08-28 20:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601456&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: expose PYTHON_API_VERSION via sys Initial Comment: I was scratching my head today about some API version mismatches I got from the VTK Python wrappers. Apparently, somewhere along the way the VTK build process used two different versions of the Python compilation environment to build different extension modules. From a debugging standpoint it seems like it would be a mild convenience to expose PYTHON_API_VERSION via the sys module. The attached trivial patch does this. This should be easily portable to the 2.1 and 2.2 maintenance branches though it's not strictly a bugfix. Skip ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 08:30 Message: Logged In: YES user_id=21627 There is no documentation change: you'll need to edit libsys.tex (using \versionadded), and Misc/NEWS. Apart from that, the patch is fine; please apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601456&group_id=5470 From noreply@sourceforge.net Mon Sep 2 14:19:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 06:19:15 -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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted 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-09-02 15:19 Message: Logged In: YES user_id=89016 Checked in as: (this is diff13.txt + the test script + dodumentation in two TeX files) Doc/lib/libcodecs.tex 1.11 Doc/lib/libexcs.tex 1.49 Include/codecs.h 2.5 Include/pyerrors.h 2.58 Lib/codecs.py 1.27 Lib/test/test_codeccallbacks.py 1.1 Misc/NEWS 1.476 Modules/_codecsmodule.c 2.15 Objects/stringobject.c 2.186 Objects/unicodeobject.c 2.167 Python/codecs.c 2.15 Python/exceptions.c 1.35 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-08-14 12:23 Message: Logged In: YES user_id=89016 This new version diff13.txt moves the initialization of codec.strict_errors etc. from Modules/_codecsmodule.c to Lib/codecs.py. The error logic for the accessor function is inverted (now its 0 for success and -1 for error). Updated the prototypes to use the new PyAPI_FUNC macro. Enhanced the docstrings for str.(de|en)code and unicode.encode. There seems to be a new string decoding function PyString_DecodeEscape in current CVS. This function has to be updated too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-26 17:41 Message: Logged In: YES user_id=89016 The attached new version of the test script add test for wrong parameter passed to the callbacks or wrong results returned from the callback. It also add tests to the long string tests for copies of the builtin error handlers, so the codec does not recognize the name and goes through the general callback machinery. UTF-7 decoding still has a flaw inherited from the current implementation: >>> "+xxx".decode("utf-7") Traceback (most recent call last): File "", line 1, in ? UnicodeDecodeError: 'utf7' codec can't decode bytes in position 0-3: unterminated shift sequence *>>> "+xxx".decode("utf-7", "ignore") u'\uc71c' The decoder should consider the whole sequence "+xxx" as undecodable, so "Ignore" should return an empty string. Currently the correct sequence will be passed to the callback, but the faulty sequence has already been emitted to the result string. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-24 21:04 Message: Logged In: YES user_id=89016 Attached is a new version of the test script. But we need more tests. UTF-7 is completely untested and using codecs that pass wrong arguments to the handler and handler that return wrong or out of bounds results is untested too. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-24 20:55 Message: Logged In: YES user_id=89016 diff12.txt finally implements the PEP293 specification (i.e. using exceptions for the communication between codec and handler) ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-30 18:30 Message: Logged In: YES user_id=89016 diff11.txt fixes two refcounting bugs in codecs.c. speedtest.py is a little test script, that checks to speed of various string/encoding/error combinations. ---------------------------------------------------------------------- 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=432401&group_id=5470 From noreply@sourceforge.net Mon Sep 2 15:14:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 07:14:31 -0700 Subject: [Patches] [ python-Patches-544740 ] test_commands test fails under Cygwin Message-ID: Patches item #544740, was opened at 2002-04-16 18:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: test_commands test fails under Cygwin Initial Comment: The Python 2.2.1 test_commands regression test fails under Cygwin 1.3.10 because the regular expression is pickier now and because Cygwin can have spaces in user and/or group names. See the following for some more details: http://cygwin.com/ml/cygwin/2002-04/msg00774.html and a workaround. I'm submitting this as a bug report instead of a patch because I don't know the best way to fix this issue. Can test_commands use numeric IDs instead of names? Should I discuss this issue on python-dev instead of here? BTW, please add a "Test" category to the available choices for Bugs. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 16:14 Message: Logged In: YES user_id=21627 This patch won't work in other locales. E.g. in de_DE, a date might read Mär 21 01:14 which won't match your regexp. Furthermore, recent GNU fileutils format it as 2002-09-02 10:12 in non-C locales, which is even further away. In theory, putting LC_ALL=C into the environment should solve this, but it would be better to not rely on the date formatting. Why do you have to put an explicit format string for the date in there? What specific change made the expression "pickier"? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-08-27 20:12 Message: Logged In: YES user_id=86216 Attached is a patch to fix this problem. As suggested by Guido, I am proposing a "better" regular expression. Unfortunately, I had to make an assumption on the date format in order to match the user and group names regardless of the number of embedded spaces. Is my date regular expression acceptable? Will it work in non US locales? FWIW, I tested under Cygwin and Red Hat Linux 7.1 without any ill effects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 17:48 Message: Logged In: YES user_id=33168 Jason, I presume this is still a problem. It probably would be a good idea to discuss on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 From noreply@sourceforge.net Mon Sep 2 16:10:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 08:10:39 -0700 Subject: [Patches] [ python-Patches-603548 ] Python object refcount accessors Message-ID: Patches item #603548, was opened at 2002-09-02 15:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603548&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rolf Kalbermatter (labviewer) Assigned to: Nobody/Anonymous (nobody) Summary: Python object refcount accessors Initial Comment: It could be useful for more generic clients of the Python core to not have to worry about the actual layout of Py_ObjectHEAD and other things. So I propose to add the two additional functions: int PyObject_IncRef(PyObject *ob) int PyObject_DecRef(PyObject *ob) Those functions could also be added to the Python 2.2 if any bug fix might be pending for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603548&group_id=5470 From noreply@sourceforge.net Mon Sep 2 16:33:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 08:33:27 -0700 Subject: [Patches] [ python-Patches-603548 ] Python object refcount accessors Message-ID: Patches item #603548, was opened at 2002-09-02 11:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603548&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rolf Kalbermatter (labviewer) Assigned to: Nobody/Anonymous (nobody) Summary: Python object refcount accessors Initial Comment: It could be useful for more generic clients of the Python core to not have to worry about the actual layout of Py_ObjectHEAD and other things. So I propose to add the two additional functions: int PyObject_IncRef(PyObject *ob) int PyObject_DecRef(PyObject *ob) Those functions could also be added to the Python 2.2 if any bug fix might be pending for it. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-02 11:33 Message: Logged In: YES user_id=31435 What's your objection to the existing Py_INCREF() and Py_DECREF()? Or didn't you know about them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603548&group_id=5470 From noreply@sourceforge.net Mon Sep 2 20:57:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 12:57:39 -0700 Subject: [Patches] [ python-Patches-603667 ] reiter() builtin Message-ID: Patches item #603667, was opened at 2002-09-02 19:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603667&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: reiter() builtin Initial Comment: The reiter() function is similar to iter() but expects a re-iterable object as an argument. If the object is already an iterator a TypeError will be raised. Example: def f(a, b): for i in a: for j in reiter(b): do_something_with(i, j) This function will raise an error if it is passed a non-reiterable object as the second argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603667&group_id=5470 From noreply@sourceforge.net Mon Sep 2 20:59:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 12:59:38 -0700 Subject: [Patches] [ python-Patches-597907 ] Oren Tirosh's fastnames patch Message-ID: Patches item #597907, was opened at 2002-08-20 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Oren Tirosh's fastnames patch Initial Comment: Oren Tirosh had a nice patch to *really* speed up global/builtin name lookup. I'm adding it here because I don't want to lose this idea. His code and some comments are here: http://www.tothink.com/python/fastnames/ I'm uploading a new version of this patch relative to current CVS. I'm still considering whether to do this; I measure at best a 1% speedup for pystone. For a modified version of Oren's benchmark (modified to use a function instead of a class for 'builtin' and 'global', so that these tests use LOAD_GLOBAL rather than LOAD_NAME, I get these test results (best of 3): builtin 1.38 global 1.54 local 1.28 fastlocal 0.90 Python 2.3 without his patch (but with my speedup hacks in LOAD_GLOBAL): builtin 1.80 global 1.52 local 1.77 fastlocal 0.91 Python 2.2 (from the 2.2 branch, which is newer than the 2.2.1 release but doesn't have any speedups) did this: builtin 2.28 global 1.86 local 1.80 fastlocal 1.10 I don't care about the speedup for the 'local' case, since this uses the LOAD_NAME opcode which is only used inside class definitions; the 'builtin' and 'global' cases are interesting. It looks like Oren's patch gives us a nice speedup for looking up a built-in name from a function. I have to think about why looking up a global from a function is slower though... ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-02 19:59 Message: Logged In: YES user_id=562624 I'm working on an improved version. Stay tuned! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-20 19:31 Message: Logged In: YES user_id=6380 Tim explained why the 'globals' case is faster than the 'builtins' case. I used 'x' as the global to look up rather than 'hex', and it so happens that the last three bits of hash('x') and hash('MANY') are the same -- MANY is an identifier I insert in the globals. I'll attach the test suite I used (with 'hex' instead of 'x'). Now I get these times: builtin 1.39 global 1.28 local 1.29 fastlocal 0.91 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 From noreply@sourceforge.net Mon Sep 2 21:19:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 13:19:47 -0700 Subject: [Patches] [ python-Patches-603667 ] reiter() builtin Message-ID: Patches item #603667, was opened at 2002-09-02 19:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603667&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: reiter() builtin Initial Comment: The reiter() function is similar to iter() but expects a re-iterable object as an argument. If the object is already an iterator a TypeError will be raised. Example: def f(a, b): for i in a: for j in reiter(b): do_something_with(i, j) This function will raise an error if it is passed a non-reiterable object as the second argument. ---------------------------------------------------------------------- >Comment By: Oren Tirosh (orenti) Date: 2002-09-02 20:19 Message: Logged In: YES user_id=562624 Correction. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603667&group_id=5470 From noreply@sourceforge.net Tue Sep 3 06:03:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Sep 2002 22:03:41 -0700 Subject: [Patches] [ python-Patches-603831 ] ccompiler argument checking too strict Message-ID: Patches item #603831, was opened at 2002-09-03 05:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603831&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Moshe Zadka (moshez) Assigned to: A.M. Kuchling (akuchling) Summary: ccompiler argument checking too strict Initial Comment: ccompiler's argument checking prevents the check_header functionality. The patch found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=159288&repeatmerged=yes is a workaround -- there are possibly better workarounds, but this one is easy and works. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603831&group_id=5470 From noreply@sourceforge.net Tue Sep 3 14:26:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 06:26:28 -0700 Subject: [Patches] [ python-Patches-601456 ] expose PYTHON_API_VERSION via sys Message-ID: Patches item #601456, was opened at 2002-08-28 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601456&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: expose PYTHON_API_VERSION via sys Initial Comment: I was scratching my head today about some API version mismatches I got from the VTK Python wrappers. Apparently, somewhere along the way the VTK build process used two different versions of the Python compilation environment to build different extension modules. From a debugging standpoint it seems like it would be a mild convenience to expose PYTHON_API_VERSION via the sys module. The attached trivial patch does this. This should be easily portable to the 2.1 and 2.2 maintenance branches though it's not strictly a bugfix. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-03 08:26 Message: Logged In: YES user_id=44345 checked in as Python/sysmodule.c 2.108, Doc/lib/libsys.tex 1.60 and Misc/NEWS 1.477 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 01:30 Message: Logged In: YES user_id=21627 There is no documentation change: you'll need to edit libsys.tex (using \versionadded), and Misc/NEWS. Apart from that, the patch is fine; please apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601456&group_id=5470 From noreply@sourceforge.net Tue Sep 3 17:41:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 09:41:37 -0700 Subject: [Patches] [ python-Patches-603548 ] Python object refcount accessors Message-ID: Patches item #603548, was opened at 2002-09-02 15:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603548&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rolf Kalbermatter (labviewer) Assigned to: Nobody/Anonymous (nobody) Summary: Python object refcount accessors Initial Comment: It could be useful for more generic clients of the Python core to not have to worry about the actual layout of Py_ObjectHEAD and other things. So I propose to add the two additional functions: int PyObject_IncRef(PyObject *ob) int PyObject_DecRef(PyObject *ob) Those functions could also be added to the Python 2.2 if any bug fix might be pending for it. ---------------------------------------------------------------------- >Comment By: Rolf Kalbermatter (labviewer) Date: 2002-09-03 16:41 Message: Logged In: YES user_id=66382 I do not object the existing macros and in absence of those proposed functions use them now, but they create unneccessary dependencies on the used Python core DLL by accessing data members of the Py_ObjectHEAD structure directly. This is especially a problem since the offset of those members changes depending if the DLL is compiled in DEBUG or non-DEBUG mode and therefore requires the client to be compiled exactly the same. Also they access additional Python data references in DEBUG mode. In my case I wanted to embed Python in another application and since I only use Python core DLL functions, I thought I would allow configuration of the Python DLL to use and load it dynamically with LoadLibrary() and access the functions with GetProcAddress(). Although this works already fine the implicit access to PyObject structure members limits the flexibility seriously. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-02 15:33 Message: Logged In: YES user_id=31435 What's your objection to the existing Py_INCREF() and Py_DECREF()? Or didn't you know about them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603548&group_id=5470 From noreply@sourceforge.net Tue Sep 3 17:53:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 09:53:49 -0700 Subject: [Patches] [ python-Patches-600488 ] Robustness tweak to httplib.py Message-ID: Patches item #600488, was opened at 2002-08-26 17:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600488&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Emerson (tree) >Assigned to: Jeremy Hylton (jhylton) Summary: Robustness tweak to httplib.py Initial Comment: Python 2.2.1, FreeBSD 4.4-STABLE httplib.py raises UnknownTransferEncoding if the HTTP response's Transfer-Encoding header is anything except 'chunked'. Some servers return completely bogus values in this header for otherwise valid results. This patch causes unknown (i.e., non-chunked) transfer encodings to be ignored. This appears to be the behavior of most user-agents I've looked at. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 12:53 Message: Logged In: YES user_id=6380 Jeremy, this looks simple enough to check it in. Do you see any reason why I shouldn't? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600488&group_id=5470 From noreply@sourceforge.net Tue Sep 3 18:52:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 10:52:36 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 22:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 13:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 15:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 18:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 16:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 17:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 23:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 05:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 18:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 13:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 23:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:02:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:02:14 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 22:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 14:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 13:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 15:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 18:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 16:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 17:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 23:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 05:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 18:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 13:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 23:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:03:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:03:08 -0700 Subject: [Patches] [ python-Patches-474274 ] Pure Python strptime() (PEP 42) Message-ID: Patches item #474274, was opened at 2001-10-23 19:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) 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-08-26 16:20 Message: Logged In: YES user_id=357491 OK, all patched and attached to the other patch entry. I also discovered a bug in PyUnit and got to submit a patch for that to its patch DB. Such fun. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 23:15 Message: Logged In: YES user_id=357491 Yep, I will patch it. I will add it to patch 593560 which has my last bugfix and code cleanup in it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-23 16:09 Message: Logged In: YES user_id=6380 Reopening to address Jason's bug report. Brett, can you provide a patch? ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2002-08-23 16:06 Message: Logged In: YES user_id=599869 _strptime still doesn't handle case correctly. Although it matches case-insensitive, the lookups for month names are still case sensitive (since they must match exactly the month names returned by time.strftime). Allow me to demonstrate below. >>> import _strptime as strptime >>> strptime.strptime( 'Aug', '%b' ) (-1, 8, -1, -1, -1, -1, -1, -1, -1) >>> strptime.strptime( 'AUG', '%b' ) Traceback (most recent call last): File "", line 1, in ? File "C:\Program Files\Python\Lib\site- packages\strptime.py", line 410, in strptime month = locale_time.a_month.index(found_dict['b']) ValueError: list.index(x): x not in list The same result is encountered using any variation of 'aug' other than 'Aug'. I imagine the solution to this problem is as simple as changing lines 408, 410, 430, and 432 to something like: month = locale_time.a_month.index(capwords(found_dict ['b'])) and adding from string import capwords to the header of the file. This is what I did in strptime v2.0.0 and the latest v2.1.5, and it has worked well. As a general note, I believe the test suite should also test for cases not automatically generated. Many of the parse routines are going to be parsing times generated by systems other than time.strftime, to include variants such as the aforementioned case variant and other things like miscellaneous interspersed strings. I will only suggest these changes, not implement them myself on this page, as I'm not intimately familiar with sourceforge or code customs, so I'll allow someone such as Guido or Brett to make the changes. Regards, Jason ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-19 13:09 Message: Logged In: YES user_id=6380 Thanks! All checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-18 20:43 Message: Logged In: YES user_id=33168 Brett, I'm still following. It wasn't that bad. :-) Guido, let me know if you want me to do anything/check stuff in. Docs are fine to upload here. I can change PEP 42 also. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-18 19:35 Message: Logged In: YES user_id=357491 Since I had the time, I went ahead and did a patch for libtime.tex that removes the comment saying that strptime fully relies on the C library and uploaded it. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-18 18:34 Message: Logged In: YES user_id=357491 Wonderful! About the docs; do you want me to email Fred or upload a patched version of the docs for time fixed? And for removing the request in PEP 42, should I email Jeremy about it or Barry? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-18 17:47 Message: Logged In: YES user_id=6380 OK, deleting all old files as promised. All tests succeed. I think I'll check this version in (but it may be tomorrow, since I've got a few other things to take care of). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-18 17:39 Message: Logged In: YES user_id=357491 God I wish I could delete those old files! Poor Neal Norwitz was nice enough to go over my code once to help me make it sure it was up for being included in the stdlib, but he initially used an old version. Thankfully he was nice enough to look over the newer version at the time. But no, SF does not give me the priveleges to delete old files (and why is that? I am the creator of the patch; you would think I could manage my own files). I re-uploaded everything now. All files that specify they were uploaded 2002-07-17 are the newest files. I am terribly sorry about this whole name mix-up. I have now fixed test_strptime.py to use _strptime. I completely removed the strptime import so that the strptime testing will go through time and thus test which ever version time will export. I removed the __future__ import. And thanks for the piece of advice; I was taking the advice that __future__ statements should come before code a little too far. =) As for your error, that is because the test_strptime.py you are using is old. I originally had a test in there that checked to make sure the regex returned was the same as the one being tested for; that was a bad decision. So I went through and removed all hard-coded tests like that. Unfortunately the version you ran still had that test in there. SF should really let patch creators delete old files. That's it this time. Now I await the next drama in this never-ending saga of trying to make a non-trivial contribution to Python. =) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-18 11:29 Message: Logged In: YES user_id=6380 - Can you please delete all the obsolete uploads? (If SF won't let you, let me know and I'll do it for you, leaving only the most recend version of each.) - There' still a confusion between strptime.py and _strptime.py; your test_time.py imports strptime, and so does the latest version of test_strptime.py I can find. - The "from __future__ import division" is unnecessary, since you're never using the single / operator (// doesn't need the future statement). Also note that future statements should come *after* a module's docstring (for future reference :-). - When I run test_strptime.py, I get one failure: ====================================================================== FAIL: Test TimeRE.pattern. ---------------------------------------------------------------------- Traceback (most recent call last): File "../Lib/test/test_strptime.py", line 124, in test_pattern self.failUnless(pattern_string.find("(?P(3[0-1])|([0-2]\d)|\d|( \d))") != -1, "did not find 'd' directive pattern string '%s'" % pattern_string) File "/home/guido/python/dist/src/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError: did not find 'd' directive pattern string '(?P(?:Mon)|(?:Tue)|(?:Wed)|(?:Thu)|(?:Fri)|(?:Sat)|(?:Sun))\s*(?P(?:Wednesday)|(?:Thursday)|(?:Saturday)|(?:Tuesday)|(?:Monday)|(?:Friday)|(?:Sunday))\s*(?P3[0-1]|[0-2]\d|\d| \d)' ---------------------------------------------------------------------- I haven't looked into this deeper. Back to you... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-16 17:34 Message: Logged In: YES user_id=357491 Two things have been uploaded. First, test_time.py w/ a strptime test. It is almost an exact mirror of the strftime test; only difference is that I used strftime to test strptime. So if strftime ever fails, strptime will fail also. I feel this is fine since strptime depends on strftime so much that if strftime were to fail strptime would definitely fail. The other file is version 2.1.5 of strptime. I made two changes. One was to remove the TypeError raised when %I was used without %p. This was from me being very picky about only accepting good data strings. The second was to go through and replace all whitespace in the format string with \s*. That basically makes this version of strptime XPG compatible as far as I (and the NetBSD man page) can tell. The only difference now is that I do not require whitespace or a non-alphanumeric character between format strings. Seems like a ridiculous requirement since the requirement that whitespace be able to compress down to no whitespace negates this requirement. Oh well, we are more than compliant now. I decided not to write a patch for the docs to make them read more leniently for what the format directives. Figured I would just let people who think like me do it in a more "proper" way with leading zeros and those who don't read it like that to still be okay. I think that is everything. If you want more in-depth tests, Guido, I can add them to the testing suite, but I figured that since this is (hopefully) going in bug-free it needs only be checked to make sure it isn't broken by anything. And if you do want more in-depth tests, do you want me to add mirror tests for strftime or not worry about that since that is the ANSI C library's problem? Other then that, I think strptime is pretty much done. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-12 18:27 Message: Logged In: YES user_id=357491 Uploaded 2.1.4. I added \d to the end of all relevant regexes (basically all of them but %y and %Y) to deal with non-zero-leading numbers. I also made the regex case-insensitive. As for the diff failing, I am wondering if I am doing something wrong. I am just running diff -c CVS_file modified_file > diff_file . Isn't that right? I will work on merging my strptime tests into the time regression tests and upload a patch here. I will do a patch for the docs since it is not consistent with the explanation of struct_time (or at least in my opinion). I tried finding XPG docs, but the best Google came up with was the NetBSD man pages for strptime (which they claim is XPG compliant). The difference between that implementation and mine is that NetBSD's allows whitespace (defined as isspace()) in the format string to match \s* in the data string. It also requires a whitespace or a non-alphanumeric character while my implementation does not require that. Personally, I don't like either difference. If they were used, though, there might be a possibility of rewriting strptime to just use a bunch of string methods instead of regexes for a possible performance benefit. But I prefer regexes since it adds checks of the input. That and I just like regexes period. =) Also, I noticed that your little test returned 0 for all unknown values. Mine returns -1 since 0 can be a legitimate value for some and I figured that would eliminate ambiguity. I can change it to 0, though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 17:13 Message: Logged In: YES user_id=6380 Hm, the new diff_time *still* fails to apply. But don't worry about that. I'd love to see regression tests for time.strptime. Please upload them here -- don't start a new patch. I think your interpretation of the docs is overly restrictive; the table shows what strftime does but I think it's reasonable for strptime to accept missing leading zeros. You can upload a patch for the docs too if you feel that's necessary. You may also try to read up on what the XPG standard says about strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-12 17:02 Message: Logged In: YES user_id=357491 To respond to your points, Guido: (a) I accidentally uploaded the old file. Sorry about that. I misnamed the new one 'time_diff" but in my head I meant to overwrite "diff_time". I have uploaded the new one. (b) See (a) (c) Oops. That is a complete oversight on my part. Now in (d) you mention writing up regression tests for the standard time.strptime. I am quite hapy to do this. Do you want that as a separate patch? If so I will just stop with uploading tests here and just start a patch with my strptime tests for the stdlib tests. (d) The reason this test failed is because your input is not compliant with the Python docs. Read what %m accepts: Month as a decimal number [01,12] Notice the leading 0 for the single digit month. My implementation follows the docs and not what glibc suggests. If you want, I can obviously add on to all the regexes \d as an option and eliminate this issue. But that means it will no longer be following the docs. This tripped Skip up too since no one writes numbers that way; strftime does, though. Now if the docs meant for no trailing 0, I think they should be rewritten since that is misleading. In other words, either strptime stays as it is and follows the docs or I change the regexes, but then the docs will have to be changed. I can go either way, but I personally would want to follow the docs as-is since strptime is meant to parse strftime output and not human output. =) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 12:58 Message: Logged In: YES user_id=6380 Hm. This isn't done yet. I get these problems: (a) the patch for timemodule.c doesn't apply cleanly in current CVS (trivial) (b) it still tries to import strptime (no leading '_') (also trivial) (c) so does test_strptime.py (also trivial) (d) the simplest of simple examples fails: With Linux's strptime: >>> time.strptime("7/12/02", "%m/%d/%y") (2002, 7, 12, 0, 0, 0, 4, 193, 0) >>> With yours: >>> time.strptime("7/12/02", "%m/%d/%y") Traceback (most recent call last): File "", line 1, in ? File "/home/guido/python/dist/src/Lib/_strptime.py", line 392, in strptime raise ValueError("time data did not match format") ValueError: time data did not match format >>> Perhaps you should write a regression test suite for the strptime function as found in the time module courtesy of libc, and then make sure that your code satisfies it? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-10 16:51 Message: Logged In: YES user_id=357491 The actual 2.1.3 edition of strptime is now up. I don't think there are any changes, but since I renamed the file _strptime.py, I figured uploading it again wouldn't hurt. I also uploaded a new contextual diff of the time module taken from CVS on 2002-07-10. The only difference between this and the previous diff (which was against 2.2.1's time module) is the change of the imported module to _strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-27 00:54 Message: Logged In: YES user_id=357491 Uploaded 2.1.2 (but accidentally labelled it 2.1.3 down below!). Just a little bit more cleanup. Biggest change is that I changed the default format string and made strptime() raise ValueError instead of TypeError. This was all done to match the time module docs. I also fiddled with the regexes so that the groups were none-capturing. Mainly done for a possible performance improvement. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-23 21:06 Message: Logged In: YES user_id=357491 2.1.1 is now uploaded. Almost a purely syntatical change. >From discussions on python-dev I renamed the helper fxns so they are all lowercase-style. Also changed them so that they state what the fxn returns. I also put all of the imports on their own line as per PEP 8. The only semantical change I did was directly import re.compile since it is the only thing I am using from the re module. These changes required tweaking of my exhaustive testing suite, so that got uploaded, too. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-21 00:35 Message: Logged In: YES user_id=357491 I have uploaded a contextual diff of timemodule.c with a callout to strptime.strptime when HAVE_STRPTIME is not defined just as Guido requested. It's my first extension module, so I am not totally sure of myself with it. But since Alex Marttelli told me what I needed to do I am fairly certain it is correct. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-19 17:49 Message: Logged In: YES user_id=357491 2.1.0 is now up and ready for use. I only changed two things to the code, but since they change the semantics of stprtime()s use, I made this a new minor release. One, I removed the ability to pass in your own LocaleTime object. I did this for two reasons. One is because I forgot about how default arguments are created at the time of function creation and not at each fxn call. This meant that if someone was not thinking and ran strptime() under one locale and then switched to another locale without explicitly passing in a new LocaleTime object for every call for the new locale, they would get bad matches. That is not good. The other reason was that I don't want to force users to pass in a LocaleTime object on every call if I can't have a default value for it. This is meant to act as a drop-in replacement for time.strptime(). That forced the removal of the parameter since it can't have a default value. In retrospect, though, people will probably never parse log files in other languages other then there default locale. And if they were, they should change the locale for the interpreter and not just for strptime(). The second change was what triggers strptime() to return an re object that it can use. Initially it was any nothing value (i.e., would be considered false), but I realized that an empty string could trigger that and it would be better to raise a TypeError then let some error come up from trying to use the re object in an incorrect way. Now, to have an re object returned, you pass in False. I figured that there is a very minimal chance of passing in False when you meant to pass in a string. Also, False as the data_string, to me, means that I don't want what would normally be returned. I debated about removing this feature from strptime(), but I profiled it and most of the time comes from TimeRE's __getitem__. So building the string to be compiled into a regex is the big bottleneck. Using a precompiled regex instead of constructing a new one everytime took 25% of the time overall for strptime() when calling strptime() 10,000 times in a row. This is a conservative number, IMO, for calls in a row; I checked the Apache hit logs for a single day on Open Computing Facility's web server (http://www.ocf.berkeley.edu/) and there were 188,562 hits on June 16 alone. So I am going to keep the feature until someone tells me otherwise. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-18 15:05 Message: Logged In: YES user_id=357491 I have uploaded v. 2.0.4. It now uses the calendar module to figure out the names of weekdays and months. Thanks goes out to Guido for pointing out this undocumented feature of calendar. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-17 16:11 Message: Logged In: YES user_id=357491 I uploaded v.2.0.3. Beyond implementing what I mentioned previously (raising TypeError when a match fails, adding \d to all applicable regexes) I did a few more things. For one, I added a special " \d" to the numeric month regex. I discovered that ANSI C for ctime displays the month with a leading space if it is a single digit. So to deal with that since at least Skip's C library likes to use that format for %c, I went ahead and added it. I changed all attributes in LocaleTime to lists. A recent mail on python-dev from GvR said that lists are for homogeneous data, which everything that is grouped together in LocaleTime is. It also simplified the code slightly and led to less conversions of data types. I also added a method that raises a TypeError if you try to assign to any of LocaleTime's attributes. I thought that if you left out the set value for property() it wouldn't work; didn't realize it just defaults over to __setitem__. So I added that method as the set value for all of the property()s. It does require 2.2.1 now since I used True and False without defining them. Obviously just set those values to 1 and 0 respectively if you are running under 2.2 I also updated the overly exhaustive PyUnit suite that I have for testing my code. It is not black-box testing, though; Skip's pruned version of my testing suite fits that bill (I think). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-12 20:46 Message: Logged In: YES user_id=357491 I am back from my vacation and ready to email python- dev about getting this patch accepted (whether to modify time or make this a separate module, etc.). I think I will do the email on June 17. Before then, though, I am going to make two changes. One is the raise a Value Error exception if the regex doesn't match (to try to match time.strptime()s exception as seen in Skip's run of the unit test). The other change is to tack on a \d on all numeric formats where it might come out as a single digit (i.e., lacking a leading zero). This will be for v2.0.3 which I will post before June 17. If there is any reason anyone thinks I should hold back on this, please let me know! I would like to have this code as done as possible before I make any announcement. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-05 02:32 Message: Logged In: YES user_id=357491 I went ahead an implemented most of Neal's suggestions. On a few, of them, though, I either didn't do it or took a slightly different route. For the 'yY' vs. ('y', 'Y'), I went with 'yY'. If it gives a performance boost, why not since it doesn't make the code harder to read. Implementing it actually had me catch some redundant code for dealing with a literal %. The tests in the __init__ for LocaleTime have been reworked to check that they are either None or have the proper length, otherwise they raise a TypeError. I have gone through and tried to catch all the lines that were over 80 characters and cut them up to fit. For the adding of '' to tuples, I created a method that could specify front or back concatination. Not much different from before, but it allows me to specify front or back concatination easily. I explained why the various magic dates were used. I in no way have to worry about leap year. Since it is not validating the data string for validity the fxn just takes the data and uses it. I have no reason to calc for leap year. date_time[offset] has been replaced with current_format and added the requisite two lines to assign between it and the list. You are only supposed to use __new__ when it is immutable. Since dict is obviously mutable, I don't need to worry about it. Used Neal's suggested shortening of the sorter helper fxn. I also used the suggestion of doing x = y = z = -1. Now it barely fits on a single line instead of two. All numerical compares use == and != instead of is and is not. Didn't know about that dependency on NSMALL((POS)|(NEG))INTS; good thing to know. The doc string was backwards. Thanks for catching that, Neal. I also went through and added True and False where appropriate. There is a line in the code where True = 1; False = 0 right at the top. That can obviously be removed if being run under Python 2.3. And I completely understand being picky about minute details where maintainability is a concern. I just graduated from Cal and so the memory of seeing beginning programmers' code is still fresh in my mind . And I will query python-dev about how to go about to get this added after the bugs are fixed and I am back home (going to be out of town until June 16). I will still be periodically checking email, though, so I will continue to implement any suggestions/bugfixes that anyone suggests/finds. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-04 19:33 Message: Logged In: YES user_id=33168 Hopefully, I'm looking at the correct patch this time. :-) To answer one question you had (re: 'yY' vs. ('y', 'Y')), I'm not sure people really care. It's not big to me. Although 'yY' is faster than ('y', 'Y'). In order to try to reduce the lines where you raise an error (in __init__) you could change 'sequence of ... must be X items long' to '... must have/contain X items'. Generally, it would be nice to make sure none of the lines are over 72-79 chars (see PEP 8). Instead of doing: newlist = list(orig) newlist.append('') x = tuple(newlist) you could do: x = tuple(orig[:]) or something like that. Perhaps a helper function? In __init__ do you want to check the params against 'is None' If someone passes a non-sequence that doesn't evaluate to False, the __init__ won't raise a TypeError which it probably should. What is the magic date used in __calc_weekday()? (1999/3/15+ 22:44:55) is this significant, should there be a comment? (magic dates are used elsewhere too, e.g., __calc_month, __calc_am_pm, many more) __calc_month() doesn't seem to take leap year into account? (not sure if this is a problem or not) In __calc_date_time(), you use date_time[offset] repetatively, couldn't you start the loop with something like dto = date_time[offset] and then use dto (dto is not a good name, I'm just making an example) Are you supposed to use __init__ when deriving from built-ins (TimeRE(dict)) or __new__? (sorry, I don't remember the answer) In __tupleToRE.sorter(), instead of the last 3 lines, you can do: return cmp(b_length, a_length) Note: you can do x = y = z = -1, instead of x = -1 ; y = -1 ; z = -1 It could be problematic to compare x is -1. You should probably just use ==. It would be a problem if NSMALLPOSINTS or NSMALLNEGINTS were not defined in Objects/intobject.c. This docstring seems backwards: def gregToJulian(year, month, day): """Calculate the Gregorian date from the Julian date.""" I know a lot of these things seem like a pain. And it's not that bad now, but the problem is maintaining the code. It will be easier for everyone else if the code is similar to the rest. BTW, protocol on python-dev is pretty loose and friendly. :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-04 18:33 Message: Logged In: YES user_id=357491 Thanks for being so prompt with your response, Skip. I found the problem with your %c. If you look at your output you will notice that the day of the month is '4', but if you look at the docs for time.strftime() you will notice that is specifies the day of the month (%d) as being in the range [01,31]. The regex for %d (simplified) is '(3[0-1])|([0-2]\d)'; not being represented by 2 digits caused the regex to fail. Now the question becomes do we follow the spec and chaulk this up to a non-standard strftime() implementation, or do we adapt strptime to deal with possible improper output from strftime()? Changing the regexes should not be a big issue since I could just tack on '\d' as the last option for all numerical regexes. As for the test error from time.strptime(), I don't know what is causing it. If you look at the test you will notice that all it basically does is parsetime(time.strftime("%Z"), "%Z"). Now how that can fail I don't know. The docs do say that strptime() tends to be buggy, so perhaps this is a case of this. One last thing. Should I wait until the bugs are worked out before I post to python-dev asking to either add this as a module to the standard library or change time to a Python stub and rename timemodule.c? Should I ask now to get the ball rolling? Since I just joined python-dev literally this morning I don't know what the protocol is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-04 01:55 Message: Logged In: YES user_id=44345 Here ya go... % ./python Python 2.3a0 (#185, Jun 1 2002, 23:19:40) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime(time.time()) >>> now (2002, 6, 4, 0, 53, 39, 1, 155, 1) >>> time.strftime("%c", now) 'Tue Jun 4 00:53:39 2002' >>> time.tzname ('CST', 'CDT') >>> time.strftime("%Z", now) 'CDT' ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-04 01:35 Message: Logged In: YES user_id=357491 I have uploaded a verision 2.0.1 which fixes the %b format bug (stupid typo on a variable name). As for the %c directive, I pass that test. Can you please send the output of strftime and the time tuple used to generate it? As for the time.strptime() failure, I don't have time.strptime() on any system available to me, so could you please send me the output you have for strftime('%Z'), and time.tzname? I don't know how much %Z should be worried about since its use is deprecated (according to the time module's documentation). Perhaps strptime() should take the initiative and not support it? -Brett ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-04 00:52 Message: Logged In: YES user_id=44345 Brett, Please see the drastically shortened test_strptime.py. (Basically all I'm interested in here is whether or not strptime.strptime and time.strptime will pass the tests.) Near the top are two lines, one commented out: parsetime = time.strptime #parsetime = strptime.strptime Regardless which version of parsetime I get, I get some errors. If parsetime == time.strptime I get ====================================================================== ERROR: Test timezone directives. ---------------------------------------------------------------------- Traceback (most recent call last): File "test_strptime.py", line 69, in test_timezone strp_output = parsetime(strf_output, "%Z") ValueError: unconverted data remains: 'CDT' If parsetime == strptime.strptime I get ERROR: *** Test %c directive. *** ---------------------------------------------------------------------- Traceback (most recent call last): File "test_strptime.py", line 75, in test_date_time self.helper('c', position) File "test_strptime.py", line 17, in helper strp_output = parsetime(strf_output, '%'+directive) File "strptime.py", line 380, in strptime found_dict = found.groupdict() AttributeError: NoneType object has no attribute 'groupdict' ====================================================================== ERROR: Test for month directives. ---------------------------------------------------------------------- Traceback (most recent call last): File "test_strptime.py", line 31, in test_month self.helper(directive, 1) File "test_strptime.py", line 17, in helper strp_output = parsetime(strf_output, '%'+directive) File "strptime.py", line 393, in strptime month = list(locale_time.f_month).index(found_dict['b']) ValueError: list.index(x): x not in list This is with a very recent interpreter (updated from CVS in the past day) running on Mandrake Linux 8.1. Can you reproduce either or both problems? Got fixes for the strptime.strptime problems? Thx, Skip ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-02 03:44 Message: Logged In: YES user_id=357491 I'm afraid you looked at the wrong patch! My fault since I accidentally forgot to add a description for my patch. So the file with no description is the newest one and completely supercedes the older file. I am very sorry about that. Trust me, the new version is much better. I realized the other day that since the time module is a C extension file, would getting this accepted require getting BDFL approval to add this as a separate module into the standard library? Would the time module have to have a Python interface module where this is put and all other methods in the module just pass directly to the extension file? As for the suggestions, here are my replies to the ones that still apply to the new file: * strings are sequences, so instead of if found in ('y', 'Y') you can do if found in 'yY' -> True, but I personally find it easier to read using the tuple. If it is standard practice in the standard library to do it the suggested way, I will change it. * daylight should use the new bools True, False (this also applies to any other flags) -> Oops. Since I wrote this under Python 2.2.1 I didn't think about it. I will go through the code and look for places where True and False should be used. -Brett C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-01 09:46 Message: Logged In: YES user_id=33168 Overall, the patch looks pretty good. I didn't check for completeness or consistency, though. * You don't need: from exceptions import Exception * The comment "from strptime import * will only export strptime()" is not correct. * I'm not sure what should be included for the license. * Why do you need success flag in CheckIntegrity, you raise an exception? (You don't need to return anything, raise an exception, else it's ok) * In return_time(), could you change xrange(9) to range(len(temp_time)) this removes a dependancy. * strings are sequences, so instead of if found in ('y', 'Y') you can do if found in 'yY' * daylight should use the new bools True, False (this also applies to any other flags) * The formatting doesn't follow the standard (see PEP 8) (specifically, spaces after commas, =, binary ops, comparisons, etc) * Long lines should be broken up The test looks pretty good too. I didn't check it for completeness. The URL is wrong (too high up), the test can be found here: http://www.ocf.berkeley.edu/~bac/Askewed_Thoughts/code/Python/Scripts/test_strptime.py I noticed a spelling mistake in the test: anme -> name. Also, note that PEP 42 has a comment about a python strptime. So if this gets implemented, we need to update PEP 42. Thanks. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-05-27 17: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 18: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 18: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 17: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:03:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:03:30 -0700 Subject: [Patches] [ python-Patches-474274 ] Pure Python strptime() (PEP 42) Message-ID: Patches item #474274, was opened at 2001-10-23 19:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) 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: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 14:03 Message: Logged In: YES user_id=12800 Closing. Refer to patch 593560 for further details. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 16:20 Message: Logged In: YES user_id=357491 OK, all patched and attached to the other patch entry. I also discovered a bug in PyUnit and got to submit a patch for that to its patch DB. Such fun. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 23:15 Message: Logged In: YES user_id=357491 Yep, I will patch it. I will add it to patch 593560 which has my last bugfix and code cleanup in it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-23 16:09 Message: Logged In: YES user_id=6380 Reopening to address Jason's bug report. Brett, can you provide a patch? ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2002-08-23 16:06 Message: Logged In: YES user_id=599869 _strptime still doesn't handle case correctly. Although it matches case-insensitive, the lookups for month names are still case sensitive (since they must match exactly the month names returned by time.strftime). Allow me to demonstrate below. >>> import _strptime as strptime >>> strptime.strptime( 'Aug', '%b' ) (-1, 8, -1, -1, -1, -1, -1, -1, -1) >>> strptime.strptime( 'AUG', '%b' ) Traceback (most recent call last): File "", line 1, in ? File "C:\Program Files\Python\Lib\site- packages\strptime.py", line 410, in strptime month = locale_time.a_month.index(found_dict['b']) ValueError: list.index(x): x not in list The same result is encountered using any variation of 'aug' other than 'Aug'. I imagine the solution to this problem is as simple as changing lines 408, 410, 430, and 432 to something like: month = locale_time.a_month.index(capwords(found_dict ['b'])) and adding from string import capwords to the header of the file. This is what I did in strptime v2.0.0 and the latest v2.1.5, and it has worked well. As a general note, I believe the test suite should also test for cases not automatically generated. Many of the parse routines are going to be parsing times generated by systems other than time.strftime, to include variants such as the aforementioned case variant and other things like miscellaneous interspersed strings. I will only suggest these changes, not implement them myself on this page, as I'm not intimately familiar with sourceforge or code customs, so I'll allow someone such as Guido or Brett to make the changes. Regards, Jason ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-19 13:09 Message: Logged In: YES user_id=6380 Thanks! All checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-18 20:43 Message: Logged In: YES user_id=33168 Brett, I'm still following. It wasn't that bad. :-) Guido, let me know if you want me to do anything/check stuff in. Docs are fine to upload here. I can change PEP 42 also. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-18 19:35 Message: Logged In: YES user_id=357491 Since I had the time, I went ahead and did a patch for libtime.tex that removes the comment saying that strptime fully relies on the C library and uploaded it. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-18 18:34 Message: Logged In: YES user_id=357491 Wonderful! About the docs; do you want me to email Fred or upload a patched version of the docs for time fixed? And for removing the request in PEP 42, should I email Jeremy about it or Barry? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-18 17:47 Message: Logged In: YES user_id=6380 OK, deleting all old files as promised. All tests succeed. I think I'll check this version in (but it may be tomorrow, since I've got a few other things to take care of). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-18 17:39 Message: Logged In: YES user_id=357491 God I wish I could delete those old files! Poor Neal Norwitz was nice enough to go over my code once to help me make it sure it was up for being included in the stdlib, but he initially used an old version. Thankfully he was nice enough to look over the newer version at the time. But no, SF does not give me the priveleges to delete old files (and why is that? I am the creator of the patch; you would think I could manage my own files). I re-uploaded everything now. All files that specify they were uploaded 2002-07-17 are the newest files. I am terribly sorry about this whole name mix-up. I have now fixed test_strptime.py to use _strptime. I completely removed the strptime import so that the strptime testing will go through time and thus test which ever version time will export. I removed the __future__ import. And thanks for the piece of advice; I was taking the advice that __future__ statements should come before code a little too far. =) As for your error, that is because the test_strptime.py you are using is old. I originally had a test in there that checked to make sure the regex returned was the same as the one being tested for; that was a bad decision. So I went through and removed all hard-coded tests like that. Unfortunately the version you ran still had that test in there. SF should really let patch creators delete old files. That's it this time. Now I await the next drama in this never-ending saga of trying to make a non-trivial contribution to Python. =) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-18 11:29 Message: Logged In: YES user_id=6380 - Can you please delete all the obsolete uploads? (If SF won't let you, let me know and I'll do it for you, leaving only the most recend version of each.) - There' still a confusion between strptime.py and _strptime.py; your test_time.py imports strptime, and so does the latest version of test_strptime.py I can find. - The "from __future__ import division" is unnecessary, since you're never using the single / operator (// doesn't need the future statement). Also note that future statements should come *after* a module's docstring (for future reference :-). - When I run test_strptime.py, I get one failure: ====================================================================== FAIL: Test TimeRE.pattern. ---------------------------------------------------------------------- Traceback (most recent call last): File "../Lib/test/test_strptime.py", line 124, in test_pattern self.failUnless(pattern_string.find("(?P(3[0-1])|([0-2]\d)|\d|( \d))") != -1, "did not find 'd' directive pattern string '%s'" % pattern_string) File "/home/guido/python/dist/src/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError: did not find 'd' directive pattern string '(?P(?:Mon)|(?:Tue)|(?:Wed)|(?:Thu)|(?:Fri)|(?:Sat)|(?:Sun))\s*(?P(?:Wednesday)|(?:Thursday)|(?:Saturday)|(?:Tuesday)|(?:Monday)|(?:Friday)|(?:Sunday))\s*(?P3[0-1]|[0-2]\d|\d| \d)' ---------------------------------------------------------------------- I haven't looked into this deeper. Back to you... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-16 17:34 Message: Logged In: YES user_id=357491 Two things have been uploaded. First, test_time.py w/ a strptime test. It is almost an exact mirror of the strftime test; only difference is that I used strftime to test strptime. So if strftime ever fails, strptime will fail also. I feel this is fine since strptime depends on strftime so much that if strftime were to fail strptime would definitely fail. The other file is version 2.1.5 of strptime. I made two changes. One was to remove the TypeError raised when %I was used without %p. This was from me being very picky about only accepting good data strings. The second was to go through and replace all whitespace in the format string with \s*. That basically makes this version of strptime XPG compatible as far as I (and the NetBSD man page) can tell. The only difference now is that I do not require whitespace or a non-alphanumeric character between format strings. Seems like a ridiculous requirement since the requirement that whitespace be able to compress down to no whitespace negates this requirement. Oh well, we are more than compliant now. I decided not to write a patch for the docs to make them read more leniently for what the format directives. Figured I would just let people who think like me do it in a more "proper" way with leading zeros and those who don't read it like that to still be okay. I think that is everything. If you want more in-depth tests, Guido, I can add them to the testing suite, but I figured that since this is (hopefully) going in bug-free it needs only be checked to make sure it isn't broken by anything. And if you do want more in-depth tests, do you want me to add mirror tests for strftime or not worry about that since that is the ANSI C library's problem? Other then that, I think strptime is pretty much done. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-12 18:27 Message: Logged In: YES user_id=357491 Uploaded 2.1.4. I added \d to the end of all relevant regexes (basically all of them but %y and %Y) to deal with non-zero-leading numbers. I also made the regex case-insensitive. As for the diff failing, I am wondering if I am doing something wrong. I am just running diff -c CVS_file modified_file > diff_file . Isn't that right? I will work on merging my strptime tests into the time regression tests and upload a patch here. I will do a patch for the docs since it is not consistent with the explanation of struct_time (or at least in my opinion). I tried finding XPG docs, but the best Google came up with was the NetBSD man pages for strptime (which they claim is XPG compliant). The difference between that implementation and mine is that NetBSD's allows whitespace (defined as isspace()) in the format string to match \s* in the data string. It also requires a whitespace or a non-alphanumeric character while my implementation does not require that. Personally, I don't like either difference. If they were used, though, there might be a possibility of rewriting strptime to just use a bunch of string methods instead of regexes for a possible performance benefit. But I prefer regexes since it adds checks of the input. That and I just like regexes period. =) Also, I noticed that your little test returned 0 for all unknown values. Mine returns -1 since 0 can be a legitimate value for some and I figured that would eliminate ambiguity. I can change it to 0, though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 17:13 Message: Logged In: YES user_id=6380 Hm, the new diff_time *still* fails to apply. But don't worry about that. I'd love to see regression tests for time.strptime. Please upload them here -- don't start a new patch. I think your interpretation of the docs is overly restrictive; the table shows what strftime does but I think it's reasonable for strptime to accept missing leading zeros. You can upload a patch for the docs too if you feel that's necessary. You may also try to read up on what the XPG standard says about strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-12 17:02 Message: Logged In: YES user_id=357491 To respond to your points, Guido: (a) I accidentally uploaded the old file. Sorry about that. I misnamed the new one 'time_diff" but in my head I meant to overwrite "diff_time". I have uploaded the new one. (b) See (a) (c) Oops. That is a complete oversight on my part. Now in (d) you mention writing up regression tests for the standard time.strptime. I am quite hapy to do this. Do you want that as a separate patch? If so I will just stop with uploading tests here and just start a patch with my strptime tests for the stdlib tests. (d) The reason this test failed is because your input is not compliant with the Python docs. Read what %m accepts: Month as a decimal number [01,12] Notice the leading 0 for the single digit month. My implementation follows the docs and not what glibc suggests. If you want, I can obviously add on to all the regexes \d as an option and eliminate this issue. But that means it will no longer be following the docs. This tripped Skip up too since no one writes numbers that way; strftime does, though. Now if the docs meant for no trailing 0, I think they should be rewritten since that is misleading. In other words, either strptime stays as it is and follows the docs or I change the regexes, but then the docs will have to be changed. I can go either way, but I personally would want to follow the docs as-is since strptime is meant to parse strftime output and not human output. =) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 12:58 Message: Logged In: YES user_id=6380 Hm. This isn't done yet. I get these problems: (a) the patch for timemodule.c doesn't apply cleanly in current CVS (trivial) (b) it still tries to import strptime (no leading '_') (also trivial) (c) so does test_strptime.py (also trivial) (d) the simplest of simple examples fails: With Linux's strptime: >>> time.strptime("7/12/02", "%m/%d/%y") (2002, 7, 12, 0, 0, 0, 4, 193, 0) >>> With yours: >>> time.strptime("7/12/02", "%m/%d/%y") Traceback (most recent call last): File "", line 1, in ? File "/home/guido/python/dist/src/Lib/_strptime.py", line 392, in strptime raise ValueError("time data did not match format") ValueError: time data did not match format >>> Perhaps you should write a regression test suite for the strptime function as found in the time module courtesy of libc, and then make sure that your code satisfies it? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-10 16:51 Message: Logged In: YES user_id=357491 The actual 2.1.3 edition of strptime is now up. I don't think there are any changes, but since I renamed the file _strptime.py, I figured uploading it again wouldn't hurt. I also uploaded a new contextual diff of the time module taken from CVS on 2002-07-10. The only difference between this and the previous diff (which was against 2.2.1's time module) is the change of the imported module to _strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-27 00:54 Message: Logged In: YES user_id=357491 Uploaded 2.1.2 (but accidentally labelled it 2.1.3 down below!). Just a little bit more cleanup. Biggest change is that I changed the default format string and made strptime() raise ValueError instead of TypeError. This was all done to match the time module docs. I also fiddled with the regexes so that the groups were none-capturing. Mainly done for a possible performance improvement. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-23 21:06 Message: Logged In: YES user_id=357491 2.1.1 is now uploaded. Almost a purely syntatical change. >From discussions on python-dev I renamed the helper fxns so they are all lowercase-style. Also changed them so that they state what the fxn returns. I also put all of the imports on their own line as per PEP 8. The only semantical change I did was directly import re.compile since it is the only thing I am using from the re module. These changes required tweaking of my exhaustive testing suite, so that got uploaded, too. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-21 00:35 Message: Logged In: YES user_id=357491 I have uploaded a contextual diff of timemodule.c with a callout to strptime.strptime when HAVE_STRPTIME is not defined just as Guido requested. It's my first extension module, so I am not totally sure of myself with it. But since Alex Marttelli told me what I needed to do I am fairly certain it is correct. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-19 17:49 Message: Logged In: YES user_id=357491 2.1.0 is now up and ready for use. I only changed two things to the code, but since they change the semantics of stprtime()s use, I made this a new minor release. One, I removed the ability to pass in your own LocaleTime object. I did this for two reasons. One is because I forgot about how default arguments are created at the time of function creation and not at each fxn call. This meant that if someone was not thinking and ran strptime() under one locale and then switched to another locale without explicitly passing in a new LocaleTime object for every call for the new locale, they would get bad matches. That is not good. The other reason was that I don't want to force users to pass in a LocaleTime object on every call if I can't have a default value for it. This is meant to act as a drop-in replacement for time.strptime(). That forced the removal of the parameter since it can't have a default value. In retrospect, though, people will probably never parse log files in other languages other then there default locale. And if they were, they should change the locale for the interpreter and not just for strptime(). The second change was what triggers strptime() to return an re object that it can use. Initially it was any nothing value (i.e., would be considered false), but I realized that an empty string could trigger that and it would be better to raise a TypeError then let some error come up from trying to use the re object in an incorrect way. Now, to have an re object returned, you pass in False. I figured that there is a very minimal chance of passing in False when you meant to pass in a string. Also, False as the data_string, to me, means that I don't want what would normally be returned. I debated about removing this feature from strptime(), but I profiled it and most of the time comes from TimeRE's __getitem__. So building the string to be compiled into a regex is the big bottleneck. Using a precompiled regex instead of constructing a new one everytime took 25% of the time overall for strptime() when calling strptime() 10,000 times in a row. This is a conservative number, IMO, for calls in a row; I checked the Apache hit logs for a single day on Open Computing Facility's web server (http://www.ocf.berkeley.edu/) and there were 188,562 hits on June 16 alone. So I am going to keep the feature until someone tells me otherwise. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-18 15:05 Message: Logged In: YES user_id=357491 I have uploaded v. 2.0.4. It now uses the calendar module to figure out the names of weekdays and months. Thanks goes out to Guido for pointing out this undocumented feature of calendar. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-17 16:11 Message: Logged In: YES user_id=357491 I uploaded v.2.0.3. Beyond implementing what I mentioned previously (raising TypeError when a match fails, adding \d to all applicable regexes) I did a few more things. For one, I added a special " \d" to the numeric month regex. I discovered that ANSI C for ctime displays the month with a leading space if it is a single digit. So to deal with that since at least Skip's C library likes to use that format for %c, I went ahead and added it. I changed all attributes in LocaleTime to lists. A recent mail on python-dev from GvR said that lists are for homogeneous data, which everything that is grouped together in LocaleTime is. It also simplified the code slightly and led to less conversions of data types. I also added a method that raises a TypeError if you try to assign to any of LocaleTime's attributes. I thought that if you left out the set value for property() it wouldn't work; didn't realize it just defaults over to __setitem__. So I added that method as the set value for all of the property()s. It does require 2.2.1 now since I used True and False without defining them. Obviously just set those values to 1 and 0 respectively if you are running under 2.2 I also updated the overly exhaustive PyUnit suite that I have for testing my code. It is not black-box testing, though; Skip's pruned version of my testing suite fits that bill (I think). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-12 20:46 Message: Logged In: YES user_id=357491 I am back from my vacation and ready to email python- dev about getting this patch accepted (whether to modify time or make this a separate module, etc.). I think I will do the email on June 17. Before then, though, I am going to make two changes. One is the raise a Value Error exception if the regex doesn't match (to try to match time.strptime()s exception as seen in Skip's run of the unit test). The other change is to tack on a \d on all numeric formats where it might come out as a single digit (i.e., lacking a leading zero). This will be for v2.0.3 which I will post before June 17. If there is any reason anyone thinks I should hold back on this, please let me know! I would like to have this code as done as possible before I make any announcement. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-05 02:32 Message: Logged In: YES user_id=357491 I went ahead an implemented most of Neal's suggestions. On a few, of them, though, I either didn't do it or took a slightly different route. For the 'yY' vs. ('y', 'Y'), I went with 'yY'. If it gives a performance boost, why not since it doesn't make the code harder to read. Implementing it actually had me catch some redundant code for dealing with a literal %. The tests in the __init__ for LocaleTime have been reworked to check that they are either None or have the proper length, otherwise they raise a TypeError. I have gone through and tried to catch all the lines that were over 80 characters and cut them up to fit. For the adding of '' to tuples, I created a method that could specify front or back concatination. Not much different from before, but it allows me to specify front or back concatination easily. I explained why the various magic dates were used. I in no way have to worry about leap year. Since it is not validating the data string for validity the fxn just takes the data and uses it. I have no reason to calc for leap year. date_time[offset] has been replaced with current_format and added the requisite two lines to assign between it and the list. You are only supposed to use __new__ when it is immutable. Since dict is obviously mutable, I don't need to worry about it. Used Neal's suggested shortening of the sorter helper fxn. I also used the suggestion of doing x = y = z = -1. Now it barely fits on a single line instead of two. All numerical compares use == and != instead of is and is not. Didn't know about that dependency on NSMALL((POS)|(NEG))INTS; good thing to know. The doc string was backwards. Thanks for catching that, Neal. I also went through and added True and False where appropriate. There is a line in the code where True = 1; False = 0 right at the top. That can obviously be removed if being run under Python 2.3. And I completely understand being picky about minute details where maintainability is a concern. I just graduated from Cal and so the memory of seeing beginning programmers' code is still fresh in my mind . And I will query python-dev about how to go about to get this added after the bugs are fixed and I am back home (going to be out of town until June 16). I will still be periodically checking email, though, so I will continue to implement any suggestions/bugfixes that anyone suggests/finds. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-04 19:33 Message: Logged In: YES user_id=33168 Hopefully, I'm looking at the correct patch this time. :-) To answer one question you had (re: 'yY' vs. ('y', 'Y')), I'm not sure people really care. It's not big to me. Although 'yY' is faster than ('y', 'Y'). In order to try to reduce the lines where you raise an error (in __init__) you could change 'sequence of ... must be X items long' to '... must have/contain X items'. Generally, it would be nice to make sure none of the lines are over 72-79 chars (see PEP 8). Instead of doing: newlist = list(orig) newlist.append('') x = tuple(newlist) you could do: x = tuple(orig[:]) or something like that. Perhaps a helper function? In __init__ do you want to check the params against 'is None' If someone passes a non-sequence that doesn't evaluate to False, the __init__ won't raise a TypeError which it probably should. What is the magic date used in __calc_weekday()? (1999/3/15+ 22:44:55) is this significant, should there be a comment? (magic dates are used elsewhere too, e.g., __calc_month, __calc_am_pm, many more) __calc_month() doesn't seem to take leap year into account? (not sure if this is a problem or not) In __calc_date_time(), you use date_time[offset] repetatively, couldn't you start the loop with something like dto = date_time[offset] and then use dto (dto is not a good name, I'm just making an example) Are you supposed to use __init__ when deriving from built-ins (TimeRE(dict)) or __new__? (sorry, I don't remember the answer) In __tupleToRE.sorter(), instead of the last 3 lines, you can do: return cmp(b_length, a_length) Note: you can do x = y = z = -1, instead of x = -1 ; y = -1 ; z = -1 It could be problematic to compare x is -1. You should probably just use ==. It would be a problem if NSMALLPOSINTS or NSMALLNEGINTS were not defined in Objects/intobject.c. This docstring seems backwards: def gregToJulian(year, month, day): """Calculate the Gregorian date from the Julian date.""" I know a lot of these things seem like a pain. And it's not that bad now, but the problem is maintaining the code. It will be easier for everyone else if the code is similar to the rest. BTW, protocol on python-dev is pretty loose and friendly. :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-04 18:33 Message: Logged In: YES user_id=357491 Thanks for being so prompt with your response, Skip. I found the problem with your %c. If you look at your output you will notice that the day of the month is '4', but if you look at the docs for time.strftime() you will notice that is specifies the day of the month (%d) as being in the range [01,31]. The regex for %d (simplified) is '(3[0-1])|([0-2]\d)'; not being represented by 2 digits caused the regex to fail. Now the question becomes do we follow the spec and chaulk this up to a non-standard strftime() implementation, or do we adapt strptime to deal with possible improper output from strftime()? Changing the regexes should not be a big issue since I could just tack on '\d' as the last option for all numerical regexes. As for the test error from time.strptime(), I don't know what is causing it. If you look at the test you will notice that all it basically does is parsetime(time.strftime("%Z"), "%Z"). Now how that can fail I don't know. The docs do say that strptime() tends to be buggy, so perhaps this is a case of this. One last thing. Should I wait until the bugs are worked out before I post to python-dev asking to either add this as a module to the standard library or change time to a Python stub and rename timemodule.c? Should I ask now to get the ball rolling? Since I just joined python-dev literally this morning I don't know what the protocol is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-04 01:55 Message: Logged In: YES user_id=44345 Here ya go... % ./python Python 2.3a0 (#185, Jun 1 2002, 23:19:40) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime(time.time()) >>> now (2002, 6, 4, 0, 53, 39, 1, 155, 1) >>> time.strftime("%c", now) 'Tue Jun 4 00:53:39 2002' >>> time.tzname ('CST', 'CDT') >>> time.strftime("%Z", now) 'CDT' ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-04 01:35 Message: Logged In: YES user_id=357491 I have uploaded a verision 2.0.1 which fixes the %b format bug (stupid typo on a variable name). As for the %c directive, I pass that test. Can you please send the output of strftime and the time tuple used to generate it? As for the time.strptime() failure, I don't have time.strptime() on any system available to me, so could you please send me the output you have for strftime('%Z'), and time.tzname? I don't know how much %Z should be worried about since its use is deprecated (according to the time module's documentation). Perhaps strptime() should take the initiative and not support it? -Brett ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-04 00:52 Message: Logged In: YES user_id=44345 Brett, Please see the drastically shortened test_strptime.py. (Basically all I'm interested in here is whether or not strptime.strptime and time.strptime will pass the tests.) Near the top are two lines, one commented out: parsetime = time.strptime #parsetime = strptime.strptime Regardless which version of parsetime I get, I get some errors. If parsetime == time.strptime I get ====================================================================== ERROR: Test timezone directives. ---------------------------------------------------------------------- Traceback (most recent call last): File "test_strptime.py", line 69, in test_timezone strp_output = parsetime(strf_output, "%Z") ValueError: unconverted data remains: 'CDT' If parsetime == strptime.strptime I get ERROR: *** Test %c directive. *** ---------------------------------------------------------------------- Traceback (most recent call last): File "test_strptime.py", line 75, in test_date_time self.helper('c', position) File "test_strptime.py", line 17, in helper strp_output = parsetime(strf_output, '%'+directive) File "strptime.py", line 380, in strptime found_dict = found.groupdict() AttributeError: NoneType object has no attribute 'groupdict' ====================================================================== ERROR: Test for month directives. ---------------------------------------------------------------------- Traceback (most recent call last): File "test_strptime.py", line 31, in test_month self.helper(directive, 1) File "test_strptime.py", line 17, in helper strp_output = parsetime(strf_output, '%'+directive) File "strptime.py", line 393, in strptime month = list(locale_time.f_month).index(found_dict['b']) ValueError: list.index(x): x not in list This is with a very recent interpreter (updated from CVS in the past day) running on Mandrake Linux 8.1. Can you reproduce either or both problems? Got fixes for the strptime.strptime problems? Thx, Skip ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-02 03:44 Message: Logged In: YES user_id=357491 I'm afraid you looked at the wrong patch! My fault since I accidentally forgot to add a description for my patch. So the file with no description is the newest one and completely supercedes the older file. I am very sorry about that. Trust me, the new version is much better. I realized the other day that since the time module is a C extension file, would getting this accepted require getting BDFL approval to add this as a separate module into the standard library? Would the time module have to have a Python interface module where this is put and all other methods in the module just pass directly to the extension file? As for the suggestions, here are my replies to the ones that still apply to the new file: * strings are sequences, so instead of if found in ('y', 'Y') you can do if found in 'yY' -> True, but I personally find it easier to read using the tuple. If it is standard practice in the standard library to do it the suggested way, I will change it. * daylight should use the new bools True, False (this also applies to any other flags) -> Oops. Since I wrote this under Python 2.2.1 I didn't think about it. I will go through the code and look for places where True and False should be used. -Brett C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-01 09:46 Message: Logged In: YES user_id=33168 Overall, the patch looks pretty good. I didn't check for completeness or consistency, though. * You don't need: from exceptions import Exception * The comment "from strptime import * will only export strptime()" is not correct. * I'm not sure what should be included for the license. * Why do you need success flag in CheckIntegrity, you raise an exception? (You don't need to return anything, raise an exception, else it's ok) * In return_time(), could you change xrange(9) to range(len(temp_time)) this removes a dependancy. * strings are sequences, so instead of if found in ('y', 'Y') you can do if found in 'yY' * daylight should use the new bools True, False (this also applies to any other flags) * The formatting doesn't follow the standard (see PEP 8) (specifically, spaces after commas, =, binary ops, comparisons, etc) * Long lines should be broken up The test looks pretty good too. I didn't check it for completeness. The URL is wrong (too high up), the test can be found here: http://www.ocf.berkeley.edu/~bac/Askewed_Thoughts/code/Python/Scripts/test_strptime.py I noticed a spelling mistake in the test: anme -> name. Also, note that PEP 42 has a comment about a python strptime. So if this gets implemented, we need to update PEP 42. Thanks. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-05-27 17: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 18: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 18: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 17: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:21:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:21:22 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 19:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2002-09-03 11:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 11:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 10:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 12:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 15:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 13:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 14:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 20:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 02:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 15:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 10:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 20:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:21:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:21:38 -0700 Subject: [Patches] [ python-Patches-602191 ] single shared ticker Message-ID: Patches item #602191, was opened at 2002-08-29 22:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602191&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: single shared ticker Initial Comment: Per discussion on python-dev, here's a patch that gets rid of the per-thread ticker, instead sharing a single one amongst all threads (and long ints). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:21 Message: Logged In: YES user_id=6380 FWIW, I measure a similar slowdown with the latest patch, compared to current CVS. But I still think it's good to check this in now, Skip. Then in a separate patch we'll increment Py_CheckInterval to 100. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 18:36 Message: Logged In: YES user_id=44345 I just went back and re-ran everything. Here are the results. methodology: * adjust source * recompile (always gcc 2.96 w/ -O3) * run pystones twice, ignoring values * run pystones three times, reporting values ------------------------------------------------------------------------------ baseline (none of this stuff) Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second ------------------------------------------------------------------------------ baseline + check interval set to 100 Pystone(1.1) time for 50000 passes = 7.64 This machine benchmarks at 6544.5 pystones/second Pystone(1.1) time for 50000 passes = 7.63 This machine benchmarks at 6553.08 pystones/second Pystone(1.1) time for 50000 passes = 7.62 This machine benchmarks at 6561.68 pystones/second ------------------------------------------------------------------------------ global, volatile _Py_Ticker == 10 global, nonvolatile _Py_CheckInterval == 10 Jeremy's Py_AddPendingCall shortcut enabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.7 This machine benchmarks at 6493.51 pystones/second Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second ------------------------------------------------------------------------------ global, volatile _Py_Ticker == 100 global, nonvolatile _Py_CheckInterval == 100 Jeremy's Py_AddPendingCall shortcut enabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.6 This machine benchmarks at 6578.95 pystones/second Pystone(1.1) time for 50000 passes = 7.62 This machine benchmarks at 6561.68 pystones/second ------------------------------------------------------------------------------ global, nonvolatile _Py_Ticker == 100 global, nonvolatile _Py_CheckInterval == 100 Jeremy's Py_AddPendingCall shortcut disabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.66 This machine benchmarks at 6527.42 pystones/second Pystone(1.1) time for 50000 passes = 7.64 This machine benchmarks at 6544.5 pystones/second ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 16:58 Message: Logged In: YES user_id=44345 Sorry, compared to the previous version (_Py_CheckInterval == 10, Jeremy's shortcut installed, but _Py_Ticker not yet declared volatile). My first submission didn't include any performance tests. That was the first thing Guido asked for, so I started running pystones with each change. Let me know what, if anything, you'd like me to report performance-wise. Skip ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 16:02 Message: Logged In: YES user_id=31435 A performance hit compared to what? There are half a dozen variations stacked up now. _Py_CheckInterval is back to 10 in the latest patch, and perhaps that has something to do with it. _Py_CheckInterval needn't be delcared volatile, BTW; i.e., take the "volatile" out of + PyAPI_DATA(volatile int) _Py_CheckInterval; I can't time this today, but you should be just as keen to get x-platform verification when claiming a performance hit as when claiming a performance boost. Chances are that it will slobber all over the place across compilers; ceval is extremely touchy. I'm sitting on a major slowdown under MSCV6 after the SET_LINENO thing, and I'm not panicked about that . ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 15:08 Message: Logged In: YES user_id=44345 This version declares the ticker volatile. Obvious performance hit. Does it need to be volatile if the Jeremy's shortcut is removed? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 14:26 Message: Logged In: YES user_id=44345 bump initial check interval to 100, per request from Tim & Guido. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 13:10 Message: Logged In: YES user_id=31435 Note that the ticker has to be declared volatile. Also """ Py_MakePendingCalls should also be changed then to reset ticker to 0 in its "early exit because the coincidences I'm relying on haven't happened yet" cases. """ You can't predict whether ceval will slow down or speed up, so don't bother with being confused . Get the code right first. Good Things will follow. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 12:53 Message: Logged In: YES user_id=44345 Here's a new version that includes Jeremy's shortcut. With _Py_CheckInterval initialized to 10 here are the pystones numbers I get: with my initial patch & Jeremy's ticker shortcut: Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.65 This machine benchmarks at 6535.95 pystones/second back to just my initial patch without the shortcut: Pystone(1.1) time for 50000 passes = 7.59 This machine benchmarks at 6587.62 pystones/second Pystone(1.1) time for 50000 passes = 7.56 This machine benchmarks at 6613.76 pystones/second Pystone(1.1) time for 50000 passes = 7.56 This machine benchmarks at 6613.76 pystones/second I'm perplexed by the performance difference. Again, I think these performance numbers should be checked by some other people. BTW, I configured with OPT=-O3 ../configure in my build directory. I'm using gcc 2.96 and glibc 2.2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 12:01 Message: Logged In: YES user_id=31435 I'd be more interested in a patch that also implemented Jeremy's suggestion. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 11:43 Message: Logged In: YES user_id=44345 minor correction to the patch - initialize both _Py_CheckInterval and _Py_Ticker to 10 so direct pystones comparisons can be made. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 00:15 Message: Logged In: YES user_id=44345 Here's an updated patch. It creates two internal globals, _Py_Ticker and _Py_CheckInterval. They are accessed from sysmodule.c, ceval.c and longobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602191&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:24:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:24:23 -0700 Subject: [Patches] [ python-Patches-474274 ] Pure Python strptime() (PEP 42) Message-ID: Patches item #474274, was opened at 2001-10-23 19:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Guido van Rossum (gvanrossum) 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: Neal Norwitz (nnorwitz) Date: 2002-09-03 14:24 Message: Logged In: YES user_id=33168 I'm assuming Barry really meant to keep this closed. :-) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 14:03 Message: Logged In: YES user_id=12800 Closing. Refer to patch 593560 for further details. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 16:20 Message: Logged In: YES user_id=357491 OK, all patched and attached to the other patch entry. I also discovered a bug in PyUnit and got to submit a patch for that to its patch DB. Such fun. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 23:15 Message: Logged In: YES user_id=357491 Yep, I will patch it. I will add it to patch 593560 which has my last bugfix and code cleanup in it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-23 16:09 Message: Logged In: YES user_id=6380 Reopening to address Jason's bug report. Brett, can you provide a patch? ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2002-08-23 16:06 Message: Logged In: YES user_id=599869 _strptime still doesn't handle case correctly. Although it matches case-insensitive, the lookups for month names are still case sensitive (since they must match exactly the month names returned by time.strftime). Allow me to demonstrate below. >>> import _strptime as strptime >>> strptime.strptime( 'Aug', '%b' ) (-1, 8, -1, -1, -1, -1, -1, -1, -1) >>> strptime.strptime( 'AUG', '%b' ) Traceback (most recent call last): File "", line 1, in ? File "C:\Program Files\Python\Lib\site- packages\strptime.py", line 410, in strptime month = locale_time.a_month.index(found_dict['b']) ValueError: list.index(x): x not in list The same result is encountered using any variation of 'aug' other than 'Aug'. I imagine the solution to this problem is as simple as changing lines 408, 410, 430, and 432 to something like: month = locale_time.a_month.index(capwords(found_dict ['b'])) and adding from string import capwords to the header of the file. This is what I did in strptime v2.0.0 and the latest v2.1.5, and it has worked well. As a general note, I believe the test suite should also test for cases not automatically generated. Many of the parse routines are going to be parsing times generated by systems other than time.strftime, to include variants such as the aforementioned case variant and other things like miscellaneous interspersed strings. I will only suggest these changes, not implement them myself on this page, as I'm not intimately familiar with sourceforge or code customs, so I'll allow someone such as Guido or Brett to make the changes. Regards, Jason ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-19 13:09 Message: Logged In: YES user_id=6380 Thanks! All checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-18 20:43 Message: Logged In: YES user_id=33168 Brett, I'm still following. It wasn't that bad. :-) Guido, let me know if you want me to do anything/check stuff in. Docs are fine to upload here. I can change PEP 42 also. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-18 19:35 Message: Logged In: YES user_id=357491 Since I had the time, I went ahead and did a patch for libtime.tex that removes the comment saying that strptime fully relies on the C library and uploaded it. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-18 18:34 Message: Logged In: YES user_id=357491 Wonderful! About the docs; do you want me to email Fred or upload a patched version of the docs for time fixed? And for removing the request in PEP 42, should I email Jeremy about it or Barry? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-18 17:47 Message: Logged In: YES user_id=6380 OK, deleting all old files as promised. All tests succeed. I think I'll check this version in (but it may be tomorrow, since I've got a few other things to take care of). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-18 17:39 Message: Logged In: YES user_id=357491 God I wish I could delete those old files! Poor Neal Norwitz was nice enough to go over my code once to help me make it sure it was up for being included in the stdlib, but he initially used an old version. Thankfully he was nice enough to look over the newer version at the time. But no, SF does not give me the priveleges to delete old files (and why is that? I am the creator of the patch; you would think I could manage my own files). I re-uploaded everything now. All files that specify they were uploaded 2002-07-17 are the newest files. I am terribly sorry about this whole name mix-up. I have now fixed test_strptime.py to use _strptime. I completely removed the strptime import so that the strptime testing will go through time and thus test which ever version time will export. I removed the __future__ import. And thanks for the piece of advice; I was taking the advice that __future__ statements should come before code a little too far. =) As for your error, that is because the test_strptime.py you are using is old. I originally had a test in there that checked to make sure the regex returned was the same as the one being tested for; that was a bad decision. So I went through and removed all hard-coded tests like that. Unfortunately the version you ran still had that test in there. SF should really let patch creators delete old files. That's it this time. Now I await the next drama in this never-ending saga of trying to make a non-trivial contribution to Python. =) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-18 11:29 Message: Logged In: YES user_id=6380 - Can you please delete all the obsolete uploads? (If SF won't let you, let me know and I'll do it for you, leaving only the most recend version of each.) - There' still a confusion between strptime.py and _strptime.py; your test_time.py imports strptime, and so does the latest version of test_strptime.py I can find. - The "from __future__ import division" is unnecessary, since you're never using the single / operator (// doesn't need the future statement). Also note that future statements should come *after* a module's docstring (for future reference :-). - When I run test_strptime.py, I get one failure: ====================================================================== FAIL: Test TimeRE.pattern. ---------------------------------------------------------------------- Traceback (most recent call last): File "../Lib/test/test_strptime.py", line 124, in test_pattern self.failUnless(pattern_string.find("(?P(3[0-1])|([0-2]\d)|\d|( \d))") != -1, "did not find 'd' directive pattern string '%s'" % pattern_string) File "/home/guido/python/dist/src/Lib/unittest.py", line 262, in failUnless if not expr: raise self.failureException, msg AssertionError: did not find 'd' directive pattern string '(?P(?:Mon)|(?:Tue)|(?:Wed)|(?:Thu)|(?:Fri)|(?:Sat)|(?:Sun))\s*(?P(?:Wednesday)|(?:Thursday)|(?:Saturday)|(?:Tuesday)|(?:Monday)|(?:Friday)|(?:Sunday))\s*(?P3[0-1]|[0-2]\d|\d| \d)' ---------------------------------------------------------------------- I haven't looked into this deeper. Back to you... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-16 17:34 Message: Logged In: YES user_id=357491 Two things have been uploaded. First, test_time.py w/ a strptime test. It is almost an exact mirror of the strftime test; only difference is that I used strftime to test strptime. So if strftime ever fails, strptime will fail also. I feel this is fine since strptime depends on strftime so much that if strftime were to fail strptime would definitely fail. The other file is version 2.1.5 of strptime. I made two changes. One was to remove the TypeError raised when %I was used without %p. This was from me being very picky about only accepting good data strings. The second was to go through and replace all whitespace in the format string with \s*. That basically makes this version of strptime XPG compatible as far as I (and the NetBSD man page) can tell. The only difference now is that I do not require whitespace or a non-alphanumeric character between format strings. Seems like a ridiculous requirement since the requirement that whitespace be able to compress down to no whitespace negates this requirement. Oh well, we are more than compliant now. I decided not to write a patch for the docs to make them read more leniently for what the format directives. Figured I would just let people who think like me do it in a more "proper" way with leading zeros and those who don't read it like that to still be okay. I think that is everything. If you want more in-depth tests, Guido, I can add them to the testing suite, but I figured that since this is (hopefully) going in bug-free it needs only be checked to make sure it isn't broken by anything. And if you do want more in-depth tests, do you want me to add mirror tests for strftime or not worry about that since that is the ANSI C library's problem? Other then that, I think strptime is pretty much done. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-12 18:27 Message: Logged In: YES user_id=357491 Uploaded 2.1.4. I added \d to the end of all relevant regexes (basically all of them but %y and %Y) to deal with non-zero-leading numbers. I also made the regex case-insensitive. As for the diff failing, I am wondering if I am doing something wrong. I am just running diff -c CVS_file modified_file > diff_file . Isn't that right? I will work on merging my strptime tests into the time regression tests and upload a patch here. I will do a patch for the docs since it is not consistent with the explanation of struct_time (or at least in my opinion). I tried finding XPG docs, but the best Google came up with was the NetBSD man pages for strptime (which they claim is XPG compliant). The difference between that implementation and mine is that NetBSD's allows whitespace (defined as isspace()) in the format string to match \s* in the data string. It also requires a whitespace or a non-alphanumeric character while my implementation does not require that. Personally, I don't like either difference. If they were used, though, there might be a possibility of rewriting strptime to just use a bunch of string methods instead of regexes for a possible performance benefit. But I prefer regexes since it adds checks of the input. That and I just like regexes period. =) Also, I noticed that your little test returned 0 for all unknown values. Mine returns -1 since 0 can be a legitimate value for some and I figured that would eliminate ambiguity. I can change it to 0, though. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 17:13 Message: Logged In: YES user_id=6380 Hm, the new diff_time *still* fails to apply. But don't worry about that. I'd love to see regression tests for time.strptime. Please upload them here -- don't start a new patch. I think your interpretation of the docs is overly restrictive; the table shows what strftime does but I think it's reasonable for strptime to accept missing leading zeros. You can upload a patch for the docs too if you feel that's necessary. You may also try to read up on what the XPG standard says about strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-12 17:02 Message: Logged In: YES user_id=357491 To respond to your points, Guido: (a) I accidentally uploaded the old file. Sorry about that. I misnamed the new one 'time_diff" but in my head I meant to overwrite "diff_time". I have uploaded the new one. (b) See (a) (c) Oops. That is a complete oversight on my part. Now in (d) you mention writing up regression tests for the standard time.strptime. I am quite hapy to do this. Do you want that as a separate patch? If so I will just stop with uploading tests here and just start a patch with my strptime tests for the stdlib tests. (d) The reason this test failed is because your input is not compliant with the Python docs. Read what %m accepts: Month as a decimal number [01,12] Notice the leading 0 for the single digit month. My implementation follows the docs and not what glibc suggests. If you want, I can obviously add on to all the regexes \d as an option and eliminate this issue. But that means it will no longer be following the docs. This tripped Skip up too since no one writes numbers that way; strftime does, though. Now if the docs meant for no trailing 0, I think they should be rewritten since that is misleading. In other words, either strptime stays as it is and follows the docs or I change the regexes, but then the docs will have to be changed. I can go either way, but I personally would want to follow the docs as-is since strptime is meant to parse strftime output and not human output. =) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-12 12:58 Message: Logged In: YES user_id=6380 Hm. This isn't done yet. I get these problems: (a) the patch for timemodule.c doesn't apply cleanly in current CVS (trivial) (b) it still tries to import strptime (no leading '_') (also trivial) (c) so does test_strptime.py (also trivial) (d) the simplest of simple examples fails: With Linux's strptime: >>> time.strptime("7/12/02", "%m/%d/%y") (2002, 7, 12, 0, 0, 0, 4, 193, 0) >>> With yours: >>> time.strptime("7/12/02", "%m/%d/%y") Traceback (most recent call last): File "", line 1, in ? File "/home/guido/python/dist/src/Lib/_strptime.py", line 392, in strptime raise ValueError("time data did not match format") ValueError: time data did not match format >>> Perhaps you should write a regression test suite for the strptime function as found in the time module courtesy of libc, and then make sure that your code satisfies it? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-07-10 16:51 Message: Logged In: YES user_id=357491 The actual 2.1.3 edition of strptime is now up. I don't think there are any changes, but since I renamed the file _strptime.py, I figured uploading it again wouldn't hurt. I also uploaded a new contextual diff of the time module taken from CVS on 2002-07-10. The only difference between this and the previous diff (which was against 2.2.1's time module) is the change of the imported module to _strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-27 00:54 Message: Logged In: YES user_id=357491 Uploaded 2.1.2 (but accidentally labelled it 2.1.3 down below!). Just a little bit more cleanup. Biggest change is that I changed the default format string and made strptime() raise ValueError instead of TypeError. This was all done to match the time module docs. I also fiddled with the regexes so that the groups were none-capturing. Mainly done for a possible performance improvement. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-23 21:06 Message: Logged In: YES user_id=357491 2.1.1 is now uploaded. Almost a purely syntatical change. >From discussions on python-dev I renamed the helper fxns so they are all lowercase-style. Also changed them so that they state what the fxn returns. I also put all of the imports on their own line as per PEP 8. The only semantical change I did was directly import re.compile since it is the only thing I am using from the re module. These changes required tweaking of my exhaustive testing suite, so that got uploaded, too. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-21 00:35 Message: Logged In: YES user_id=357491 I have uploaded a contextual diff of timemodule.c with a callout to strptime.strptime when HAVE_STRPTIME is not defined just as Guido requested. It's my first extension module, so I am not totally sure of myself with it. But since Alex Marttelli told me what I needed to do I am fairly certain it is correct. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-19 17:49 Message: Logged In: YES user_id=357491 2.1.0 is now up and ready for use. I only changed two things to the code, but since they change the semantics of stprtime()s use, I made this a new minor release. One, I removed the ability to pass in your own LocaleTime object. I did this for two reasons. One is because I forgot about how default arguments are created at the time of function creation and not at each fxn call. This meant that if someone was not thinking and ran strptime() under one locale and then switched to another locale without explicitly passing in a new LocaleTime object for every call for the new locale, they would get bad matches. That is not good. The other reason was that I don't want to force users to pass in a LocaleTime object on every call if I can't have a default value for it. This is meant to act as a drop-in replacement for time.strptime(). That forced the removal of the parameter since it can't have a default value. In retrospect, though, people will probably never parse log files in other languages other then there default locale. And if they were, they should change the locale for the interpreter and not just for strptime(). The second change was what triggers strptime() to return an re object that it can use. Initially it was any nothing value (i.e., would be considered false), but I realized that an empty string could trigger that and it would be better to raise a TypeError then let some error come up from trying to use the re object in an incorrect way. Now, to have an re object returned, you pass in False. I figured that there is a very minimal chance of passing in False when you meant to pass in a string. Also, False as the data_string, to me, means that I don't want what would normally be returned. I debated about removing this feature from strptime(), but I profiled it and most of the time comes from TimeRE's __getitem__. So building the string to be compiled into a regex is the big bottleneck. Using a precompiled regex instead of constructing a new one everytime took 25% of the time overall for strptime() when calling strptime() 10,000 times in a row. This is a conservative number, IMO, for calls in a row; I checked the Apache hit logs for a single day on Open Computing Facility's web server (http://www.ocf.berkeley.edu/) and there were 188,562 hits on June 16 alone. So I am going to keep the feature until someone tells me otherwise. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-18 15:05 Message: Logged In: YES user_id=357491 I have uploaded v. 2.0.4. It now uses the calendar module to figure out the names of weekdays and months. Thanks goes out to Guido for pointing out this undocumented feature of calendar. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-17 16:11 Message: Logged In: YES user_id=357491 I uploaded v.2.0.3. Beyond implementing what I mentioned previously (raising TypeError when a match fails, adding \d to all applicable regexes) I did a few more things. For one, I added a special " \d" to the numeric month regex. I discovered that ANSI C for ctime displays the month with a leading space if it is a single digit. So to deal with that since at least Skip's C library likes to use that format for %c, I went ahead and added it. I changed all attributes in LocaleTime to lists. A recent mail on python-dev from GvR said that lists are for homogeneous data, which everything that is grouped together in LocaleTime is. It also simplified the code slightly and led to less conversions of data types. I also added a method that raises a TypeError if you try to assign to any of LocaleTime's attributes. I thought that if you left out the set value for property() it wouldn't work; didn't realize it just defaults over to __setitem__. So I added that method as the set value for all of the property()s. It does require 2.2.1 now since I used True and False without defining them. Obviously just set those values to 1 and 0 respectively if you are running under 2.2 I also updated the overly exhaustive PyUnit suite that I have for testing my code. It is not black-box testing, though; Skip's pruned version of my testing suite fits that bill (I think). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-12 20:46 Message: Logged In: YES user_id=357491 I am back from my vacation and ready to email python- dev about getting this patch accepted (whether to modify time or make this a separate module, etc.). I think I will do the email on June 17. Before then, though, I am going to make two changes. One is the raise a Value Error exception if the regex doesn't match (to try to match time.strptime()s exception as seen in Skip's run of the unit test). The other change is to tack on a \d on all numeric formats where it might come out as a single digit (i.e., lacking a leading zero). This will be for v2.0.3 which I will post before June 17. If there is any reason anyone thinks I should hold back on this, please let me know! I would like to have this code as done as possible before I make any announcement. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-05 02:32 Message: Logged In: YES user_id=357491 I went ahead an implemented most of Neal's suggestions. On a few, of them, though, I either didn't do it or took a slightly different route. For the 'yY' vs. ('y', 'Y'), I went with 'yY'. If it gives a performance boost, why not since it doesn't make the code harder to read. Implementing it actually had me catch some redundant code for dealing with a literal %. The tests in the __init__ for LocaleTime have been reworked to check that they are either None or have the proper length, otherwise they raise a TypeError. I have gone through and tried to catch all the lines that were over 80 characters and cut them up to fit. For the adding of '' to tuples, I created a method that could specify front or back concatination. Not much different from before, but it allows me to specify front or back concatination easily. I explained why the various magic dates were used. I in no way have to worry about leap year. Since it is not validating the data string for validity the fxn just takes the data and uses it. I have no reason to calc for leap year. date_time[offset] has been replaced with current_format and added the requisite two lines to assign between it and the list. You are only supposed to use __new__ when it is immutable. Since dict is obviously mutable, I don't need to worry about it. Used Neal's suggested shortening of the sorter helper fxn. I also used the suggestion of doing x = y = z = -1. Now it barely fits on a single line instead of two. All numerical compares use == and != instead of is and is not. Didn't know about that dependency on NSMALL((POS)|(NEG))INTS; good thing to know. The doc string was backwards. Thanks for catching that, Neal. I also went through and added True and False where appropriate. There is a line in the code where True = 1; False = 0 right at the top. That can obviously be removed if being run under Python 2.3. And I completely understand being picky about minute details where maintainability is a concern. I just graduated from Cal and so the memory of seeing beginning programmers' code is still fresh in my mind . And I will query python-dev about how to go about to get this added after the bugs are fixed and I am back home (going to be out of town until June 16). I will still be periodically checking email, though, so I will continue to implement any suggestions/bugfixes that anyone suggests/finds. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-04 19:33 Message: Logged In: YES user_id=33168 Hopefully, I'm looking at the correct patch this time. :-) To answer one question you had (re: 'yY' vs. ('y', 'Y')), I'm not sure people really care. It's not big to me. Although 'yY' is faster than ('y', 'Y'). In order to try to reduce the lines where you raise an error (in __init__) you could change 'sequence of ... must be X items long' to '... must have/contain X items'. Generally, it would be nice to make sure none of the lines are over 72-79 chars (see PEP 8). Instead of doing: newlist = list(orig) newlist.append('') x = tuple(newlist) you could do: x = tuple(orig[:]) or something like that. Perhaps a helper function? In __init__ do you want to check the params against 'is None' If someone passes a non-sequence that doesn't evaluate to False, the __init__ won't raise a TypeError which it probably should. What is the magic date used in __calc_weekday()? (1999/3/15+ 22:44:55) is this significant, should there be a comment? (magic dates are used elsewhere too, e.g., __calc_month, __calc_am_pm, many more) __calc_month() doesn't seem to take leap year into account? (not sure if this is a problem or not) In __calc_date_time(), you use date_time[offset] repetatively, couldn't you start the loop with something like dto = date_time[offset] and then use dto (dto is not a good name, I'm just making an example) Are you supposed to use __init__ when deriving from built-ins (TimeRE(dict)) or __new__? (sorry, I don't remember the answer) In __tupleToRE.sorter(), instead of the last 3 lines, you can do: return cmp(b_length, a_length) Note: you can do x = y = z = -1, instead of x = -1 ; y = -1 ; z = -1 It could be problematic to compare x is -1. You should probably just use ==. It would be a problem if NSMALLPOSINTS or NSMALLNEGINTS were not defined in Objects/intobject.c. This docstring seems backwards: def gregToJulian(year, month, day): """Calculate the Gregorian date from the Julian date.""" I know a lot of these things seem like a pain. And it's not that bad now, but the problem is maintaining the code. It will be easier for everyone else if the code is similar to the rest. BTW, protocol on python-dev is pretty loose and friendly. :-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-04 18:33 Message: Logged In: YES user_id=357491 Thanks for being so prompt with your response, Skip. I found the problem with your %c. If you look at your output you will notice that the day of the month is '4', but if you look at the docs for time.strftime() you will notice that is specifies the day of the month (%d) as being in the range [01,31]. The regex for %d (simplified) is '(3[0-1])|([0-2]\d)'; not being represented by 2 digits caused the regex to fail. Now the question becomes do we follow the spec and chaulk this up to a non-standard strftime() implementation, or do we adapt strptime to deal with possible improper output from strftime()? Changing the regexes should not be a big issue since I could just tack on '\d' as the last option for all numerical regexes. As for the test error from time.strptime(), I don't know what is causing it. If you look at the test you will notice that all it basically does is parsetime(time.strftime("%Z"), "%Z"). Now how that can fail I don't know. The docs do say that strptime() tends to be buggy, so perhaps this is a case of this. One last thing. Should I wait until the bugs are worked out before I post to python-dev asking to either add this as a module to the standard library or change time to a Python stub and rename timemodule.c? Should I ask now to get the ball rolling? Since I just joined python-dev literally this morning I don't know what the protocol is. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-04 01:55 Message: Logged In: YES user_id=44345 Here ya go... % ./python Python 2.3a0 (#185, Jun 1 2002, 23:19:40) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> now = time.localtime(time.time()) >>> now (2002, 6, 4, 0, 53, 39, 1, 155, 1) >>> time.strftime("%c", now) 'Tue Jun 4 00:53:39 2002' >>> time.tzname ('CST', 'CDT') >>> time.strftime("%Z", now) 'CDT' ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-04 01:35 Message: Logged In: YES user_id=357491 I have uploaded a verision 2.0.1 which fixes the %b format bug (stupid typo on a variable name). As for the %c directive, I pass that test. Can you please send the output of strftime and the time tuple used to generate it? As for the time.strptime() failure, I don't have time.strptime() on any system available to me, so could you please send me the output you have for strftime('%Z'), and time.tzname? I don't know how much %Z should be worried about since its use is deprecated (according to the time module's documentation). Perhaps strptime() should take the initiative and not support it? -Brett ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-06-04 00:52 Message: Logged In: YES user_id=44345 Brett, Please see the drastically shortened test_strptime.py. (Basically all I'm interested in here is whether or not strptime.strptime and time.strptime will pass the tests.) Near the top are two lines, one commented out: parsetime = time.strptime #parsetime = strptime.strptime Regardless which version of parsetime I get, I get some errors. If parsetime == time.strptime I get ====================================================================== ERROR: Test timezone directives. ---------------------------------------------------------------------- Traceback (most recent call last): File "test_strptime.py", line 69, in test_timezone strp_output = parsetime(strf_output, "%Z") ValueError: unconverted data remains: 'CDT' If parsetime == strptime.strptime I get ERROR: *** Test %c directive. *** ---------------------------------------------------------------------- Traceback (most recent call last): File "test_strptime.py", line 75, in test_date_time self.helper('c', position) File "test_strptime.py", line 17, in helper strp_output = parsetime(strf_output, '%'+directive) File "strptime.py", line 380, in strptime found_dict = found.groupdict() AttributeError: NoneType object has no attribute 'groupdict' ====================================================================== ERROR: Test for month directives. ---------------------------------------------------------------------- Traceback (most recent call last): File "test_strptime.py", line 31, in test_month self.helper(directive, 1) File "test_strptime.py", line 17, in helper strp_output = parsetime(strf_output, '%'+directive) File "strptime.py", line 393, in strptime month = list(locale_time.f_month).index(found_dict['b']) ValueError: list.index(x): x not in list This is with a very recent interpreter (updated from CVS in the past day) running on Mandrake Linux 8.1. Can you reproduce either or both problems? Got fixes for the strptime.strptime problems? Thx, Skip ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-06-02 03:44 Message: Logged In: YES user_id=357491 I'm afraid you looked at the wrong patch! My fault since I accidentally forgot to add a description for my patch. So the file with no description is the newest one and completely supercedes the older file. I am very sorry about that. Trust me, the new version is much better. I realized the other day that since the time module is a C extension file, would getting this accepted require getting BDFL approval to add this as a separate module into the standard library? Would the time module have to have a Python interface module where this is put and all other methods in the module just pass directly to the extension file? As for the suggestions, here are my replies to the ones that still apply to the new file: * strings are sequences, so instead of if found in ('y', 'Y') you can do if found in 'yY' -> True, but I personally find it easier to read using the tuple. If it is standard practice in the standard library to do it the suggested way, I will change it. * daylight should use the new bools True, False (this also applies to any other flags) -> Oops. Since I wrote this under Python 2.2.1 I didn't think about it. I will go through the code and look for places where True and False should be used. -Brett C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-01 09:46 Message: Logged In: YES user_id=33168 Overall, the patch looks pretty good. I didn't check for completeness or consistency, though. * You don't need: from exceptions import Exception * The comment "from strptime import * will only export strptime()" is not correct. * I'm not sure what should be included for the license. * Why do you need success flag in CheckIntegrity, you raise an exception? (You don't need to return anything, raise an exception, else it's ok) * In return_time(), could you change xrange(9) to range(len(temp_time)) this removes a dependancy. * strings are sequences, so instead of if found in ('y', 'Y') you can do if found in 'yY' * daylight should use the new bools True, False (this also applies to any other flags) * The formatting doesn't follow the standard (see PEP 8) (specifically, spaces after commas, =, binary ops, comparisons, etc) * Long lines should be broken up The test looks pretty good too. I didn't check it for completeness. The URL is wrong (too high up), the test can be found here: http://www.ocf.berkeley.edu/~bac/Askewed_Thoughts/code/Python/Scripts/test_strptime.py I noticed a spelling mistake in the test: anme -> name. Also, note that PEP 42 has a comment about a python strptime. So if this gets implemented, we need to update PEP 42. Thanks. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-05-27 17: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 18: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 18: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 17: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=474274&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:48:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:48:51 -0700 Subject: [Patches] [ python-Patches-603667 ] reiter() builtin Message-ID: Patches item #603667, was opened at 2002-09-02 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603667&group_id=5470 >Category: Core (C code) >Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Oren Tirosh (orenti) >Assigned to: Guido van Rossum (gvanrossum) Summary: reiter() builtin Initial Comment: The reiter() function is similar to iter() but expects a re-iterable object as an argument. If the object is already an iterator a TypeError will be raised. Example: def f(a, b): for i in a: for j in reiter(b): do_something_with(i, j) This function will raise an error if it is passed a non-reiterable object as the second argument. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:48 Message: Logged In: YES user_id=6380 You know, I think that this is a nice addition in theory, but in practice, I don't see anyone except you using it. So, I'm rejecting this. Anybody can write this themselves in 2 lines of code; you can submit a doc patch to explain that to people (it could be an example for iter()). ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-02 16:19 Message: Logged In: YES user_id=562624 Correction. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603667&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:52:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:52:48 -0700 Subject: [Patches] [ python-Patches-603548 ] Python object refcount accessors Message-ID: Patches item #603548, was opened at 2002-09-02 11:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603548&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Rolf Kalbermatter (labviewer) >Assigned to: Guido van Rossum (gvanrossum) Summary: Python object refcount accessors Initial Comment: It could be useful for more generic clients of the Python core to not have to worry about the actual layout of Py_ObjectHEAD and other things. So I propose to add the two additional functions: int PyObject_IncRef(PyObject *ob) int PyObject_DecRef(PyObject *ob) Those functions could also be added to the Python 2.2 if any bug fix might be pending for it. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:52 Message: Logged In: YES user_id=6380 Switching between the DEBUG and non-DEBUG Python DLL is not supported. There are too many things that wouldn't work; Py_INCREF is just the tip of the iceberg. So I'm rejecting this. ---------------------------------------------------------------------- Comment By: Rolf Kalbermatter (labviewer) Date: 2002-09-03 12:41 Message: Logged In: YES user_id=66382 I do not object the existing macros and in absence of those proposed functions use them now, but they create unneccessary dependencies on the used Python core DLL by accessing data members of the Py_ObjectHEAD structure directly. This is especially a problem since the offset of those members changes depending if the DLL is compiled in DEBUG or non-DEBUG mode and therefore requires the client to be compiled exactly the same. Also they access additional Python data references in DEBUG mode. In my case I wanted to embed Python in another application and since I only use Python core DLL functions, I thought I would allow configuration of the Python DLL to use and load it dynamically with LoadLibrary() and access the functions with GetProcAddress(). Although this works already fine the implicit access to PyObject structure members limits the flexibility seriously. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-02 11:33 Message: Logged In: YES user_id=31435 What's your objection to the existing Py_INCREF() and Py_DECREF()? Or didn't you know about them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603548&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:55:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:55:10 -0700 Subject: [Patches] [ python-Patches-602108 ] improper use of strncpy in getpath Message-ID: Patches item #602108, was opened at 2002-08-29 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Rejected Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: improper use of strncpy in getpath Initial Comment: Many uses of strncpy() in Modules/getpath and PC/getpathp do not copy the terminating null character onto the string. This patch makes sure the strings are null terminated after strncpy(). Should this be backported? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:55 Message: Logged In: YES user_id=6380 Since the variables affected are all globals, there is already a null byte in the final position. So there's no need to write one explicitly. I therefore reject this patch. I'm leaving it open in case I'm misunderstanding something. If you agree, please close it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:55:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:55:57 -0700 Subject: [Patches] [ python-Patches-602005 ] sys.path in user.py Message-ID: Patches item #602005, was opened at 2002-08-29 14:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602005&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Stepan Koltsov (yozh) >Assigned to: Guido van Rossum (gvanrossum) Summary: sys.path in user.py Initial Comment: this patch adds ~/lib/python, ~/lib/pythonx.y to sys.path in module user.py. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:55 Message: Logged In: YES user_id=6380 I'm not interested in doing this. You can set PYTHONPATH in your environment if you want this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602005&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:56:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:56:41 -0700 Subject: [Patches] [ python-Patches-599836 ] Bugfix for urllib2.py Message-ID: Patches item #599836, was opened at 2002-08-25 03:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Jeremy Hylton (jhylton) Summary: Bugfix for urllib2.py Initial Comment: OpenerDirector has a default User-agent header. That wouldn't be a problem, except that AbstractHTTPHandler uses the headers in OpenerDirector.addheaders *after* a Request has been instantiated, thus making that default override whatever headers were given to Request. This patch checks to make sure a header isn't already in a Request before adding the OpenerDirector's headers. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:56 Message: Logged In: YES user_id=6380 For Jeremy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:57:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:57:04 -0700 Subject: [Patches] [ python-Patches-598163 ] textwrap.dedent, inspect.getdoc-ish Message-ID: Patches item #598163, was opened at 2002-08-21 05:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ville Vainio (vvainio) >Assigned to: Greg Ward (gward) Summary: textwrap.dedent, inspect.getdoc-ish Initial Comment: Ability to remove indentation from multiline strings (often triple-quoted). Differs from inspect.getdoc by not handling the first line in special manner (often a sensible approach for non-docstring multiline strings) - which should make this function more general (symmetric 'indent' also possible), and more fitting for the textwrap module. Implementation is for the most parts familiar from inspect.getdoc, though I used sring methods instead of the module 'string'. The module 'textwrap' and the function name 'dedent' were suggested on python-dev a while back (by MAL, IIRC). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:57 Message: Logged In: YES user_id=6380 For Greg Ward. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:57:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:57:49 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 07:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 09:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:06:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:06:29 -0700 Subject: [Patches] [ python-Patches-593069 ] socketmodule.[ch] downgrade Message-ID: Patches item #593069, was opened at 2002-08-09 10:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593069&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Stepan Koltsov (yozh) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.[ch] downgrade Initial Comment: 1. Was removed fields 'sock_type' and 'sock_proto' from structure PySocketSockObject since they are not used anywhere. 2. Changed semantics of 'socket.fromfd'. Now it ignore 3rd and 4th arguments, 2nd arg is optional, if it was not specified, it got with getsockname call. 3. Added constant AF_LOCAL. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:06 Message: Logged In: YES user_id=6380 Rejected. sock_type and sock_proto are used in the socket() call, and I find it useful to be able to report these in repr(). I may use your trick to get the default family for fromfd() though. What is AF_LOCAL? Your patch for it is wrong -- it doesn't add a proper #ifdef around it, and it defines the value to be the same as AF_INET. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593069&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:43:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:43:16 -0700 Subject: [Patches] [ python-Patches-601369 ] obmalloc,structmodule: 64bit, big endian Message-ID: Patches item #601369, was opened at 2002-08-28 11:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 Category: Modules >Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) >Assigned to: Guido van Rossum (gvanrossum) Summary: obmalloc,structmodule: 64bit, big endian Initial Comment: Issue 1: in Objects/obmalloc.c, SYSTEM_PAGE_SIZE is assumed to be 4K. I corrected (#if _MIPS_ABI>=4) the page size at least for 64bit SGI Irix machines. Issue 2: in Modules/structmodule.c, most of the un/packing functions assumed that the char *p argument (destination or source for un/packing) is correctly aligned for the concerned type. It is no problem for x86 processors (2 cycle access instead of 1 if unaligned), but it is a problem for 64bit MIPS processors (where an int is 64bit and it must be at least on a 4-byte boundary). All the functions handling types larger than 1 byte use memcpy now, taking care of endianess with an intermediate variable y wherever needed. The sparse comments stating "p may not be properly aligned" are removed, and a more thorough comment is inserted before the definitions of the un/packing functions. The patched module passes test_struct fine in 64-bit and 32-bit builds on an SGI Octane with MIPS cc; so it does on a Pentium Linux with gcc. I have no way to make a Windows build. Pack formats prefixed with '!' or '>' produce the same sizes everywhere. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:43 Message: Logged In: YES user_id=6380 Tim sez, the obmalloc.c patch should not go in unless supported by measurements. I do like the structmodule.c patch, and have check it in. Thanks! PS the structmodule patch might apply to Python 2.2.x too. Somebody should backport it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:46:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:46:54 -0700 Subject: [Patches] [ python-Patches-602191 ] single shared ticker Message-ID: Patches item #602191, was opened at 2002-08-29 22:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602191&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: single shared ticker Initial Comment: Per discussion on python-dev, here's a patch that gets rid of the per-thread ticker, instead sharing a single one amongst all threads (and long ints). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-03 14:46 Message: Logged In: YES user_id=31435 I get a 1.5% speedup on Win2K, baseline versus whatever this patch does. Go for it, Skip, as I said before, """ _Py_CheckInterval needn't be delcared volatile, BTW; i.e., take the "volatile" out of + PyAPI_DATA(volatile int) _Py_CheckInterval; """ The patch won't compile under MSVC6 unless this is done (as is, the declaration conflicts with the definition). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:21 Message: Logged In: YES user_id=6380 FWIW, I measure a similar slowdown with the latest patch, compared to current CVS. But I still think it's good to check this in now, Skip. Then in a separate patch we'll increment Py_CheckInterval to 100. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 18:36 Message: Logged In: YES user_id=44345 I just went back and re-ran everything. Here are the results. methodology: * adjust source * recompile (always gcc 2.96 w/ -O3) * run pystones twice, ignoring values * run pystones three times, reporting values ------------------------------------------------------------------------------ baseline (none of this stuff) Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second ------------------------------------------------------------------------------ baseline + check interval set to 100 Pystone(1.1) time for 50000 passes = 7.64 This machine benchmarks at 6544.5 pystones/second Pystone(1.1) time for 50000 passes = 7.63 This machine benchmarks at 6553.08 pystones/second Pystone(1.1) time for 50000 passes = 7.62 This machine benchmarks at 6561.68 pystones/second ------------------------------------------------------------------------------ global, volatile _Py_Ticker == 10 global, nonvolatile _Py_CheckInterval == 10 Jeremy's Py_AddPendingCall shortcut enabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.7 This machine benchmarks at 6493.51 pystones/second Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second ------------------------------------------------------------------------------ global, volatile _Py_Ticker == 100 global, nonvolatile _Py_CheckInterval == 100 Jeremy's Py_AddPendingCall shortcut enabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.6 This machine benchmarks at 6578.95 pystones/second Pystone(1.1) time for 50000 passes = 7.62 This machine benchmarks at 6561.68 pystones/second ------------------------------------------------------------------------------ global, nonvolatile _Py_Ticker == 100 global, nonvolatile _Py_CheckInterval == 100 Jeremy's Py_AddPendingCall shortcut disabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.66 This machine benchmarks at 6527.42 pystones/second Pystone(1.1) time for 50000 passes = 7.64 This machine benchmarks at 6544.5 pystones/second ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 16:58 Message: Logged In: YES user_id=44345 Sorry, compared to the previous version (_Py_CheckInterval == 10, Jeremy's shortcut installed, but _Py_Ticker not yet declared volatile). My first submission didn't include any performance tests. That was the first thing Guido asked for, so I started running pystones with each change. Let me know what, if anything, you'd like me to report performance-wise. Skip ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 16:02 Message: Logged In: YES user_id=31435 A performance hit compared to what? There are half a dozen variations stacked up now. _Py_CheckInterval is back to 10 in the latest patch, and perhaps that has something to do with it. _Py_CheckInterval needn't be delcared volatile, BTW; i.e., take the "volatile" out of + PyAPI_DATA(volatile int) _Py_CheckInterval; I can't time this today, but you should be just as keen to get x-platform verification when claiming a performance hit as when claiming a performance boost. Chances are that it will slobber all over the place across compilers; ceval is extremely touchy. I'm sitting on a major slowdown under MSCV6 after the SET_LINENO thing, and I'm not panicked about that . ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 15:08 Message: Logged In: YES user_id=44345 This version declares the ticker volatile. Obvious performance hit. Does it need to be volatile if the Jeremy's shortcut is removed? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 14:26 Message: Logged In: YES user_id=44345 bump initial check interval to 100, per request from Tim & Guido. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 13:10 Message: Logged In: YES user_id=31435 Note that the ticker has to be declared volatile. Also """ Py_MakePendingCalls should also be changed then to reset ticker to 0 in its "early exit because the coincidences I'm relying on haven't happened yet" cases. """ You can't predict whether ceval will slow down or speed up, so don't bother with being confused . Get the code right first. Good Things will follow. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 12:53 Message: Logged In: YES user_id=44345 Here's a new version that includes Jeremy's shortcut. With _Py_CheckInterval initialized to 10 here are the pystones numbers I get: with my initial patch & Jeremy's ticker shortcut: Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.65 This machine benchmarks at 6535.95 pystones/second back to just my initial patch without the shortcut: Pystone(1.1) time for 50000 passes = 7.59 This machine benchmarks at 6587.62 pystones/second Pystone(1.1) time for 50000 passes = 7.56 This machine benchmarks at 6613.76 pystones/second Pystone(1.1) time for 50000 passes = 7.56 This machine benchmarks at 6613.76 pystones/second I'm perplexed by the performance difference. Again, I think these performance numbers should be checked by some other people. BTW, I configured with OPT=-O3 ../configure in my build directory. I'm using gcc 2.96 and glibc 2.2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 12:01 Message: Logged In: YES user_id=31435 I'd be more interested in a patch that also implemented Jeremy's suggestion. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 11:43 Message: Logged In: YES user_id=44345 minor correction to the patch - initialize both _Py_CheckInterval and _Py_Ticker to 10 so direct pystones comparisons can be made. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 00:15 Message: Logged In: YES user_id=44345 Here's an updated patch. It creates two internal globals, _Py_Ticker and _Py_CheckInterval. They are accessed from sysmodule.c, ceval.c and longobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602191&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:24:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:24:55 -0700 Subject: [Patches] [ python-Patches-600488 ] Robustness tweak to httplib.py Message-ID: Patches item #600488, was opened at 2002-08-26 21:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600488&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tom Emerson (tree) Assigned to: Jeremy Hylton (jhylton) Summary: Robustness tweak to httplib.py Initial Comment: Python 2.2.1, FreeBSD 4.4-STABLE httplib.py raises UnknownTransferEncoding if the HTTP response's Transfer-Encoding header is anything except 'chunked'. Some servers return completely bogus values in this header for otherwise valid results. This patch causes unknown (i.e., non-chunked) transfer encodings to be ignored. This appears to be the behavior of most user-agents I've looked at. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 19:24 Message: Logged In: YES user_id=31392 Fixed in rev 1.65 of httplib.py ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 16:53 Message: Logged In: YES user_id=6380 Jeremy, this looks simple enough to check it in. Do you see any reason why I shouldn't? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600488&group_id=5470 From noreply@sourceforge.net Tue Sep 3 19:29:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 11:29:03 -0700 Subject: [Patches] [ python-Patches-597907 ] Oren Tirosh's fastnames patch Message-ID: Patches item #597907, was opened at 2002-08-20 15:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Oren Tirosh's fastnames patch Initial Comment: Oren Tirosh had a nice patch to *really* speed up global/builtin name lookup. I'm adding it here because I don't want to lose this idea. His code and some comments are here: http://www.tothink.com/python/fastnames/ I'm uploading a new version of this patch relative to current CVS. I'm still considering whether to do this; I measure at best a 1% speedup for pystone. For a modified version of Oren's benchmark (modified to use a function instead of a class for 'builtin' and 'global', so that these tests use LOAD_GLOBAL rather than LOAD_NAME, I get these test results (best of 3): builtin 1.38 global 1.54 local 1.28 fastlocal 0.90 Python 2.3 without his patch (but with my speedup hacks in LOAD_GLOBAL): builtin 1.80 global 1.52 local 1.77 fastlocal 0.91 Python 2.2 (from the 2.2 branch, which is newer than the 2.2.1 release but doesn't have any speedups) did this: builtin 2.28 global 1.86 local 1.80 fastlocal 1.10 I don't care about the speedup for the 'local' case, since this uses the LOAD_NAME opcode which is only used inside class definitions; the 'builtin' and 'global' cases are interesting. It looks like Oren's patch gives us a nice speedup for looking up a built-in name from a function. I have to think about why looking up a global from a function is slower though... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:29 Message: Logged In: YES user_id=6380 OK. I'm holding my breath! :-) ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-02 15:59 Message: Logged In: YES user_id=562624 I'm working on an improved version. Stay tuned! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-20 15:31 Message: Logged In: YES user_id=6380 Tim explained why the 'globals' case is faster than the 'builtins' case. I used 'x' as the global to look up rather than 'hex', and it so happens that the last three bits of hash('x') and hash('MANY') are the same -- MANY is an identifier I insert in the globals. I'll attach the test suite I used (with 'hex' instead of 'x'). Now I get these times: builtin 1.39 global 1.28 local 1.29 fastlocal 0.91 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 From noreply@sourceforge.net Tue Sep 3 20:44:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 12:44:03 -0700 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 13:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Riehl (jriehl) >Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply@sourceforge.net Tue Sep 3 21:13:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 13:13:05 -0700 Subject: [Patches] [ python-Patches-602191 ] single shared ticker Message-ID: Patches item #602191, was opened at 2002-08-29 21:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602191&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: single shared ticker Initial Comment: Per discussion on python-dev, here's a patch that gets rid of the per-thread ticker, instead sharing a single one amongst all threads (and long ints). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-03 15:13 Message: Logged In: YES user_id=44345 Implemented as Include/pystate.h 2.20 Include/ceval.h 2.46 Python/ceval.c 2.334 Python/sysmodule.c 2.110 Objects/longobject.c 1.143 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-03 13:46 Message: Logged In: YES user_id=31435 I get a 1.5% speedup on Win2K, baseline versus whatever this patch does. Go for it, Skip, as I said before, """ _Py_CheckInterval needn't be delcared volatile, BTW; i.e., take the "volatile" out of + PyAPI_DATA(volatile int) _Py_CheckInterval; """ The patch won't compile under MSVC6 unless this is done (as is, the declaration conflicts with the definition). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 13:21 Message: Logged In: YES user_id=6380 FWIW, I measure a similar slowdown with the latest patch, compared to current CVS. But I still think it's good to check this in now, Skip. Then in a separate patch we'll increment Py_CheckInterval to 100. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 17:36 Message: Logged In: YES user_id=44345 I just went back and re-ran everything. Here are the results. methodology: * adjust source * recompile (always gcc 2.96 w/ -O3) * run pystones twice, ignoring values * run pystones three times, reporting values ------------------------------------------------------------------------------ baseline (none of this stuff) Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second ------------------------------------------------------------------------------ baseline + check interval set to 100 Pystone(1.1) time for 50000 passes = 7.64 This machine benchmarks at 6544.5 pystones/second Pystone(1.1) time for 50000 passes = 7.63 This machine benchmarks at 6553.08 pystones/second Pystone(1.1) time for 50000 passes = 7.62 This machine benchmarks at 6561.68 pystones/second ------------------------------------------------------------------------------ global, volatile _Py_Ticker == 10 global, nonvolatile _Py_CheckInterval == 10 Jeremy's Py_AddPendingCall shortcut enabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.7 This machine benchmarks at 6493.51 pystones/second Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second ------------------------------------------------------------------------------ global, volatile _Py_Ticker == 100 global, nonvolatile _Py_CheckInterval == 100 Jeremy's Py_AddPendingCall shortcut enabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.6 This machine benchmarks at 6578.95 pystones/second Pystone(1.1) time for 50000 passes = 7.62 This machine benchmarks at 6561.68 pystones/second ------------------------------------------------------------------------------ global, nonvolatile _Py_Ticker == 100 global, nonvolatile _Py_CheckInterval == 100 Jeremy's Py_AddPendingCall shortcut disabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.66 This machine benchmarks at 6527.42 pystones/second Pystone(1.1) time for 50000 passes = 7.64 This machine benchmarks at 6544.5 pystones/second ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 15:58 Message: Logged In: YES user_id=44345 Sorry, compared to the previous version (_Py_CheckInterval == 10, Jeremy's shortcut installed, but _Py_Ticker not yet declared volatile). My first submission didn't include any performance tests. That was the first thing Guido asked for, so I started running pystones with each change. Let me know what, if anything, you'd like me to report performance-wise. Skip ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 15:02 Message: Logged In: YES user_id=31435 A performance hit compared to what? There are half a dozen variations stacked up now. _Py_CheckInterval is back to 10 in the latest patch, and perhaps that has something to do with it. _Py_CheckInterval needn't be delcared volatile, BTW; i.e., take the "volatile" out of + PyAPI_DATA(volatile int) _Py_CheckInterval; I can't time this today, but you should be just as keen to get x-platform verification when claiming a performance hit as when claiming a performance boost. Chances are that it will slobber all over the place across compilers; ceval is extremely touchy. I'm sitting on a major slowdown under MSCV6 after the SET_LINENO thing, and I'm not panicked about that . ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 14:08 Message: Logged In: YES user_id=44345 This version declares the ticker volatile. Obvious performance hit. Does it need to be volatile if the Jeremy's shortcut is removed? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 13:26 Message: Logged In: YES user_id=44345 bump initial check interval to 100, per request from Tim & Guido. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 12:10 Message: Logged In: YES user_id=31435 Note that the ticker has to be declared volatile. Also """ Py_MakePendingCalls should also be changed then to reset ticker to 0 in its "early exit because the coincidences I'm relying on haven't happened yet" cases. """ You can't predict whether ceval will slow down or speed up, so don't bother with being confused . Get the code right first. Good Things will follow. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 11:53 Message: Logged In: YES user_id=44345 Here's a new version that includes Jeremy's shortcut. With _Py_CheckInterval initialized to 10 here are the pystones numbers I get: with my initial patch & Jeremy's ticker shortcut: Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.65 This machine benchmarks at 6535.95 pystones/second back to just my initial patch without the shortcut: Pystone(1.1) time for 50000 passes = 7.59 This machine benchmarks at 6587.62 pystones/second Pystone(1.1) time for 50000 passes = 7.56 This machine benchmarks at 6613.76 pystones/second Pystone(1.1) time for 50000 passes = 7.56 This machine benchmarks at 6613.76 pystones/second I'm perplexed by the performance difference. Again, I think these performance numbers should be checked by some other people. BTW, I configured with OPT=-O3 ../configure in my build directory. I'm using gcc 2.96 and glibc 2.2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 11:01 Message: Logged In: YES user_id=31435 I'd be more interested in a patch that also implemented Jeremy's suggestion. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 10:43 Message: Logged In: YES user_id=44345 minor correction to the patch - initialize both _Py_CheckInterval and _Py_Ticker to 10 so direct pystones comparisons can be made. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 23:15 Message: Logged In: YES user_id=44345 Here's an updated patch. It creates two internal globals, _Py_Ticker and _Py_CheckInterval. They are accessed from sysmodule.c, ceval.c and longobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602191&group_id=5470 From noreply@sourceforge.net Tue Sep 3 21:25:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 13:25:06 -0700 Subject: [Patches] [ python-Patches-602191 ] single shared ticker Message-ID: Patches item #602191, was opened at 2002-08-29 21:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602191&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: single shared ticker Initial Comment: Per discussion on python-dev, here's a patch that gets rid of the per-thread ticker, instead sharing a single one amongst all threads (and long ints). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-03 15:25 Message: Logged In: YES user_id=44345 oops, and Python/pystate.c 2.21 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-03 15:13 Message: Logged In: YES user_id=44345 Implemented as Include/pystate.h 2.20 Include/ceval.h 2.46 Python/ceval.c 2.334 Python/sysmodule.c 2.110 Objects/longobject.c 1.143 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-03 13:46 Message: Logged In: YES user_id=31435 I get a 1.5% speedup on Win2K, baseline versus whatever this patch does. Go for it, Skip, as I said before, """ _Py_CheckInterval needn't be delcared volatile, BTW; i.e., take the "volatile" out of + PyAPI_DATA(volatile int) _Py_CheckInterval; """ The patch won't compile under MSVC6 unless this is done (as is, the declaration conflicts with the definition). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 13:21 Message: Logged In: YES user_id=6380 FWIW, I measure a similar slowdown with the latest patch, compared to current CVS. But I still think it's good to check this in now, Skip. Then in a separate patch we'll increment Py_CheckInterval to 100. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 17:36 Message: Logged In: YES user_id=44345 I just went back and re-ran everything. Here are the results. methodology: * adjust source * recompile (always gcc 2.96 w/ -O3) * run pystones twice, ignoring values * run pystones three times, reporting values ------------------------------------------------------------------------------ baseline (none of this stuff) Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second ------------------------------------------------------------------------------ baseline + check interval set to 100 Pystone(1.1) time for 50000 passes = 7.64 This machine benchmarks at 6544.5 pystones/second Pystone(1.1) time for 50000 passes = 7.63 This machine benchmarks at 6553.08 pystones/second Pystone(1.1) time for 50000 passes = 7.62 This machine benchmarks at 6561.68 pystones/second ------------------------------------------------------------------------------ global, volatile _Py_Ticker == 10 global, nonvolatile _Py_CheckInterval == 10 Jeremy's Py_AddPendingCall shortcut enabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.7 This machine benchmarks at 6493.51 pystones/second Pystone(1.1) time for 50000 passes = 7.68 This machine benchmarks at 6510.42 pystones/second ------------------------------------------------------------------------------ global, volatile _Py_Ticker == 100 global, nonvolatile _Py_CheckInterval == 100 Jeremy's Py_AddPendingCall shortcut enabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.6 This machine benchmarks at 6578.95 pystones/second Pystone(1.1) time for 50000 passes = 7.62 This machine benchmarks at 6561.68 pystones/second ------------------------------------------------------------------------------ global, nonvolatile _Py_Ticker == 100 global, nonvolatile _Py_CheckInterval == 100 Jeremy's Py_AddPendingCall shortcut disabled Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.66 This machine benchmarks at 6527.42 pystones/second Pystone(1.1) time for 50000 passes = 7.64 This machine benchmarks at 6544.5 pystones/second ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 15:58 Message: Logged In: YES user_id=44345 Sorry, compared to the previous version (_Py_CheckInterval == 10, Jeremy's shortcut installed, but _Py_Ticker not yet declared volatile). My first submission didn't include any performance tests. That was the first thing Guido asked for, so I started running pystones with each change. Let me know what, if anything, you'd like me to report performance-wise. Skip ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 15:02 Message: Logged In: YES user_id=31435 A performance hit compared to what? There are half a dozen variations stacked up now. _Py_CheckInterval is back to 10 in the latest patch, and perhaps that has something to do with it. _Py_CheckInterval needn't be delcared volatile, BTW; i.e., take the "volatile" out of + PyAPI_DATA(volatile int) _Py_CheckInterval; I can't time this today, but you should be just as keen to get x-platform verification when claiming a performance hit as when claiming a performance boost. Chances are that it will slobber all over the place across compilers; ceval is extremely touchy. I'm sitting on a major slowdown under MSCV6 after the SET_LINENO thing, and I'm not panicked about that . ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 14:08 Message: Logged In: YES user_id=44345 This version declares the ticker volatile. Obvious performance hit. Does it need to be volatile if the Jeremy's shortcut is removed? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 13:26 Message: Logged In: YES user_id=44345 bump initial check interval to 100, per request from Tim & Guido. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 12:10 Message: Logged In: YES user_id=31435 Note that the ticker has to be declared volatile. Also """ Py_MakePendingCalls should also be changed then to reset ticker to 0 in its "early exit because the coincidences I'm relying on haven't happened yet" cases. """ You can't predict whether ceval will slow down or speed up, so don't bother with being confused . Get the code right first. Good Things will follow. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 11:53 Message: Logged In: YES user_id=44345 Here's a new version that includes Jeremy's shortcut. With _Py_CheckInterval initialized to 10 here are the pystones numbers I get: with my initial patch & Jeremy's ticker shortcut: Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.67 This machine benchmarks at 6518.9 pystones/second Pystone(1.1) time for 50000 passes = 7.65 This machine benchmarks at 6535.95 pystones/second back to just my initial patch without the shortcut: Pystone(1.1) time for 50000 passes = 7.59 This machine benchmarks at 6587.62 pystones/second Pystone(1.1) time for 50000 passes = 7.56 This machine benchmarks at 6613.76 pystones/second Pystone(1.1) time for 50000 passes = 7.56 This machine benchmarks at 6613.76 pystones/second I'm perplexed by the performance difference. Again, I think these performance numbers should be checked by some other people. BTW, I configured with OPT=-O3 ../configure in my build directory. I'm using gcc 2.96 and glibc 2.2.4. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-08-30 11:01 Message: Logged In: YES user_id=31435 I'd be more interested in a patch that also implemented Jeremy's suggestion. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 10:43 Message: Logged In: YES user_id=44345 minor correction to the patch - initialize both _Py_CheckInterval and _Py_Ticker to 10 so direct pystones comparisons can be made. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-29 23:15 Message: Logged In: YES user_id=44345 Here's an updated patch. It creates two internal globals, _Py_Ticker and _Py_CheckInterval. They are accessed from sysmodule.c, ceval.c and longobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602191&group_id=5470 From noreply@sourceforge.net Tue Sep 3 21:22:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 13:22:13 -0700 Subject: [Patches] [ python-Patches-597907 ] Oren Tirosh's fastnames patch Message-ID: Patches item #597907, was opened at 2002-08-20 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Oren Tirosh's fastnames patch Initial Comment: Oren Tirosh had a nice patch to *really* speed up global/builtin name lookup. I'm adding it here because I don't want to lose this idea. His code and some comments are here: http://www.tothink.com/python/fastnames/ I'm uploading a new version of this patch relative to current CVS. I'm still considering whether to do this; I measure at best a 1% speedup for pystone. For a modified version of Oren's benchmark (modified to use a function instead of a class for 'builtin' and 'global', so that these tests use LOAD_GLOBAL rather than LOAD_NAME, I get these test results (best of 3): builtin 1.38 global 1.54 local 1.28 fastlocal 0.90 Python 2.3 without his patch (but with my speedup hacks in LOAD_GLOBAL): builtin 1.80 global 1.52 local 1.77 fastlocal 0.91 Python 2.2 (from the 2.2 branch, which is newer than the 2.2.1 release but doesn't have any speedups) did this: builtin 2.28 global 1.86 local 1.80 fastlocal 1.10 I don't care about the speedup for the 'local' case, since this uses the LOAD_NAME opcode which is only used inside class definitions; the 'builtin' and 'global' cases are interesting. It looks like Oren's patch gives us a nice speedup for looking up a built-in name from a function. I have to think about why looking up a global from a function is slower though... ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-03 20:22 Message: Logged In: YES user_id=562624 > I'm still considering whether to do this; I measure at > best a 1% speedup for pystone. No surprising considering the fact that pystone is dominated by fastlocals (IIRC it was something like 99.7% according to my instrumented version). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 18:29 Message: Logged In: YES user_id=6380 OK. I'm holding my breath! :-) ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-02 19:59 Message: Logged In: YES user_id=562624 I'm working on an improved version. Stay tuned! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-20 19:31 Message: Logged In: YES user_id=6380 Tim explained why the 'globals' case is faster than the 'builtins' case. I used 'x' as the global to look up rather than 'hex', and it so happens that the last three bits of hash('x') and hash('MANY') are the same -- MANY is an identifier I insert in the globals. I'll attach the test suite I used (with 'hex' instead of 'x'). Now I get these times: builtin 1.39 global 1.28 local 1.29 fastlocal 0.91 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 From noreply@sourceforge.net Tue Sep 3 21:21:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 13:21:45 -0700 Subject: [Patches] [ python-Patches-544740 ] test_commands test fails under Cygwin Message-ID: Patches item #544740, was opened at 2002-04-16 18:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: test_commands test fails under Cygwin Initial Comment: The Python 2.2.1 test_commands regression test fails under Cygwin 1.3.10 because the regular expression is pickier now and because Cygwin can have spaces in user and/or group names. See the following for some more details: http://cygwin.com/ml/cygwin/2002-04/msg00774.html and a workaround. I'm submitting this as a bug report instead of a patch because I don't know the best way to fix this issue. Can test_commands use numeric IDs instead of names? Should I discuss this issue on python-dev instead of here? BTW, please add a "Test" category to the available choices for Bugs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 16:14 Message: Logged In: YES user_id=21627 This patch won't work in other locales. E.g. in de_DE, a date might read Mär 21 01:14 which won't match your regexp. Furthermore, recent GNU fileutils format it as 2002-09-02 10:12 in non-C locales, which is even further away. In theory, putting LC_ALL=C into the environment should solve this, but it would be better to not rely on the date formatting. Why do you have to put an explicit format string for the date in there? What specific change made the expression "pickier"? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-08-27 20:12 Message: Logged In: YES user_id=86216 Attached is a patch to fix this problem. As suggested by Guido, I am proposing a "better" regular expression. Unfortunately, I had to make an assumption on the date format in order to match the user and group names regardless of the number of embedded spaces. Is my date regular expression acceptable? Will it work in non US locales? FWIW, I tested under Cygwin and Red Hat Linux 7.1 without any ill effects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 17:48 Message: Logged In: YES user_id=33168 Jason, I presume this is still a problem. It probably would be a good idea to discuss on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 From noreply@sourceforge.net Tue Sep 3 22:47:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 14:47:09 -0700 Subject: [Patches] [ python-Patches-604209 ] release GIL before calling getaddrinfo() Message-ID: Patches item #604209, was opened at 2002-09-03 21:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604209&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Martin v. Löwis (loewis) Summary: release GIL before calling getaddrinfo() Initial Comment: Index: socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.244 diff -c -c -r1.244 socketmodule.c *** socketmodule.c 3 Sep 2002 19:10:18 -0000 1.244 --- socketmodule.c 3 Sep 2002 21:46:35 -0000 *************** *** 500,506 **** /* Do a select() on the socket, if necessary (sock_timeout > 0). The argument writing indicates the direction. This does not raise an exception or return a success indicator; ! we'll let the actual socket call do that. */ static void internal_select(PySocketSockObject *s, int writing) { --- 500,507 ---- /* Do a select() on the socket, if necessary (sock_timeout > 0). The argument writing indicates the direction. This does not raise an exception or return a success indicator; ! we'll let the actual socket call do that. ! */ static void internal_select(PySocketSockObject *s, int writing) { *************** *** 596,606 **** --- 597,609 ---- memset((void *) addr_ret, '\0', sizeof(*addr_ret)); if (name[0] == '\0') { int siz; + Py_BEGIN_ALLOW_THREADS memset(&hints, 0, sizeof(hints)); hints.ai_family = af; hints.ai_socktype = SOCK_DGRAM; /*dummy*/ hints.ai_flags = AI_PASSIVE; error = getaddrinfo(NULL, "0", &hints, &res); + Py_END_ALLOW_THREADS if (error) { set_gaierror(error); return -1; *************** *** 648,653 **** --- 651,657 ---- sin->sin_addr.s_addr = INADDR_BROADCAST; return sizeof(sin->sin_addr); } + Py_BEGIN_ALLOW_THREADS memset(&hints, 0, sizeof(hints)); hints.ai_family = af; error = getaddrinfo(name, NULL, &hints, &res); *************** *** 659,664 **** --- 663,669 ---- error = getaddrinfo(name, NULL, &hints, &res); } #endif + Py_END_ALLOW_THREADS if (error) { set_gaierror(error); return -1; *************** *** 849,855 **** } if (!PyArg_ParseTuple(args, "si:getsockaddrarg", &host, &port)) return 0; ! if (setipaddr(host, (struct sockaddr *)addr, sizeof(*addr), AF_INET) < 0) return 0; addr->sin_family = AF_INET; addr->sin_port = htons((short)port); --- 854,861 ---- } if (!PyArg_ParseTuple(args, "si:getsockaddrarg", &host, &port)) return 0; ! if (setipaddr(host, (struct sockaddr *)addr, sizeof(*addr), ! AF_INET) < 0) return 0; addr->sin_family = AF_INET; addr->sin_port = htons((short)port); *************** *** 2676,2687 **** --- 2682,2695 ---- PyErr_SetString(socket_error, "Int or String expected"); return NULL; } + Py_BEGIN_ALLOW_THREADS memset(&hints, 0, sizeof(hints)); hints.ai_family = family; hints.ai_socktype = socktype; hints.ai_protocol = protocol; hints.ai_flags = flags; error = getaddrinfo(hptr, pptr, &hints, &res0); + Py_END_ALLOW_THREADS if (error) { set_gaierror(error); return NULL; *************** *** 2745,2754 **** --- 2753,2764 ---- &hostp, &port, &flowinfo, &scope_id)) return NULL; PyOS_snprintf(pbuf, sizeof(pbuf), "%d", port); + Py_BEGIN_ALLOW_THREADS memset(&hints, 0, sizeof(hints)); hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; /* make numeric port happy */ error = getaddrinfo(hostp, pbuf, &hints, &res); + Py_END_ALLOW_THREADS if (error) { set_gaierror(error); goto fail; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604209&group_id=5470 From noreply@sourceforge.net Tue Sep 3 22:47:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 14:47:38 -0700 Subject: [Patches] [ python-Patches-604209 ] release GIL before calling getaddrinfo() Message-ID: Patches item #604209, was opened at 2002-09-03 21:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604209&group_id=5470 Category: Modules Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Martin v. Löwis (loewis) Summary: release GIL before calling getaddrinfo() Initial Comment: Index: socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.244 diff -c -c -r1.244 socketmodule.c *** socketmodule.c 3 Sep 2002 19:10:18 -0000 1.244 --- socketmodule.c 3 Sep 2002 21:46:35 -0000 *************** *** 500,506 **** /* Do a select() on the socket, if necessary (sock_timeout > 0). The argument writing indicates the direction. This does not raise an exception or return a success indicator; ! we'll let the actual socket call do that. */ static void internal_select(PySocketSockObject *s, int writing) { --- 500,507 ---- /* Do a select() on the socket, if necessary (sock_timeout > 0). The argument writing indicates the direction. This does not raise an exception or return a success indicator; ! we'll let the actual socket call do that. ! */ static void internal_select(PySocketSockObject *s, int writing) { *************** *** 596,606 **** --- 597,609 ---- memset((void *) addr_ret, '\0', sizeof(*addr_ret)); if (name[0] == '\0') { int siz; + Py_BEGIN_ALLOW_THREADS memset(&hints, 0, sizeof(hints)); hints.ai_family = af; hints.ai_socktype = SOCK_DGRAM; /*dummy*/ hints.ai_flags = AI_PASSIVE; error = getaddrinfo(NULL, "0", &hints, &res); + Py_END_ALLOW_THREADS if (error) { set_gaierror(error); return -1; *************** *** 648,653 **** --- 651,657 ---- sin->sin_addr.s_addr = INADDR_BROADCAST; return sizeof(sin->sin_addr); } + Py_BEGIN_ALLOW_THREADS memset(&hints, 0, sizeof(hints)); hints.ai_family = af; error = getaddrinfo(name, NULL, &hints, &res); *************** *** 659,664 **** --- 663,669 ---- error = getaddrinfo(name, NULL, &hints, &res); } #endif + Py_END_ALLOW_THREADS if (error) { set_gaierror(error); return -1; *************** *** 849,855 **** } if (!PyArg_ParseTuple(args, "si:getsockaddrarg", &host, &port)) return 0; ! if (setipaddr(host, (struct sockaddr *)addr, sizeof(*addr), AF_INET) < 0) return 0; addr->sin_family = AF_INET; addr->sin_port = htons((short)port); --- 854,861 ---- } if (!PyArg_ParseTuple(args, "si:getsockaddrarg", &host, &port)) return 0; ! if (setipaddr(host, (struct sockaddr *)addr, sizeof(*addr), ! AF_INET) < 0) return 0; addr->sin_family = AF_INET; addr->sin_port = htons((short)port); *************** *** 2676,2687 **** --- 2682,2695 ---- PyErr_SetString(socket_error, "Int or String expected"); return NULL; } + Py_BEGIN_ALLOW_THREADS memset(&hints, 0, sizeof(hints)); hints.ai_family = family; hints.ai_socktype = socktype; hints.ai_protocol = protocol; hints.ai_flags = flags; error = getaddrinfo(hptr, pptr, &hints, &res0); + Py_END_ALLOW_THREADS if (error) { set_gaierror(error); return NULL; *************** *** 2745,2754 **** --- 2753,2764 ---- &hostp, &port, &flowinfo, &scope_id)) return NULL; PyOS_snprintf(pbuf, sizeof(pbuf), "%d", port); + Py_BEGIN_ALLOW_THREADS memset(&hints, 0, sizeof(hints)); hints.ai_family = PF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; /* make numeric port happy */ error = getaddrinfo(hostp, pbuf, &hints, &res); + Py_END_ALLOW_THREADS if (error) { set_gaierror(error); goto fail; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604209&group_id=5470 From noreply@sourceforge.net Tue Sep 3 22:48:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 14:48:41 -0700 Subject: [Patches] [ python-Patches-604210 ] release GIL around getaddrinfo() Message-ID: Patches item #604210, was opened at 2002-09-03 21:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Martin v. Löwis (loewis) Summary: release GIL around getaddrinfo() Initial Comment: If getaddrinfo() is thread-safe, then we should release the interpreter lock before calling it. There is every reason to believe that this operation will be slow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 From noreply@sourceforge.net Tue Sep 3 22:51:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 14:51:06 -0700 Subject: [Patches] [ python-Patches-602108 ] improper use of strncpy in getpath Message-ID: Patches item #602108, was opened at 2002-08-29 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: Rejected Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: improper use of strncpy in getpath Initial Comment: Many uses of strncpy() in Modules/getpath and PC/getpathp do not copy the terminating null character onto the string. This patch makes sure the strings are null terminated after strncpy(). Should this be backported? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 17:51 Message: Logged In: YES user_id=33168 You are correct. There should always be a null byte since all the variables are static. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:55 Message: Logged In: YES user_id=6380 Since the variables affected are all globals, there is already a null byte in the final position. So there's no need to write one explicitly. I therefore reject this patch. I'm leaving it open in case I'm misunderstanding something. If you agree, please close it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 From noreply@sourceforge.net Wed Sep 4 07:25:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Sep 2002 23:25:19 -0700 Subject: [Patches] [ python-Patches-604210 ] release GIL around getaddrinfo() Message-ID: Patches item #604210, was opened at 2002-09-03 23:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Martin v. Löwis (loewis) Summary: release GIL around getaddrinfo() Initial Comment: If getaddrinfo() is thread-safe, then we should release the interpreter lock before calling it. There is every reason to believe that this operation will be slow. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 08:25 Message: Logged In: YES user_id=21627 How do you know getaddrinfo is thread-safe? In particular, when using the getaddrinfo emulation, it is not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 From noreply@sourceforge.net Wed Sep 4 09:57:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 01:57:39 -0700 Subject: [Patches] [ python-Patches-604210 ] release GIL around getaddrinfo() Message-ID: Patches item #604210, was opened at 2002-09-03 23:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: Jeremy Hylton (jhylton) Summary: release GIL around getaddrinfo() Initial Comment: If getaddrinfo() is thread-safe, then we should release the interpreter lock before calling it. There is every reason to believe that this operation will be slow. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 08:25 Message: Logged In: YES user_id=21627 How do you know getaddrinfo is thread-safe? In particular, when using the getaddrinfo emulation, it is not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 From noreply@sourceforge.net Wed Sep 4 13:06:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 05:06:52 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 13:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 14:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 15:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Wed Sep 4 15:23:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 07:23:42 -0700 Subject: [Patches] [ python-Patches-601369 ] obmalloc,structmodule: 64bit, big endian Message-ID: Patches item #601369, was opened at 2002-08-28 18:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 Category: Modules Group: Python 2.2.x Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Guido van Rossum (gvanrossum) Summary: obmalloc,structmodule: 64bit, big endian Initial Comment: Issue 1: in Objects/obmalloc.c, SYSTEM_PAGE_SIZE is assumed to be 4K. I corrected (#if _MIPS_ABI>=4) the page size at least for 64bit SGI Irix machines. Issue 2: in Modules/structmodule.c, most of the un/packing functions assumed that the char *p argument (destination or source for un/packing) is correctly aligned for the concerned type. It is no problem for x86 processors (2 cycle access instead of 1 if unaligned), but it is a problem for 64bit MIPS processors (where an int is 64bit and it must be at least on a 4-byte boundary). All the functions handling types larger than 1 byte use memcpy now, taking care of endianess with an intermediate variable y wherever needed. The sparse comments stating "p may not be properly aligned" are removed, and a more thorough comment is inserted before the definitions of the un/packing functions. The patched module passes test_struct fine in 64-bit and 32-bit builds on an SGI Octane with MIPS cc; so it does on a Pentium Linux with gcc. I have no way to make a Windows build. Pack formats prefixed with '!' or '>' produce the same sizes everywhere. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2002-09-04 17:23 Message: Logged In: YES user_id=539787 Tim is probably right. Compiled obmalloc.c with PYMALLOC_DEBUG and running test.testall with PYTHONMALLOCSTATS, here are some statistics results: 4K maximum numbers: # bytes in allocated blocks = 33,964,192 # bytes in available blocks = 63,056 # bytes lost to pool headers = 405,216 # bytes lost to quantization = 145,968 # bytes lost to arena alignment = 548,864 16K maximum numbers: # bytes in allocated blocks = 33,970,384 # bytes in available blocks = 289,824 # bytes lost to pool headers = 100,800 # bytes lost to quantization = 45,392 # bytes lost to arena alignment = 2,293,760 The overall size of the python process remained in both cases at 223MB the most. I don't think I should research more into it. I will try to make a patch for the current 2.2 branch too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 21:43 Message: Logged In: YES user_id=6380 Tim sez, the obmalloc.c patch should not go in unless supported by measurements. I do like the structmodule.c patch, and have check it in. Thanks! PS the structmodule patch might apply to Python 2.2.x too. Somebody should backport it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 From noreply@sourceforge.net Wed Sep 4 15:55:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 07:55:48 -0700 Subject: [Patches] [ python-Patches-601369 ] obmalloc,structmodule: 64bit, big endian Message-ID: Patches item #601369, was opened at 2002-08-28 11:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 Category: Modules Group: Python 2.2.x >Status: Open Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) >Assigned to: Tim Peters (tim_one) Summary: obmalloc,structmodule: 64bit, big endian Initial Comment: Issue 1: in Objects/obmalloc.c, SYSTEM_PAGE_SIZE is assumed to be 4K. I corrected (#if _MIPS_ABI>=4) the page size at least for 64bit SGI Irix machines. Issue 2: in Modules/structmodule.c, most of the un/packing functions assumed that the char *p argument (destination or source for un/packing) is correctly aligned for the concerned type. It is no problem for x86 processors (2 cycle access instead of 1 if unaligned), but it is a problem for 64bit MIPS processors (where an int is 64bit and it must be at least on a 4-byte boundary). All the functions handling types larger than 1 byte use memcpy now, taking care of endianess with an intermediate variable y wherever needed. The sparse comments stating "p may not be properly aligned" are removed, and a more thorough comment is inserted before the definitions of the un/packing functions. The patched module passes test_struct fine in 64-bit and 32-bit builds on an SGI Octane with MIPS cc; so it does on a Pentium Linux with gcc. I have no way to make a Windows build. Pack formats prefixed with '!' or '>' produce the same sizes everywhere. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-04 10:55 Message: Logged In: YES user_id=6380 I'll leave it to Tim to comment on those numbers. A different question is, did you measure a speedup by matching the system page size? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 10:23 Message: Logged In: YES user_id=539787 Tim is probably right. Compiled obmalloc.c with PYMALLOC_DEBUG and running test.testall with PYTHONMALLOCSTATS, here are some statistics results: 4K maximum numbers: # bytes in allocated blocks = 33,964,192 # bytes in available blocks = 63,056 # bytes lost to pool headers = 405,216 # bytes lost to quantization = 145,968 # bytes lost to arena alignment = 548,864 16K maximum numbers: # bytes in allocated blocks = 33,970,384 # bytes in available blocks = 289,824 # bytes lost to pool headers = 100,800 # bytes lost to quantization = 45,392 # bytes lost to arena alignment = 2,293,760 The overall size of the python process remained in both cases at 223MB the most. I don't think I should research more into it. I will try to make a patch for the current 2.2 branch too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:43 Message: Logged In: YES user_id=6380 Tim sez, the obmalloc.c patch should not go in unless supported by measurements. I do like the structmodule.c patch, and have check it in. Thanks! PS the structmodule patch might apply to Python 2.2.x too. Somebody should backport it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 From noreply@sourceforge.net Wed Sep 4 17:11:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 09:11:57 -0700 Subject: [Patches] [ python-Patches-601369 ] obmalloc,structmodule: 64bit, big endian Message-ID: Patches item #601369, was opened at 2002-08-28 18:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Tim Peters (tim_one) Summary: obmalloc,structmodule: 64bit, big endian Initial Comment: Issue 1: in Objects/obmalloc.c, SYSTEM_PAGE_SIZE is assumed to be 4K. I corrected (#if _MIPS_ABI>=4) the page size at least for 64bit SGI Irix machines. Issue 2: in Modules/structmodule.c, most of the un/packing functions assumed that the char *p argument (destination or source for un/packing) is correctly aligned for the concerned type. It is no problem for x86 processors (2 cycle access instead of 1 if unaligned), but it is a problem for 64bit MIPS processors (where an int is 64bit and it must be at least on a 4-byte boundary). All the functions handling types larger than 1 byte use memcpy now, taking care of endianess with an intermediate variable y wherever needed. The sparse comments stating "p may not be properly aligned" are removed, and a more thorough comment is inserted before the definitions of the un/packing functions. The patched module passes test_struct fine in 64-bit and 32-bit builds on an SGI Octane with MIPS cc; so it does on a Pentium Linux with gcc. I have no way to make a Windows build. Pack formats prefixed with '!' or '>' produce the same sizes everywhere. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2002-09-04 19:11 Message: Logged In: YES user_id=539787 3 runs of test.pystone.main(), averaged: 16K pool size: 5920 4K pool size: 6120 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-04 17:55 Message: Logged In: YES user_id=6380 I'll leave it to Tim to comment on those numbers. A different question is, did you measure a speedup by matching the system page size? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 17:23 Message: Logged In: YES user_id=539787 Tim is probably right. Compiled obmalloc.c with PYMALLOC_DEBUG and running test.testall with PYTHONMALLOCSTATS, here are some statistics results: 4K maximum numbers: # bytes in allocated blocks = 33,964,192 # bytes in available blocks = 63,056 # bytes lost to pool headers = 405,216 # bytes lost to quantization = 145,968 # bytes lost to arena alignment = 548,864 16K maximum numbers: # bytes in allocated blocks = 33,970,384 # bytes in available blocks = 289,824 # bytes lost to pool headers = 100,800 # bytes lost to quantization = 45,392 # bytes lost to arena alignment = 2,293,760 The overall size of the python process remained in both cases at 223MB the most. I don't think I should research more into it. I will try to make a patch for the current 2.2 branch too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 21:43 Message: Logged In: YES user_id=6380 Tim sez, the obmalloc.c patch should not go in unless supported by measurements. I do like the structmodule.c patch, and have check it in. Thanks! PS the structmodule patch might apply to Python 2.2.x too. Somebody should backport it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 From noreply@sourceforge.net Wed Sep 4 17:21:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 09:21:20 -0700 Subject: [Patches] [ python-Patches-604600 ] For Bug [ 490168 ] shutil.copy(path, pat Message-ID: Patches item #604600, was opened at 2002-09-04 19:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604600&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: For Bug [ 490168 ] shutil.copy(path, pat Initial Comment: As the bug says, shutil.copy(src, dst) deletes the contents of src if it is the same as dst. Example: $ pwd /home/tzot $ echo hello >file01 $ ln file01 file02 $ echo hello >file03 $ ln -s file03 file04 $ echo hello >file05 $ python Python 2.3a0 (#26, Sep 4 2002, 17:39:22) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> from shutil import copyfile >>> copyfile('file01', 'file02') >>> copyfile('file03', 'file04') >>> copyfile('file05', '../tzot/file05') After this sequence, all files have zero length. The patch corrects this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604600&group_id=5470 From noreply@sourceforge.net Wed Sep 4 14:43:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 06:43:39 -0700 Subject: [Patches] [ python-Patches-598163 ] textwrap.dedent, inspect.getdoc-ish Message-ID: Patches item #598163, was opened at 2002-08-21 05:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ville Vainio (vvainio) Assigned to: Greg Ward (gward) Summary: textwrap.dedent, inspect.getdoc-ish Initial Comment: Ability to remove indentation from multiline strings (often triple-quoted). Differs from inspect.getdoc by not handling the first line in special manner (often a sensible approach for non-docstring multiline strings) - which should make this function more general (symmetric 'indent' also possible), and more fitting for the textwrap module. Implementation is for the most parts familiar from inspect.getdoc, though I used sring methods instead of the module 'string'. The module 'textwrap' and the function name 'dedent' were suggested on python-dev a while back (by MAL, IIRC). ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2002-09-04 09:43 Message: Logged In: YES user_id=14422 Looks fine to me. Can you provide a patch for Doc/lib/libtextwrap.tex as well? A patch to Lib/test/test_textwrap.py would be nice too, but I can take care of that if you prefer. (Any other diffs should just be uploaded to this patch report.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:57 Message: Logged In: YES user_id=6380 For Greg Ward. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 From noreply@sourceforge.net Wed Sep 4 20:10:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 12:10:07 -0700 Subject: [Patches] [ python-Patches-601369 ] obmalloc,structmodule: 64bit, big endian Message-ID: Patches item #601369, was opened at 2002-08-28 11:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 Category: Modules Group: Python 2.2.x >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Tim Peters (tim_one) Summary: obmalloc,structmodule: 64bit, big endian Initial Comment: Issue 1: in Objects/obmalloc.c, SYSTEM_PAGE_SIZE is assumed to be 4K. I corrected (#if _MIPS_ABI>=4) the page size at least for 64bit SGI Irix machines. Issue 2: in Modules/structmodule.c, most of the un/packing functions assumed that the char *p argument (destination or source for un/packing) is correctly aligned for the concerned type. It is no problem for x86 processors (2 cycle access instead of 1 if unaligned), but it is a problem for 64bit MIPS processors (where an int is 64bit and it must be at least on a 4-byte boundary). All the functions handling types larger than 1 byte use memcpy now, taking care of endianess with an intermediate variable y wherever needed. The sparse comments stating "p may not be properly aligned" are removed, and a more thorough comment is inserted before the definitions of the un/packing functions. The patched module passes test_struct fine in 64-bit and 32-bit builds on an SGI Octane with MIPS cc; so it does on a Pentium Linux with gcc. I have no way to make a Windows build. Pack formats prefixed with '!' or '>' produce the same sizes everywhere. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-04 15:10 Message: Logged In: YES user_id=31435 AFAIK, you're the first person ever to try changing SYSTEM_PAGE_SIZE. It may (or may not ) work better to boost that while simultaneously changing POOL_SIZE to remain at 4K, or perhaps 8K. In any case, there's no reason I can see to believe that the SYSTEM_PAGE_SIZE value should make any difference in general, provided only that it's a reasonably large power of 2: the system malloc sees Python asking for the much larger ARENA_SIZE bytes at a time regardless of what value SYSTEM_PAGE_SIZE has. Closing this, since there's nothing clear left to be persued here. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 12:11 Message: Logged In: YES user_id=539787 3 runs of test.pystone.main(), averaged: 16K pool size: 5920 4K pool size: 6120 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-04 10:55 Message: Logged In: YES user_id=6380 I'll leave it to Tim to comment on those numbers. A different question is, did you measure a speedup by matching the system page size? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 10:23 Message: Logged In: YES user_id=539787 Tim is probably right. Compiled obmalloc.c with PYMALLOC_DEBUG and running test.testall with PYTHONMALLOCSTATS, here are some statistics results: 4K maximum numbers: # bytes in allocated blocks = 33,964,192 # bytes in available blocks = 63,056 # bytes lost to pool headers = 405,216 # bytes lost to quantization = 145,968 # bytes lost to arena alignment = 548,864 16K maximum numbers: # bytes in allocated blocks = 33,970,384 # bytes in available blocks = 289,824 # bytes lost to pool headers = 100,800 # bytes lost to quantization = 45,392 # bytes lost to arena alignment = 2,293,760 The overall size of the python process remained in both cases at 223MB the most. I don't think I should research more into it. I will try to make a patch for the current 2.2 branch too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:43 Message: Logged In: YES user_id=6380 Tim sez, the obmalloc.c patch should not go in unless supported by measurements. I do like the structmodule.c patch, and have check it in. Thanks! PS the structmodule patch might apply to Python 2.2.x too. Somebody should backport it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601369&group_id=5470 From noreply@sourceforge.net Wed Sep 4 20:20:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 12:20:44 -0700 Subject: [Patches] [ python-Patches-604210 ] release GIL around getaddrinfo() Message-ID: Patches item #604210, was opened at 2002-09-03 21:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: release GIL around getaddrinfo() Initial Comment: If getaddrinfo() is thread-safe, then we should release the interpreter lock before calling it. There is every reason to believe that this operation will be slow. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-09-04 19:20 Message: Logged In: YES user_id=31392 The getaddrinfo() on Linux says it thread-safe. It's a name-fangled call. Is it part of some standard? It would certainly be possible to make the fallback implementation thread-safe. Or, if we don't believe it is thread-safe, we could add a separate lock to protect it. The socket module of 2.1 vintage had a separate lock for this purpose. And the 2.1 vintage Python performs much better when a multi-threaded app does DNS lookups. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 06:25 Message: Logged In: YES user_id=21627 How do you know getaddrinfo is thread-safe? In particular, when using the getaddrinfo emulation, it is not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 From noreply@sourceforge.net Wed Sep 4 21:18:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Sep 2002 13:18:03 -0700 Subject: [Patches] [ python-Patches-604210 ] release GIL around getaddrinfo() Message-ID: Patches item #604210, was opened at 2002-09-03 17:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: release GIL around getaddrinfo() Initial Comment: If getaddrinfo() is thread-safe, then we should release the interpreter lock before calling it. There is every reason to believe that this operation will be slow. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-04 16:18 Message: Logged In: YES user_id=33168 I looked on OpenBSD (I think, may have been NetBSD) and FreeBSD. The man pages were the same, both old (circa 1995), but they said their implementation was not thread-safe. I did a man on Dec UNIX and it said it conformed to POSIX.1g Draft 6.6, but didn't indicate if it was thread safe. Solaris 8 doesn't say anything in the man page. Here's a NetBSD 1.6 man page dated 2002/05/14 and it's still not thread-safe: http://216.239.37.100/search?q=cache:4bTvQQqcwq4C:www.tac.eu.org/cgi-bin/man-cgi%3Fgetaddrinfo%2B3+getaddrinfo+thread+safe&hl=en&ie=UTF-8 This: http://216.239.33.100/search?q=cache:q5egqJ5_mv4C:mail.gnu.org/pipermail/guile-devel/2001-October/004039.html+getaddrinfo+thread+safe&hl=en&ie=UTF-8 says "getaddrinfo and getnameinfo are the recommended APIs. They avoid hidden static data; they're supposed to be thread-safe; they handle multiple address families." It seems safest to do what Jeremy proposes and add a lock. There can always be a define if getaddrinfo is thread safe or not. Maybe we can even determine with autoconf. Note: I get much better performance with this patch under linux. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-04 15:20 Message: Logged In: YES user_id=31392 The getaddrinfo() on Linux says it thread-safe. It's a name-fangled call. Is it part of some standard? It would certainly be possible to make the fallback implementation thread-safe. Or, if we don't believe it is thread-safe, we could add a separate lock to protect it. The socket module of 2.1 vintage had a separate lock for this purpose. And the 2.1 vintage Python performs much better when a multi-threaded app does DNS lookups. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 02:25 Message: Logged In: YES user_id=21627 How do you know getaddrinfo is thread-safe? In particular, when using the getaddrinfo emulation, it is not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 From noreply@sourceforge.net Thu Sep 5 14:30:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 06:30:12 -0700 Subject: [Patches] [ python-Patches-603831 ] ccompiler argument checking too strict Message-ID: Patches item #603831, was opened at 2002-09-03 01:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603831&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Moshe Zadka (moshez) Assigned to: A.M. Kuchling (akuchling) Summary: ccompiler argument checking too strict Initial Comment: ccompiler's argument checking prevents the check_header functionality. The patch found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=159288&repeatmerged=yes is a workaround -- there are possibly better workarounds, but this one is easy and works. Thanks. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-09-05 09:30 Message: Logged In: YES user_id=11375 The patch looks fine to me; feel free to check it in. (Should probably mark it a bugfix candidate.) However, can you provide an example setup.py? With the suggested patch, check_header() still fails for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603831&group_id=5470 From noreply@sourceforge.net Thu Sep 5 09:38:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 01:38:49 -0700 Subject: [Patches] [ python-Patches-604210 ] release GIL around getaddrinfo() Message-ID: Patches item #604210, was opened at 2002-09-03 23:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: release GIL around getaddrinfo() Initial Comment: If getaddrinfo() is thread-safe, then we should release the interpreter lock before calling it. There is every reason to believe that this operation will be slow. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-05 10:38 Message: Logged In: YES user_id=21627 RFC 2553 specifies that getaddrinfo, getipnodebyname, and all the other new netdb functions must be thread-safe - hence the BSD man pages document it as a bug that they are not. So adding an additional lock, in general, might be overkill. I'd suggest a strategy that assumes, in general, that getaddrinfo is thread-safe. If it isn't (by hard-coded knowledge), I'd propose just to continue using the interpreter lock - those systems deserve to lose. As for the fallback implementation - feel free to do anything about it that you can find the time for. Recording it as thread-unsafe might be fine, adding a lock is another option, using the thread-safe API inside the fallback (where available) is a third option. I would not care too much, except that this is used on Windows. Notice that it won't be used on Windows if Python is compiled with VC.NET, since that provides a "native" getaddrinfo (and Python knows that it does). So if Python 2.3 is going to be compiled with VC.NET, I would not worry about the fallback implementation at all. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-04 22:18 Message: Logged In: YES user_id=33168 I looked on OpenBSD (I think, may have been NetBSD) and FreeBSD. The man pages were the same, both old (circa 1995), but they said their implementation was not thread-safe. I did a man on Dec UNIX and it said it conformed to POSIX.1g Draft 6.6, but didn't indicate if it was thread safe. Solaris 8 doesn't say anything in the man page. Here's a NetBSD 1.6 man page dated 2002/05/14 and it's still not thread-safe: http://216.239.37.100/search?q=cache:4bTvQQqcwq4C:www.tac.eu.org/cgi-bin/man-cgi%3Fgetaddrinfo%2B3+getaddrinfo+thread+safe&hl=en&ie=UTF-8 This: http://216.239.33.100/search?q=cache:q5egqJ5_mv4C:mail.gnu.org/pipermail/guile-devel/2001-October/004039.html+getaddrinfo+thread+safe&hl=en&ie=UTF-8 says "getaddrinfo and getnameinfo are the recommended APIs. They avoid hidden static data; they're supposed to be thread-safe; they handle multiple address families." It seems safest to do what Jeremy proposes and add a lock. There can always be a define if getaddrinfo is thread safe or not. Maybe we can even determine with autoconf. Note: I get much better performance with this patch under linux. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-04 21:20 Message: Logged In: YES user_id=31392 The getaddrinfo() on Linux says it thread-safe. It's a name-fangled call. Is it part of some standard? It would certainly be possible to make the fallback implementation thread-safe. Or, if we don't believe it is thread-safe, we could add a separate lock to protect it. The socket module of 2.1 vintage had a separate lock for this purpose. And the 2.1 vintage Python performs much better when a multi-threaded app does DNS lookups. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 08:25 Message: Logged In: YES user_id=21627 How do you know getaddrinfo is thread-safe? In particular, when using the getaddrinfo emulation, it is not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604210&group_id=5470 From noreply@sourceforge.net Thu Sep 5 14:45:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 06:45:42 -0700 Subject: [Patches] [ python-Patches-603831 ] ccompiler argument checking too strict Message-ID: Patches item #603831, was opened at 2002-09-03 01:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603831&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Moshe Zadka (moshez) Assigned to: A.M. Kuchling (akuchling) Summary: ccompiler argument checking too strict Initial Comment: ccompiler's argument checking prevents the check_header functionality. The patch found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=159288&repeatmerged=yes is a workaround -- there are possibly better workarounds, but this one is easy and works. Thanks. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-09-05 09:45 Message: Logged In: YES user_id=11375 After some more poking, I think the following other two changes are needed (providing a body to try_cpp(), and using the source file name in preprocess()). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-09-05 09:30 Message: Logged In: YES user_id=11375 The patch looks fine to me; feel free to check it in. (Should probably mark it a bugfix candidate.) However, can you provide an example setup.py? With the suggested patch, check_header() still fails for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=603831&group_id=5470 From noreply@sourceforge.net Thu Sep 5 21:32:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 13:32:01 -0700 Subject: [Patches] [ python-Patches-602108 ] improper use of strncpy in getpath Message-ID: Patches item #602108, was opened at 2002-08-29 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) Summary: improper use of strncpy in getpath Initial Comment: Many uses of strncpy() in Modules/getpath and PC/getpathp do not copy the terminating null character onto the string. This patch makes sure the strings are null terminated after strncpy(). Should this be backported? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-05 16:32 Message: Logged In: YES user_id=33168 I spoke too soon. Not all the variables are global static. In Modules/getpath.c::calculate_path() (line 363), argv0_path is a local, non-static variable. In the original patch, this was set to the null char in 4 places. I think it would be easier to do: argv0_path[MAXPATHLEN] = '\0'; once, before argv0_path is used rather than after each strncpy(). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 17:51 Message: Logged In: YES user_id=33168 You are correct. There should always be a null byte since all the variables are static. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:55 Message: Logged In: YES user_id=6380 Since the variables affected are all globals, there is already a null byte in the final position. So there's no need to write one explicitly. I therefore reject this patch. I'm leaving it open in case I'm misunderstanding something. If you agree, please close it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 From noreply@sourceforge.net Fri Sep 6 03:37:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 19:37:41 -0700 Subject: [Patches] [ python-Patches-605370 ] nntplib: group descriptions and RFC2980 Message-ID: Patches item #605370, was opened at 2002-09-06 04:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jürgen A. Erhard (jae) Assigned to: Nobody/Anonymous (nobody) Summary: nntplib: group descriptions and RFC2980 Initial Comment: nntplib's NNTP.xgtitle() is deprecated by RFC2980. And some servers (like leafnode) don't even know XGTITLE. This adds two methods to NNTP, description and descriptions. NNTP.description just gets the description of one group (and doesn't return the server status code). NNTP.descriptions does the same as xgtitle does now, but in a more general, and RFC2980 compliant way. It tries the RFC2980 way (LIST NEWSGROUPS) and if this fails, falls back to XGTITLE. This patch also adds an new optional "groups" argument to the NNTP.list. I thought it fitting to mirror the "LIST/LIST NEWSGROUPS" in the method. Feel free to kill this part, I'm not really attached to it. I do prefer description/descriptions, as they make the code more self-documenting. (If you insist: I'm on Debian GNU/Linux "sid", python2.2.1... but the patch should apply cleanly against CVS, doerwalter's checkin shouldn't conflict) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=605370&group_id=5470 From noreply@sourceforge.net Fri Sep 6 04:41:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 20:41:33 -0700 Subject: [Patches] [ python-Patches-601959 ] replace_header method for Message class Message-ID: Patches item #601959, was opened at 2002-08-29 12:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601959&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: replace_header method for Message class Initial Comment: There are certain situations where I want to replace the contents of a header and not change either the header's name or its position in the list of headers. Accordingly, something like del msg["Subject"] msg["Subject"] = newsubj doesn't quite cut it. For example, de-SpamAssassin-ing a message for feeding to GBayes would change the header order (minor change, but annoying) and potentially change the actual subject string (some spam seems to use "SUBJECT:" instead of "Subject:"). Here's a replace_header method that does what I want. def replace_header(self, hdr, newval): """replace first value for hdr with newval""" hdr = hdr.lower() for (i, (k, v)) in enumerate(self._headers): if k.lower() == hdr: self._headers[i] = (k, newval) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-05 23:41 Message: Logged In: YES user_id=12800 Added to Message.py 1.21 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-30 10:13 Message: Logged In: YES user_id=12800 +1 Thanks! I'll try to get this into email 2.3. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-08-30 10:10 Message: Logged In: YES user_id=44345 How about the attached? Used zip() instead of enumerate. I'll let you worry about the name... ;-) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-30 09:12 Message: Logged In: YES user_id=12800 +1 although I'd like to think some on the method name. Also, we'll need a Python 2.1 compatible version of that method (no "enumerate"). The email package still has to be Py2.1 compatible. See PEP 291. Care to upload a new version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=601959&group_id=5470 From noreply@sourceforge.net Fri Sep 6 04:55:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 20:55:30 -0700 Subject: [Patches] [ python-Patches-600096 ] email: RFC 2231 parameters encoding Message-ID: Patches item #600096, was opened at 2002-08-26 04:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600096&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email: RFC 2231 parameters encoding Initial Comment: This patch accomplishes the patch N549133 (RFC 2231 parameters decoding). It adds RFC 2231 parameter encoding. I gzipped the file to prevent damage in transit (the file has mixed tb/spaces, etc). ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-05 23:55 Message: Logged In: YES user_id=12800 Added to Message 1.22. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600096&group_id=5470 From noreply@sourceforge.net Fri Sep 6 06:07:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Sep 2002 22:07:50 -0700 Subject: [Patches] [ python-Patches-602108 ] improper use of strncpy in getpath Message-ID: Patches item #602108, was opened at 2002-08-29 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Open Resolution: Rejected Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: improper use of strncpy in getpath Initial Comment: Many uses of strncpy() in Modules/getpath and PC/getpathp do not copy the terminating null character onto the string. This patch makes sure the strings are null terminated after strncpy(). Should this be backported? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-06 01:07 Message: Logged In: YES user_id=6380 Good catch. Can you check a fix along those lines in for just that variable? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-05 16:32 Message: Logged In: YES user_id=33168 I spoke too soon. Not all the variables are global static. In Modules/getpath.c::calculate_path() (line 363), argv0_path is a local, non-static variable. In the original patch, this was set to the null char in 4 places. I think it would be easier to do: argv0_path[MAXPATHLEN] = '\0'; once, before argv0_path is used rather than after each strncpy(). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 17:51 Message: Logged In: YES user_id=33168 You are correct. There should always be a null byte since all the variables are static. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:55 Message: Logged In: YES user_id=6380 Since the variables affected are all globals, there is already a null byte in the final position. So there's no need to write one explicitly. I therefore reject this patch. I'm leaving it open in case I'm misunderstanding something. If you agree, please close it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 From noreply@sourceforge.net Fri Sep 6 10:45:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 02:45:48 -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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554192&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) 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. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 11:45 Message: Logged In: YES user_id=21627 Looks good, please apply it. Don't forget to edit Misc/NEWS. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-08-19 14:57 Message: Logged In: YES user_id=89016 diff3.txt adds a strict=True to add_type and to all methods that call add_type (i.e. read() and readfp()). types_map and common_types are combined into a dict tuple (in the class, on the module level they are still two dicts, to be backwards compatible.) What about adding a guess_all_types(), that returns a list of all registered mimetypes for an exception? This way we would be able to handle duplicates. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-15 20:18 Message: Logged In: YES user_id=12800 If add_type() is going to be public, shouldn't it have a "strict" flag to decide whether to add it to the standard types dict or the common types dict? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-08-15 19:40 Message: Logged In: YES user_id=89016 diff2.txt adds the global version of add_type and the documentation in Doc/lib/libmimetypes.tex. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-31 13:24 Message: Logged In: YES user_id=89016 OK, I'll change the patch and post the question to python-dev next week (I'm on vacation right now). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-30 14:34 Message: Logged In: YES user_id=21627 I'm in favour of exposing it on the module level. If you are uncertain, you might want to ask on python-dev. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-30 13:00 Message: Logged In: YES user_id=89016 It *is* used in two spots: The constructor and the readfp method. But exposing it at the module level could make sense, because it is the atomic method of adding mime type information. So should it change the patch to expose it at the module level and change the LaTeX documentation accordingly? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-29 10:44 Message: Logged In: YES user_id=21627 I can't see the point of making it private, since it is not used inside the module. If you plan to use it, that usage certainly is outside of the module, so the method would be public. If it is public, it needs to be exposed on the module level, and it needs to be documented. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-29 10:23 Message: Logged In: YES user_id=89016 The patch adds an inverted mapping (i.e. mapping from type to a list of extensions). add_type simplifies adding a type<->ext mapping to both dictionaries. If this method should not be exposed we could make the name private. (_add_type) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 12:30 Message: Logged In: YES user_id=21627 What is the role of add_type in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554192&group_id=5470 From noreply@sourceforge.net Fri Sep 6 14:12:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 06:12:31 -0700 Subject: [Patches] [ python-Patches-544740 ] test_commands test fails under Cygwin Message-ID: Patches item #544740, was opened at 2002-04-16 08:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Martin v. Löwis (loewis) Summary: test_commands test fails under Cygwin Initial Comment: The Python 2.2.1 test_commands regression test fails under Cygwin 1.3.10 because the regular expression is pickier now and because Cygwin can have spaces in user and/or group names. See the following for some more details: http://cygwin.com/ml/cygwin/2002-04/msg00774.html and a workaround. I'm submitting this as a bug report instead of a patch because I don't know the best way to fix this issue. Can test_commands use numeric IDs instead of names? Should I discuss this issue on python-dev instead of here? BTW, please add a "Test" category to the available choices for Bugs. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-09-06 05:12 Message: Logged In: YES user_id=86216 > This patch won't work in other locales. I was afraid of this. > Why do you have to put an explicit format string > for the date in there? Because without the explicit date regular expression, I could not figure out how to match the user and group names with an arbitrary number of embedded spaces. > What specific change made the expression > "pickier"? I guess that "pickier" was a bad choice of words -- I should have used "changed" instead. The original test used "ls -ld /bin/ls" which didn't seem to (but could) trigger the failure. JT> Can test_commands use numeric IDs instead of JT> names? What about changing commands.getstatus() to use numeric IDs? Is the attached (new) patch more acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 06:14 Message: Logged In: YES user_id=21627 This patch won't work in other locales. E.g. in de_DE, a date might read Mär 21 01:14 which won't match your regexp. Furthermore, recent GNU fileutils format it as 2002-09-02 10:12 in non-C locales, which is even further away. In theory, putting LC_ALL=C into the environment should solve this, but it would be better to not rely on the date formatting. Why do you have to put an explicit format string for the date in there? What specific change made the expression "pickier"? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-08-27 10:12 Message: Logged In: YES user_id=86216 Attached is a patch to fix this problem. As suggested by Guido, I am proposing a "better" regular expression. Unfortunately, I had to make an assumption on the date format in order to match the user and group names regardless of the number of embedded spaces. Is my date regular expression acceptable? Will it work in non US locales? FWIW, I tested under Cygwin and Red Hat Linux 7.1 without any ill effects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 07:48 Message: Logged In: YES user_id=33168 Jason, I presume this is still a problem. It probably would be a good idea to discuss on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 From noreply@sourceforge.net Fri Sep 6 14:22:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 06:22:31 -0700 Subject: [Patches] [ python-Patches-544740 ] test_commands test fails under Cygwin Message-ID: Patches item #544740, was opened at 2002-04-16 18:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: test_commands test fails under Cygwin Initial Comment: The Python 2.2.1 test_commands regression test fails under Cygwin 1.3.10 because the regular expression is pickier now and because Cygwin can have spaces in user and/or group names. See the following for some more details: http://cygwin.com/ml/cygwin/2002-04/msg00774.html and a workaround. I'm submitting this as a bug report instead of a patch because I don't know the best way to fix this issue. Can test_commands use numeric IDs instead of names? Should I discuss this issue on python-dev instead of here? BTW, please add a "Test" category to the available choices for Bugs. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 15:22 Message: Logged In: YES user_id=21627 I'm not sure what the purpose of getstatus is - adding -n is a behaviour change, which should be avoided. I'm still not sure what the issue with spaces in group names is. Can you report the output of the ls for your system? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 15:12 Message: Logged In: YES user_id=86216 > This patch won't work in other locales. I was afraid of this. > Why do you have to put an explicit format string > for the date in there? Because without the explicit date regular expression, I could not figure out how to match the user and group names with an arbitrary number of embedded spaces. > What specific change made the expression > "pickier"? I guess that "pickier" was a bad choice of words -- I should have used "changed" instead. The original test used "ls -ld /bin/ls" which didn't seem to (but could) trigger the failure. JT> Can test_commands use numeric IDs instead of JT> names? What about changing commands.getstatus() to use numeric IDs? Is the attached (new) patch more acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 16:14 Message: Logged In: YES user_id=21627 This patch won't work in other locales. E.g. in de_DE, a date might read Mär 21 01:14 which won't match your regexp. Furthermore, recent GNU fileutils format it as 2002-09-02 10:12 in non-C locales, which is even further away. In theory, putting LC_ALL=C into the environment should solve this, but it would be better to not rely on the date formatting. Why do you have to put an explicit format string for the date in there? What specific change made the expression "pickier"? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-08-27 20:12 Message: Logged In: YES user_id=86216 Attached is a patch to fix this problem. As suggested by Guido, I am proposing a "better" regular expression. Unfortunately, I had to make an assumption on the date format in order to match the user and group names regardless of the number of embedded spaces. Is my date regular expression acceptable? Will it work in non US locales? FWIW, I tested under Cygwin and Red Hat Linux 7.1 without any ill effects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 17:48 Message: Logged In: YES user_id=33168 Jason, I presume this is still a problem. It probably would be a good idea to discuss on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 From noreply@sourceforge.net Fri Sep 6 14:41:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 06:41:50 -0700 Subject: [Patches] [ python-Patches-544740 ] test_commands test fails under Cygwin Message-ID: Patches item #544740, was opened at 2002-04-16 08:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: test_commands test fails under Cygwin Initial Comment: The Python 2.2.1 test_commands regression test fails under Cygwin 1.3.10 because the regular expression is pickier now and because Cygwin can have spaces in user and/or group names. See the following for some more details: http://cygwin.com/ml/cygwin/2002-04/msg00774.html and a workaround. I'm submitting this as a bug report instead of a patch because I don't know the best way to fix this issue. Can test_commands use numeric IDs instead of names? Should I discuss this issue on python-dev instead of here? BTW, please add a "Test" category to the available choices for Bugs. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-09-06 05:41 Message: Logged In: YES user_id=86216 > I'm not sure what the purpose of getstatus is - > adding -n is a behaviour change, which should be > avoided. Agreed. AFAICT, nothing in the Python source except for test_commands.py itself is using commands.getstatus(). I verified this via: find Lib -name '*.py' | xargs fgrep getstatus Obviously, Python applications could be using commands.py. > I'm still not sure what the issue with spaces in > group names is. Can you report the output of the > ls for your system? $ ls -ld / drwxr-xr-x 15 Administ Domain U 4096 Aug 12 12:50 / $ fgrep 'Domain U' /etc/group Domain Users:S-1-5-21-136257377-364972176-1563891627-513:10513: Note that "Domain U" is the truncated version of "Domain Users". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 05:22 Message: Logged In: YES user_id=21627 I'm not sure what the purpose of getstatus is - adding -n is a behaviour change, which should be avoided. I'm still not sure what the issue with spaces in group names is. Can you report the output of the ls for your system? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 05:12 Message: Logged In: YES user_id=86216 > This patch won't work in other locales. I was afraid of this. > Why do you have to put an explicit format string > for the date in there? Because without the explicit date regular expression, I could not figure out how to match the user and group names with an arbitrary number of embedded spaces. > What specific change made the expression > "pickier"? I guess that "pickier" was a bad choice of words -- I should have used "changed" instead. The original test used "ls -ld /bin/ls" which didn't seem to (but could) trigger the failure. JT> Can test_commands use numeric IDs instead of JT> names? What about changing commands.getstatus() to use numeric IDs? Is the attached (new) patch more acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 06:14 Message: Logged In: YES user_id=21627 This patch won't work in other locales. E.g. in de_DE, a date might read Mär 21 01:14 which won't match your regexp. Furthermore, recent GNU fileutils format it as 2002-09-02 10:12 in non-C locales, which is even further away. In theory, putting LC_ALL=C into the environment should solve this, but it would be better to not rely on the date formatting. Why do you have to put an explicit format string for the date in there? What specific change made the expression "pickier"? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-08-27 10:12 Message: Logged In: YES user_id=86216 Attached is a patch to fix this problem. As suggested by Guido, I am proposing a "better" regular expression. Unfortunately, I had to make an assumption on the date format in order to match the user and group names regardless of the number of embedded spaces. Is my date regular expression acceptable? Will it work in non US locales? FWIW, I tested under Cygwin and Red Hat Linux 7.1 without any ill effects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 07:48 Message: Logged In: YES user_id=33168 Jason, I presume this is still a problem. It probably would be a good idea to discuss on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 From noreply@sourceforge.net Fri Sep 6 16:50:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 08:50:39 -0700 Subject: [Patches] [ python-Patches-599836 ] Bugfix for urllib2.py Message-ID: Patches item #599836, was opened at 2002-08-25 00:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Jeremy Hylton (jhylton) Summary: Bugfix for urllib2.py Initial Comment: OpenerDirector has a default User-agent header. That wouldn't be a problem, except that AbstractHTTPHandler uses the headers in OpenerDirector.addheaders *after* a Request has been instantiated, thus making that default override whatever headers were given to Request. This patch checks to make sure a header isn't already in a Request before adding the OpenerDirector's headers. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-06 08:50 Message: Logged In: NO Unless you want problems, I suggest you to use the same case as Mozilla, IE and the RFC in the User-Agent HTTP header. --- python/dist/src/Lib/urllib.py +++ python/dist/src/Lib/urllib.py @@ -104,7 +104,7 @@ self.proxies = proxies self.key_file = x509.get('key_file') self.cert_file = x509.get('cert_file') - self.addheaders = [('User-agent', self.version)] + self.addheaders = [('User-Agent', self.version)] self.__tempfiles = [] self.__unlink = os.unlink # See cleanup() self.tempcache = None --- python/dist/src/Lib/urllib2.py +++ python/dist/src/Lib/urllib2.py @@ -247,7 +247,7 @@ class OpenerDirector: def __init__(self): server_version = "Python-urllib/%s" % __version__ - self.addheaders = [('User-agent', server_version)] + self.addheaders = [('User-Agent', server_version)] # manage the individual handlers self.handlers = [] self.handle_open = {} ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 11:56 Message: Logged In: YES user_id=6380 For Jeremy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 From noreply@sourceforge.net Fri Sep 6 17:19:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 09:19:18 -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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554192&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) 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. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-06 18:19 Message: Logged In: YES user_id=89016 Checked in as: Doc/lib/libmimetypes.tex 1.11 Lib/mimetypes.py 1.23 Misc/NEWS 1.481 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 11:45 Message: Logged In: YES user_id=21627 Looks good, please apply it. Don't forget to edit Misc/NEWS. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-08-19 14:57 Message: Logged In: YES user_id=89016 diff3.txt adds a strict=True to add_type and to all methods that call add_type (i.e. read() and readfp()). types_map and common_types are combined into a dict tuple (in the class, on the module level they are still two dicts, to be backwards compatible.) What about adding a guess_all_types(), that returns a list of all registered mimetypes for an exception? This way we would be able to handle duplicates. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-15 20:18 Message: Logged In: YES user_id=12800 If add_type() is going to be public, shouldn't it have a "strict" flag to decide whether to add it to the standard types dict or the common types dict? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-08-15 19:40 Message: Logged In: YES user_id=89016 diff2.txt adds the global version of add_type and the documentation in Doc/lib/libmimetypes.tex. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-31 13:24 Message: Logged In: YES user_id=89016 OK, I'll change the patch and post the question to python-dev next week (I'm on vacation right now). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-30 14:34 Message: Logged In: YES user_id=21627 I'm in favour of exposing it on the module level. If you are uncertain, you might want to ask on python-dev. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-30 13:00 Message: Logged In: YES user_id=89016 It *is* used in two spots: The constructor and the readfp method. But exposing it at the module level could make sense, because it is the atomic method of adding mime type information. So should it change the patch to expose it at the module level and change the LaTeX documentation accordingly? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-29 10:44 Message: Logged In: YES user_id=21627 I can't see the point of making it private, since it is not used inside the module. If you plan to use it, that usage certainly is outside of the module, so the method would be public. If it is public, it needs to be exposed on the module level, and it needs to be documented. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-29 10:23 Message: Logged In: YES user_id=89016 The patch adds an inverted mapping (i.e. mapping from type to a list of extensions). add_type simplifies adding a type<->ext mapping to both dictionaries. If this method should not be exposed we could make the name private. (_add_type) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 12:30 Message: Logged In: YES user_id=21627 What is the role of add_type in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554192&group_id=5470 From noreply@sourceforge.net Fri Sep 6 17:32:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Sep 2002 09:32:30 -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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554192&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) 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. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-06 18:19 Message: Logged In: YES user_id=89016 Checked in as: Doc/lib/libmimetypes.tex 1.11 Lib/mimetypes.py 1.23 Misc/NEWS 1.481 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 11:45 Message: Logged In: YES user_id=21627 Looks good, please apply it. Don't forget to edit Misc/NEWS. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-08-19 14:57 Message: Logged In: YES user_id=89016 diff3.txt adds a strict=True to add_type and to all methods that call add_type (i.e. read() and readfp()). types_map and common_types are combined into a dict tuple (in the class, on the module level they are still two dicts, to be backwards compatible.) What about adding a guess_all_types(), that returns a list of all registered mimetypes for an exception? This way we would be able to handle duplicates. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-15 20:18 Message: Logged In: YES user_id=12800 If add_type() is going to be public, shouldn't it have a "strict" flag to decide whether to add it to the standard types dict or the common types dict? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-08-15 19:40 Message: Logged In: YES user_id=89016 diff2.txt adds the global version of add_type and the documentation in Doc/lib/libmimetypes.tex. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-31 13:24 Message: Logged In: YES user_id=89016 OK, I'll change the patch and post the question to python-dev next week (I'm on vacation right now). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-30 14:34 Message: Logged In: YES user_id=21627 I'm in favour of exposing it on the module level. If you are uncertain, you might want to ask on python-dev. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-30 13:00 Message: Logged In: YES user_id=89016 It *is* used in two spots: The constructor and the readfp method. But exposing it at the module level could make sense, because it is the atomic method of adding mime type information. So should it change the patch to expose it at the module level and change the LaTeX documentation accordingly? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-29 10:44 Message: Logged In: YES user_id=21627 I can't see the point of making it private, since it is not used inside the module. If you plan to use it, that usage certainly is outside of the module, so the method would be public. If it is public, it needs to be exposed on the module level, and it needs to be documented. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-07-29 10:23 Message: Logged In: YES user_id=89016 The patch adds an inverted mapping (i.e. mapping from type to a list of extensions). add_type simplifies adding a type<->ext mapping to both dictionaries. If this method should not be exposed we could make the name private. (_add_type) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 12:30 Message: Logged In: YES user_id=21627 What is the role of add_type in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554192&group_id=5470 From noreply@sourceforge.net Sat Sep 7 17:27:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 09:27:36 -0700 Subject: [Patches] [ python-Patches-606067 ] Tweaks to calls to AH/Help Message-ID: Patches item #606067, was opened at 2002-09-07 16:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606067&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: Tweaks to calls to AH/Help Initial Comment: An import was missing from FrameWork.py; and choosing the "Help | Python Documentation" menu item in the IDE was causing an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606067&group_id=5470 From noreply@sourceforge.net Sat Sep 7 19:36:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 11:36:54 -0700 Subject: [Patches] [ python-Patches-606098 ] fast dictionary lookup by name Message-ID: Patches item #606098, was opened at 2002-09-07 18:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606098&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oren Tirosh (orenti) Assigned to: Nobody/Anonymous (nobody) Summary: fast dictionary lookup by name Initial Comment: This patch speeds up dictionary lookup when the key is an interned string. Test results (Guido's tar from patch #597907) Before: builtin 2.01 global 1.57 local 1.87 fastlocal 1.02 After: builtin 1.78 global 1.63 local 1.51 fastlocal 1.06 Not as impressive as the last patch because this version doesn't use the inline macro yet. A dummy/negative entry is now defined as me_key != NULL and me_value == NULL. A dummy entry also has me_hash set to -1 to shave a few more cycles in the search. Management of negative entries and the interaction with table resizing still needs more work. If there is not enough room for a new negative entry it is simply ignored. The bottlneck appears to be the first negative lookup. It starts with a fast search that fails and then falls back to a slow search and inserts a negative entry. This path is significantly slower than without the patch. Subsequent lookups will be much faster but many objects are created where attributes or methods are looked up just once. The solution I am considering is to change lookdict_string to lookdict_interned. A dictionary in this state has only interned string keys so the fast search is guaranteed to produce the correct result if the lookup key is also an interned string with no fallback required. This should also make it easier to speed up PyDict_SetItem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606098&group_id=5470 From noreply@sourceforge.net Sat Sep 7 22:19:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 14:19:31 -0700 Subject: [Patches] [ python-Patches-606132 ] Mac OS X keydefs Message-ID: Patches item #606132, was opened at 2002-09-07 21:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606132&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X keydefs Initial Comment: Adds keydefs that are more suitable to Mac OS X; also disable CallTips in config-mac.txt due to broken tooltips in Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606132&group_id=5470 From noreply@sourceforge.net Sat Sep 7 22:24:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 14:24:01 -0700 Subject: [Patches] [ python-Patches-606134 ] install_IDLE target in Mac/OSX/Makefile Message-ID: Patches item #606134, was opened at 2002-09-07 21:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606134&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: install_IDLE target in Mac/OSX/Makefile Initial Comment: With this patch, IDLE is installed if _tkinter is found, just like the IDE. Also, /Library/Frameworks, ~/Library/Frameworks and /Network/Library/Frameworks are added to the path. Includes the diffs from patch 606067. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606134&group_id=5470 From noreply@sourceforge.net Sun Sep 8 04:43:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 20:43:41 -0700 Subject: [Patches] [ python-Patches-600152 ] IDLE [Open module]: import submodules Message-ID: Patches item #600152, was opened at 2002-08-26 06:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600152&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Christos Georgiou (tzot) Assigned to: Raymond Hettinger (rhettinger) Summary: IDLE [Open module]: import submodules Initial Comment: Since imp module's find_module can't find submodules, we can use the __import__ builtin to get the path to the submodule, and then call the imp.find_module function. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-07 22:43 Message: Logged In: YES user_id=80475 Revised patch and committed as EditorWindow.py 1.43. Marking as fixed and closing patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-31 09:12 Message: Logged In: YES user_id=80475 Looks good. Will apply when I get back from this weekend. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-08-26 07:28 Message: Logged In: YES user_id=539787 Added code to correctly handle the case of trying to open submodules like 'os.path' ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-08-26 07:26 Message: Logged In: YES user_id=539787 Added some code to handle correctly trying to open modules such as os.path ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=600152&group_id=5470 From noreply@sourceforge.net Sun Sep 8 04:54:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 20:54:30 -0700 Subject: [Patches] [ python-Patches-604600 ] For Bug [ 490168 ] shutil.copy(path, pat Message-ID: Patches item #604600, was opened at 2002-09-04 11:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604600&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: For Bug [ 490168 ] shutil.copy(path, pat Initial Comment: As the bug says, shutil.copy(src, dst) deletes the contents of src if it is the same as dst. Example: $ pwd /home/tzot $ echo hello >file01 $ ln file01 file02 $ echo hello >file03 $ ln -s file03 file04 $ echo hello >file05 $ python Python 2.3a0 (#26, Sep 4 2002, 17:39:22) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> from shutil import copyfile >>> copyfile('file01', 'file02') >>> copyfile('file03', 'file04') >>> copyfile('file05', '../tzot/file05') After this sequence, all files have zero length. The patch corrects this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-07 22:54 Message: Logged In: YES user_id=80475 What is this line for? if _src.st_ino>0<_dst.st_ino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604600&group_id=5470 From noreply@sourceforge.net Sun Sep 8 05:09:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 21:09:46 -0700 Subject: [Patches] [ python-Patches-578688 ] incompatible, but nice strings improveme Message-ID: Patches item #578688, was opened at 2002-07-08 09:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=578688&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stepan Koltsov (yozh) Assigned to: Nobody/Anonymous (nobody) Summary: incompatible, but nice strings improveme Initial Comment: This patch changes interpretation of multiline strings (desn't matter, single, double quoted (when NL escaped with backslash), triple quoted). After applying this patch, first: first charachter after opening quote is ignored, if it is NL, example: """ la-la-la """ will be equivalent of """la-la-la """ First variant looks better, isn't is? Second: all spaces after NL before first nonblack char but no more then current indentation are ignored, example: New: def f(): """ This is docstring, mama-mama, apple, banana """ is equivalent of old: def f(): """This is docstring, mama-mama, apple, banana """ Patch enabled if PyPARSE_STRIPPED_STRINGS defined. I suggest you to apply patch but undefine PyPARSE_STRIPPED_STRINGS until python-4 ;-) I am sure, that this semantics is right, as alternative, I suggest adding new modifier 'i' to strings, like 'u' and 'r', for inst. i'iddqd'. P. S. AFAIU, editing of parsermodule.c needed. P. P. S. I am sorry, my English suck :-( ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-07 23:09 Message: Logged In: YES user_id=80475 This proposal does not have much of a chance. It offers only a minor gain (debatable) but assures incompatability. I recommend that the OP take Martin's hint and withdraw or close the patch. If you need it badly, a PEP is essential. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-09 03:13 Message: Logged In: YES user_id=21627 In that case,I think your proposed change will be highly debated. That means you will have to write a PEP first if you want to see it implemented (even if it is only an option). ---------------------------------------------------------------------- Comment By: Stepan Koltsov (yozh) Date: 2002-07-08 11:06 Message: Logged In: YES user_id=247706 I think the first part is still needed since 1. In r"""\ lalala """ backslash doesn't escape NL 2. I think it looks better. About second part: 1. Additional library routines make program text less readable. 2. They cannot know what indentation in spaces was where string constant appeared. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-08 10:48 Message: Logged In: YES user_id=21627 The first part of your patch is not needed, you can just as fine write """\ la-la-la """ to escape the first newline. The second patch is probably not needed either, since you can easily write library routines that deal with that kind of stripping. In fact, pydoc already does that transformation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=578688&group_id=5470 From noreply@sourceforge.net Sun Sep 8 05:53:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 21:53:12 -0700 Subject: [Patches] [ python-Patches-572113 ] Remove import string in Tools/ directory Message-ID: Patches item #572113, was opened at 2002-06-21 09:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: Remove import string in Tools/ directory Initial Comment: This patch replace string module functions with string methods and removes the "import string" for the stuff in the Tools directory. A few "import string" statements are still remaining: scripts/texi2html.py still uses string.ascii_letters, string.digits, etc. modulator/modulator.py still uses string.letters and string.digits freeze/win32.html still mentions the string module idle/AutoExpand.py still uses string.ascii_letters and string.digits idle/CallTips.py still uses string.uppercase, string.lowercase and string.digits idle/PyShell.py still uses string.ascii_letters and string.digits idle/UndoDelegator.py still uses string.ascii_letters and string.digits idle/testcode.py still uses string.capwords() ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-07 23:53 Message: Logged In: YES user_id=80475 Let me know if you want this done. If so, I'll give it a second check (line-by-line) for errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 From noreply@sourceforge.net Sun Sep 8 05:57:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 21:57:03 -0700 Subject: [Patches] [ python-Patches-572113 ] Remove import string in Tools/ directory Message-ID: Patches item #572113, was opened at 2002-06-21 10:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Remove import string in Tools/ directory Initial Comment: This patch replace string module functions with string methods and removes the "import string" for the stuff in the Tools directory. A few "import string" statements are still remaining: scripts/texi2html.py still uses string.ascii_letters, string.digits, etc. modulator/modulator.py still uses string.letters and string.digits freeze/win32.html still mentions the string module idle/AutoExpand.py still uses string.ascii_letters and string.digits idle/CallTips.py still uses string.uppercase, string.lowercase and string.digits idle/PyShell.py still uses string.ascii_letters and string.digits idle/UndoDelegator.py still uses string.ascii_letters and string.digits idle/testcode.py still uses string.capwords() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-08 00:57 Message: Logged In: YES user_id=6380 Good idea to give it a careful check. I'd suggest to let Walter to check it in since he did the work though. Or you two can race for it. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 00:53 Message: Logged In: YES user_id=80475 Let me know if you want this done. If so, I'll give it a second check (line-by-line) for errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 From noreply@sourceforge.net Sun Sep 8 05:57:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Sep 2002 21:57:27 -0700 Subject: [Patches] [ python-Patches-561244 ] Micro optimizations Message-ID: Patches item #561244, was opened at 2002-05-27 16:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&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: 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. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-07 23:57 Message: Logged In: YES user_id=80475 Are these all done now? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-03 10:59 Message: Logged In: YES user_id=33168 Checked in the memset()s in: {list,tuple}object.c and _sre.c. object.c 2.178 Still have to do int and frame. I've cleaned up int so that if there is an init failure, a fatal error is raised similar to other initializations. I will get around to checking that in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 16:43 Message: Logged In: YES user_id=6380 I like all of these, even PyInt_Init(). Go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-31 17:11 Message: Logged In: YES user_id=80475 Wow, you plowed through a lot of code! Two sets of optimizations look worthwhile, the memsets() and the XINCREFs to INCREFS. Probably the fastlocals substitutions should be done also, but more for beauty and clarity than speed. I checked those three categories of changes on my machine. They compile fine, pass the standard regression tests and checkout okay on my personal, realcode testfarm. I don't think the PyInt_Init() addition buys us anything. The register and macro tweaks may cost more in review time and potential errors than they could ever save in cumulative computer time. Recommend you get these in before someone changes the codebase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&group_id=5470 From noreply@sourceforge.net Sun Sep 8 15:20:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 07:20:15 -0700 Subject: [Patches] [ python-Patches-604600 ] For Bug [ 490168 ] shutil.copy(path, pat Message-ID: Patches item #604600, was opened at 2002-09-04 19:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604600&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: For Bug [ 490168 ] shutil.copy(path, pat Initial Comment: As the bug says, shutil.copy(src, dst) deletes the contents of src if it is the same as dst. Example: $ pwd /home/tzot $ echo hello >file01 $ ln file01 file02 $ echo hello >file03 $ ln -s file03 file04 $ echo hello >file05 $ python Python 2.3a0 (#26, Sep 4 2002, 17:39:22) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> from shutil import copyfile >>> copyfile('file01', 'file02') >>> copyfile('file03', 'file04') >>> copyfile('file05', '../tzot/file05') After this sequence, all files have zero length. The patch corrects this. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2002-09-08 17:20 Message: Logged In: YES user_id=539787 This is a check that is true only on POSIX systems AFAIK. On windows systems, st_ino is reported as 0 for all files, so the files would falsely be presumed to be the same file and therefore not copied. PS At least on NTFS, files do have an inode number (same concept)... there is even a CreateHardLink call in kernel32.dll, which can be used to create hard links; MS implemented this since NT 3.51 I think, in order to attain POSIX conformability; however, either python ignores that, or MS do not provide information in their stat and / or link simulated system calls. I will invest some time in getting acquainted to Windows programming so that I research into this and offer a patch to posixmodule.c. If interested, see http://msdn.microsoft.com/library/en- us/fileio/base/createhardlink.asp ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 06:54 Message: Logged In: YES user_id=80475 What is this line for? if _src.st_ino>0<_dst.st_ino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604600&group_id=5470 From noreply@sourceforge.net Sun Sep 8 16:43:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 08:43:33 -0700 Subject: [Patches] [ python-Patches-606354 ] typo in Doc/lib/libcodecs.tex Message-ID: Patches item #606354, was opened at 2002-09-08 15:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606354&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: typo in Doc/lib/libcodecs.tex Initial Comment: --- python2.3-2.2.91.orig/Doc/lib/libcodecs.tex +++ python2.3-2.2.91/Doc/lib/libcodecs.tex @@ -100,7 +100,7 @@ \begin{funcdesc}{register_error}{name, error_handler} Register the error handling function \var{error_handler} under the -name \var{name}. \vari{error_handler} will be called during encoding +name \var{name}. \var{error_handler} will be called during encoding and decoding in case of an error, when \var{name} is specified as the errors parameter. \var{error_handler} will be called with an \exception{UnicodeEncodeError}, \exception{UnicodeDecodeError} or ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606354&group_id=5470 From noreply@sourceforge.net Sun Sep 8 21:46:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 13:46:25 -0700 Subject: [Patches] [ python-Patches-604600 ] For Bug [ 490168 ] shutil.copy(path, pat Message-ID: Patches item #604600, was opened at 2002-09-04 11:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604600&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: For Bug [ 490168 ] shutil.copy(path, pat Initial Comment: As the bug says, shutil.copy(src, dst) deletes the contents of src if it is the same as dst. Example: $ pwd /home/tzot $ echo hello >file01 $ ln file01 file02 $ echo hello >file03 $ ln -s file03 file04 $ echo hello >file05 $ python Python 2.3a0 (#26, Sep 4 2002, 17:39:22) [C] on irix646 Type "help", "copyright", "credits" or "license" for more information. >>> from shutil import copyfile >>> copyfile('file01', 'file02') >>> copyfile('file03', 'file04') >>> copyfile('file05', '../tzot/file05') After this sequence, all files have zero length. The patch corrects this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 15:46 Message: Logged In: YES user_id=80475 Added a simplified version of the patch to Py2.3. See shutil.py 1.23 Am leaving the Posix piece out for several reasons: -- I'm on Windows and can't verify the code -- As patched, the code didn't work at all (it assumed that the destination existed and the call to stat fails if it doesn't) -- Handling symbolic links is a somewhat special case. Thanks for the patch. It's great that you helped address one of the older pending bugs. For the future, please send a cvs diff -c taken from the current version of the file. Please test all cases (when src and dst are the same, when the same but spelled differently, and when they are different altogether). Also, please remove the print statements so the patch can be applied directly. Also, please post the patches directly to the original bug instead of opening a separate patch -- this simplifies tracking the discussion. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-08 09:20 Message: Logged In: YES user_id=539787 This is a check that is true only on POSIX systems AFAIK. On windows systems, st_ino is reported as 0 for all files, so the files would falsely be presumed to be the same file and therefore not copied. PS At least on NTFS, files do have an inode number (same concept)... there is even a CreateHardLink call in kernel32.dll, which can be used to create hard links; MS implemented this since NT 3.51 I think, in order to attain POSIX conformability; however, either python ignores that, or MS do not provide information in their stat and / or link simulated system calls. I will invest some time in getting acquainted to Windows programming so that I research into this and offer a patch to posixmodule.c. If interested, see http://msdn.microsoft.com/library/en- us/fileio/base/createhardlink.asp ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-07 22:54 Message: Logged In: YES user_id=80475 What is this line for? if _src.st_ino>0<_dst.st_ino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=604600&group_id=5470 From noreply@sourceforge.net Sun Sep 8 23:26:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 15:26:50 -0700 Subject: [Patches] [ python-Patches-606354 ] typo in Doc/lib/libcodecs.tex Message-ID: Patches item #606354, was opened at 2002-09-08 10:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606354&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: typo in Doc/lib/libcodecs.tex Initial Comment: --- python2.3-2.2.91.orig/Doc/lib/libcodecs.tex +++ python2.3-2.2.91/Doc/lib/libcodecs.tex @@ -100,7 +100,7 @@ \begin{funcdesc}{register_error}{name, error_handler} Register the error handling function \var{error_handler} under the -name \var{name}. \vari{error_handler} will be called during encoding +name \var{name}. \var{error_handler} will be called during encoding and decoding in case of an error, when \var{name} is specified as the errors parameter. \var{error_handler} will be called with an \exception{UnicodeEncodeError}, \exception{UnicodeDecodeError} or ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 17:26 Message: Logged In: YES user_id=80475 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606354&group_id=5470 From noreply@sourceforge.net Mon Sep 9 01:28:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 17:28:51 -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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&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: 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. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-08 20:28 Message: Logged In: YES user_id=33168 No, I've still got some outstanding modifications. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 00:57 Message: Logged In: YES user_id=80475 Are these all done now? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-03 11:59 Message: Logged In: YES user_id=33168 Checked in the memset()s in: {list,tuple}object.c and _sre.c. object.c 2.178 Still have to do int and frame. I've cleaned up int so that if there is an init failure, a fatal error is raised similar to other initializations. I will get around to checking that in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 17:43 Message: Logged In: YES user_id=6380 I like all of these, even PyInt_Init(). Go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-31 18:11 Message: Logged In: YES user_id=80475 Wow, you plowed through a lot of code! Two sets of optimizations look worthwhile, the memsets() and the XINCREFs to INCREFS. Probably the fastlocals substitutions should be done also, but more for beauty and clarity than speed. I checked those three categories of changes on my machine. They compile fine, pass the standard regression tests and checkout okay on my personal, realcode testfarm. I don't think the PyInt_Init() addition buys us anything. The register and macro tweaks may cost more in review time and potential errors than they could ever save in cumulative computer time. Recommend you get these in before someone changes the codebase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&group_id=5470 From noreply@sourceforge.net Mon Sep 9 05:03:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 21:03:37 -0700 Subject: [Patches] [ python-Patches-572113 ] Remove import string in Tools/ directory Message-ID: Patches item #572113, was opened at 2002-06-21 09:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Walter Dörwald (doerwalter) Summary: Remove import string in Tools/ directory Initial Comment: This patch replace string module functions with string methods and removes the "import string" for the stuff in the Tools directory. A few "import string" statements are still remaining: scripts/texi2html.py still uses string.ascii_letters, string.digits, etc. modulator/modulator.py still uses string.letters and string.digits freeze/win32.html still mentions the string module idle/AutoExpand.py still uses string.ascii_letters and string.digits idle/CallTips.py still uses string.uppercase, string.lowercase and string.digits idle/PyShell.py still uses string.ascii_letters and string.digits idle/UndoDelegator.py still uses string.ascii_letters and string.digits idle/testcode.py still uses string.capwords() ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 23:03 Message: Logged In: YES user_id=80475 Whew! It takes just as long to check as 6000 line diff as it does to create the thing in the first place. The patch is accepted and ready to commit after the following corrections and review notes are addressed. Since several errors were syntactical, they could be caught by running the script. I recommend that all of the scripts be run one time before a final commit. Also, anoter additional check would be useful. Everywhere a function defined the likes of _find=string.find, re-verify that every instance of _find was fixed-up (I cannot check this from the diff file). Corrections and review notes (also attached as a separate file): In file: AutoIndent.py Replace: have = len(chars.expand(tabwidth)) With: have = len(chars.expandtabs(tabwidth)) In file: EditorWindow.py Replace: line.find('python') >= 0 With: 'python' in line In file: FormatParagraph.py Replace: data = "\n".join("\n") With: data = "\n".join(lines) In file: PyParse.py Replace: return len(str[self.stmt_start:i].expandtabs(, With: return len(str[self.stmt_start:i].expandtabs(\ In file: byteyears.py Replace: print file.ljust(file, maxlen), With: print file.ljust(maxlen), In file: fixheader.py Reverify propriety of substitution: if ord(c)<=0x80 and c.isalnum() In file: mailerdaemon.py Replace: if sub.find('warning') >= 0: return 1 With: if 'warning' in sub: return 1 In file: mailerdaemon.py Replace: errors.append(''.join((email.strip()+': '+res.group ('reason')).split())) With: errors.append(' '.join((email.strip()+': '+res.group ('reason')).split())) In file: mailerdaemon.py errors.append(''.join((email.strip()+': '+reason).split())) errors.append(' '.join((email.strip()+': '+reason).split())) In file: objgraph.py Replace: ! /usr/bin/env python With: #! /usr/bin/env python In file: pathfix.py Replace: if line.find("python") < 0: With: if "python" in line: In file: texi2html.py I don't understand the <<<<<< additions In file: treesync.py Replace: split(e.split('/') With: e.split('/') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-07 23:57 Message: Logged In: YES user_id=6380 Good idea to give it a careful check. I'd suggest to let Walter to check it in since he did the work though. Or you two can race for it. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-07 23:53 Message: Logged In: YES user_id=80475 Let me know if you want this done. If so, I'll give it a second check (line-by-line) for errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 From noreply@sourceforge.net Mon Sep 9 06:57:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Sep 2002 22:57:42 -0700 Subject: [Patches] [ python-Patches-606592 ] Subsecond timestamps Message-ID: Patches item #606592, was opened at 2002-09-09 07:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Subsecond timestamps Initial Comment: This patch changes st_mtime/atime/ctime to use floats if the system offers the st.st_mtim.tv_nsec field and if that field is nonzero. Support for other APIs can be added as they come available (on Windows, I believe you'll have to sidestep the C library to get FILETIMEs). While this is an API change, reports indicate that Python applications deal fine with getting floats from stat. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 From noreply@sourceforge.net Mon Sep 9 10:40:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 02:40:10 -0700 Subject: [Patches] [ python-Patches-598163 ] textwrap.dedent, inspect.getdoc-ish Message-ID: Patches item #598163, was opened at 2002-08-21 12:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ville Vainio (vvainio) Assigned to: Greg Ward (gward) Summary: textwrap.dedent, inspect.getdoc-ish Initial Comment: Ability to remove indentation from multiline strings (often triple-quoted). Differs from inspect.getdoc by not handling the first line in special manner (often a sensible approach for non-docstring multiline strings) - which should make this function more general (symmetric 'indent' also possible), and more fitting for the textwrap module. Implementation is for the most parts familiar from inspect.getdoc, though I used sring methods instead of the module 'string'. The module 'textwrap' and the function name 'dedent' were suggested on python-dev a while back (by MAL, IIRC). ---------------------------------------------------------------------- >Comment By: Ville Vainio (vvainio) Date: 2002-09-09 12:40 Message: Logged In: YES user_id=213488 Yes, I'll look into the patches for Doc and test - it just might take a short while (have to access anon cvs at work) - few weeks or so. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-09-04 16:43 Message: Logged In: YES user_id=14422 Looks fine to me. Can you provide a patch for Doc/lib/libtextwrap.tex as well? A patch to Lib/test/test_textwrap.py would be nice too, but I can take care of that if you prefer. (Any other diffs should just be uploaded to this patch report.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 21:57 Message: Logged In: YES user_id=6380 For Greg Ward. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=598163&group_id=5470 From noreply@sourceforge.net Mon Sep 9 13:08:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 05:08:24 -0700 Subject: [Patches] [ python-Patches-606592 ] Subsecond timestamps Message-ID: Patches item #606592, was opened at 2002-09-09 01:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: Subsecond timestamps Initial Comment: This patch changes st_mtime/atime/ctime to use floats if the system offers the st.st_mtim.tv_nsec field and if that field is nonzero. Support for other APIs can be added as they come available (on Windows, I believe you'll have to sidestep the C library to get FILETIMEs). While this is an API change, reports indicate that Python applications deal fine with getting floats from stat. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 08:08 Message: Logged In: YES user_id=6380 Looks good. Please check it in, adding a NEWS item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 From noreply@sourceforge.net Mon Sep 9 13:09:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 05:09:43 -0700 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 13:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Riehl (jriehl) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 08:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply@sourceforge.net Mon Sep 9 14:57:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 06:57:27 -0700 Subject: [Patches] [ python-Patches-590513 ] Add popen2 like functionality to pty.py. Message-ID: Patches item #590513, was opened at 2002-08-03 16:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590513&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Rasjid Wilcox (rasjidw) Assigned to: Thomas Wouters (twouters) Summary: Add popen2 like functionality to pty.py. Initial Comment: This patch adds a popen2 like function to pty.py. Due to use of os.execlp in pty.spawn, it is not quite the same, as all the arguments (including the command to be run) must be passed as a tupple. It is only a first draft, and may need some more work, which I am willing to do if some direction is indicated. Tested on Python2.2, under RedHat Linux 7.3. Rasjid. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2002-09-09 15:57 Message: Logged In: YES user_id=34209 I have several comments, but I'm not sure if they've been adressed in other forums or not. Guido mentions documentation, but the patches attached don't seem to contain them; are they seperate ? I also don't see a testcase. - Why threads ? A seperate non-thread version, with a third process to handle the data trafficking, and falling back to that when threads are not available would be nice. - I concur the new behaviour is much more useful. However, I'm a stickler for backward compatibility, so I advice against renaming the old spawn :) - I don't like 'th_spawn'. 'spawn_thread' or 'threaded_spawn' or some such sound better to me (but see above about threads.) - Some minor whitespace issues (the line-wrap on line 150 is not necessary, line 179 is too long, and the backslashes on lines 190 and 205 are not necessary.) A comment describing why the tty.setraw() is done would also be nice. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-08-30 05:54 Message: Logged In: YES user_id=39640 Okay. My final version (I promise!). The code has been reorganised a little so that: a) it is cleaner to read b) the popen2 function now returns the pid of the child process Rasjid. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-20 20:33 Message: Logged In: YES user_id=6380 Assigning this to Thomas Wouters according to his wishes. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-08-16 15:47 Message: Logged In: YES user_id=34209 The pty module actually works on all platforms that provide openpty(). I know at least BSDI and FreeBSD do, in addition to Linux, and I suspect OpenBSD and NetBSD as well, and possibly other BSD-derived systems. Still, it is very unlikely to work on non-POSIX-ish systems, so /bin/sh is a safe bet. I can take a look at the patch, and test it on a variety of machines, but not before I leave on a two-week vacation, this sunday :) I have plenty of time to look at it when I'm back though, in the first week of September. Feel free to assign the patch to me, as a reminder. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-08-16 14:39 Message: Logged In: YES user_id=39640 Okay. This is essentially my final version, subject to an issue around the naming of a couple of the modules functions. My issue is that the pty.spawn funciton does not return. My new one 'th_spawn' function does. I believe quite strongly that to be consistent with the rest of python, 'th_spawn' should be renamed 'spawn', and the current spawn function should be renamed something like '_master' since it takes the place of the pty master. The issue of course is backward compatibility. However, I believe this to be relatively minor for two reasons. 1. I think very few (if any) people are using it, since it was a) largely undocumented, b) didn't always work c) wasn't particularly useful, since it only allowed control from an existing pty (so what was the point?) 2. If anyone is using it, they would _almost_ certainly be starting it on a new thread, so all that would happen if the functions were renamed would be that an extra (redundant) sub-thread is created. I have posted to comp.lang.python to see what other pty.py users think. Subject to the response here and there, I may post to python-dev in due course. Rasjid. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-05 17:20 Message: Logged In: YES user_id=6380 I mostly concur with Martin von Loewis's comments, though I'm not sure this is big enough for a PEP. I think that you're right in answering (yes, no, yes) but I have no information (portability of this module is already limited to IRIX and Linux, according to the docs). The docs use the word "baffle" -- I wonder if you could substitute something else or generally clarify that sentence; it's not very clear from the docs what spawn() does (nor what fork() does, to tell the truth -- all these could really use some examples). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-05 13:44 Message: Logged In: YES user_id=21627 I'm not a regular pty user. Please ask those questions in comp.lang.python, and python-dev. You can also ask previous authors to pty for comments. Uncertainty in such areas might be a hint that a library PEP is need, to justify the rationale for all the details. There is no need to hurry - Python 2.3 is still months away. That said, I do think that this functionality is desirable, so I'd encourage you to complete this task. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-08-05 13:34 Message: Logged In: YES user_id=39640 Before I do docs etc, I have a few questions: 1. I could make it more popen2 like by changing the args to def popen2(cmd, ....) and adding argv=('/bin/sh','-c',cmd) Is this a better idea? Does it reduce portability? Is it safe to assume that all posix systems have /bin/sh? (My guess is yes, no and yes.) 2. Should the threading done in the pty.popen2 function be moved to a separate function, to allow more direct access to spawn. (The current spawn function does not return until the child exits or the parent closes the pipe). 3. Should I worry about how keyboard interrupts are handled? In some cases an uncontrolled process may be left hanging around. Or is it the job of the calling process to deal with that? Lastly, I am away for a week from Wednesday, so I won't be able to do much until I get back, but I will try and finish this off then. Cheers, Rasjid. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 10:56 Message: Logged In: YES user_id=21627 Can you please write documentation and a test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590513&group_id=5470 From noreply@sourceforge.net Mon Sep 9 14:58:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 06:58:54 -0700 Subject: [Patches] [ python-Patches-481118 ] 'switch'/'case'/'else' statement Message-ID: Patches item #481118, was opened at 2001-11-13 01:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=481118&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Thomas Wouters (twouters) Assigned to: M.-A. Lemburg (lemburg) Summary: 'switch'/'case'/'else' statement Initial Comment: This is a quick hack that adds the 'switch' statement to Python. This is by no means production code, it is *hack* that probably leaks stackentries all over the place. It's simply a proof of concept. I probably won't have time to solidify this anytime soon, so if anyone feels a strong desire for rejection, feel free to grab this and fix it up :) Assigned to MAL because he owns the PEP that mentions something like this. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2002-09-09 15:58 Message: Logged In: YES user_id=34209 Can't we put this poor thing out of its misery by now ? :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=481118&group_id=5470 From noreply@sourceforge.net Mon Sep 9 15:25:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 07:25:45 -0700 Subject: [Patches] [ python-Patches-606592 ] Subsecond timestamps Message-ID: Patches item #606592, was opened at 2002-09-09 07:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Subsecond timestamps Initial Comment: This patch changes st_mtime/atime/ctime to use floats if the system offers the st.st_mtim.tv_nsec field and if that field is nonzero. Support for other APIs can be added as they come available (on Windows, I believe you'll have to sidestep the C library to get FILETIMEs). While this is an API change, reports indicate that Python applications deal fine with getting floats from stat. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-09 16:25 Message: Logged In: YES user_id=21627 Committed as configure 1.331 configure.in 1.342 pyconfig.h.in 1.48 libos.tex 1.95 NEWS 1.482 posixmodule.c 2.254 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 14:08 Message: Logged In: YES user_id=6380 Looks good. Please check it in, adding a NEWS item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 From noreply@sourceforge.net Mon Sep 9 15:35:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 07:35:07 -0700 Subject: [Patches] [ python-Patches-606592 ] Subsecond timestamps Message-ID: Patches item #606592, was opened at 2002-09-09 01:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Subsecond timestamps Initial Comment: This patch changes st_mtime/atime/ctime to use floats if the system offers the st.st_mtim.tv_nsec field and if that field is nonzero. Support for other APIs can be added as they come available (on Windows, I believe you'll have to sidestep the C library to get FILETIMEs). While this is an API change, reports indicate that Python applications deal fine with getting floats from stat. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 10:35 Message: Logged In: YES user_id=6380 Hm, I didn't read the patch carefully enough. I'd prefer it of the values were *always* floats. This avoids portability problems where someone tests their code on a system where they happen to be ints, and then the code is ported to a system that has floats. Same as with time.time(): this always returns a float, even if the resolution is only seconds. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-09 10:25 Message: Logged In: YES user_id=21627 Committed as configure 1.331 configure.in 1.342 pyconfig.h.in 1.48 libos.tex 1.95 NEWS 1.482 posixmodule.c 2.254 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 08:08 Message: Logged In: YES user_id=6380 Looks good. Please check it in, adding a NEWS item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 From noreply@sourceforge.net Mon Sep 9 17:20:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 09:20:00 -0700 Subject: [Patches] [ python-Patches-606592 ] Subsecond timestamps Message-ID: Patches item #606592, was opened at 2002-09-09 07:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: Subsecond timestamps Initial Comment: This patch changes st_mtime/atime/ctime to use floats if the system offers the st.st_mtim.tv_nsec field and if that field is nonzero. Support for other APIs can be added as they come available (on Windows, I believe you'll have to sidestep the C library to get FILETIMEs). While this is an API change, reports indicate that Python applications deal fine with getting floats from stat. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-09 18:20 Message: Logged In: YES user_id=21627 Correct in posixmodule.c 1.255, libos.tex 2.255. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 16:35 Message: Logged In: YES user_id=6380 Hm, I didn't read the patch carefully enough. I'd prefer it of the values were *always* floats. This avoids portability problems where someone tests their code on a system where they happen to be ints, and then the code is ported to a system that has floats. Same as with time.time(): this always returns a float, even if the resolution is only seconds. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-09 16:25 Message: Logged In: YES user_id=21627 Committed as configure 1.331 configure.in 1.342 pyconfig.h.in 1.48 libos.tex 1.95 NEWS 1.482 posixmodule.c 2.254 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 14:08 Message: Logged In: YES user_id=6380 Looks good. Please check it in, adding a NEWS item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606592&group_id=5470 From noreply@sourceforge.net Mon Sep 9 20:54:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 12:54:26 -0700 Subject: [Patches] [ python-Patches-572113 ] Remove import string in Tools/ directory Message-ID: Patches item #572113, was opened at 2002-06-21 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Remove import string in Tools/ directory Initial Comment: This patch replace string module functions with string methods and removes the "import string" for the stuff in the Tools directory. A few "import string" statements are still remaining: scripts/texi2html.py still uses string.ascii_letters, string.digits, etc. modulator/modulator.py still uses string.letters and string.digits freeze/win32.html still mentions the string module idle/AutoExpand.py still uses string.ascii_letters and string.digits idle/CallTips.py still uses string.uppercase, string.lowercase and string.digits idle/PyShell.py still uses string.ascii_letters and string.digits idle/UndoDelegator.py still uses string.ascii_letters and string.digits idle/testcode.py still uses string.capwords() ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-09 21:54 Message: Logged In: YES user_id=89016 diff2.txt is a new version of the patch (against current CVS). I rechecked the fixheader fix with: for i in xrange(256): c = chr(i) if (ord(c)<=0x80 and c.isalnum()) != (c in string.ascii_letters + string.digits): print i,c There are no differences. > In file: pathfix.py > Replace: if line.find("python") < 0: > With: if "python" in line: This should probably be: if "python" not in line: > In file: texi2html.py > I don't understand the <<<<<< additions Ouch, that was a merge conflict. OK, Raymond could you recheck if the new patch diff2.txt is OK now? These mindless changes really are tricky! ;) Unfortunately running the scripts isn't an option in most cases: Some require Tk, some might expect certain files and some might even transmogrify all the source files. I changed a few tests line[:x] == "xxx...xxx" to line.startswith("xxx...xxx") too. I rechecked the _find = string.find cases in idle/PyParse.py and script/gencodec.py. If I'll get your OK I'll check this in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-09 06:03 Message: Logged In: YES user_id=80475 Whew! It takes just as long to check as 6000 line diff as it does to create the thing in the first place. The patch is accepted and ready to commit after the following corrections and review notes are addressed. Since several errors were syntactical, they could be caught by running the script. I recommend that all of the scripts be run one time before a final commit. Also, anoter additional check would be useful. Everywhere a function defined the likes of _find=string.find, re-verify that every instance of _find was fixed-up (I cannot check this from the diff file). Corrections and review notes (also attached as a separate file): In file: AutoIndent.py Replace: have = len(chars.expand(tabwidth)) With: have = len(chars.expandtabs(tabwidth)) In file: EditorWindow.py Replace: line.find('python') >= 0 With: 'python' in line In file: FormatParagraph.py Replace: data = "\n".join("\n") With: data = "\n".join(lines) In file: PyParse.py Replace: return len(str[self.stmt_start:i].expandtabs(, With: return len(str[self.stmt_start:i].expandtabs(\ In file: byteyears.py Replace: print file.ljust(file, maxlen), With: print file.ljust(maxlen), In file: fixheader.py Reverify propriety of substitution: if ord(c)<=0x80 and c.isalnum() In file: mailerdaemon.py Replace: if sub.find('warning') >= 0: return 1 With: if 'warning' in sub: return 1 In file: mailerdaemon.py Replace: errors.append(''.join((email.strip()+': '+res.group ('reason')).split())) With: errors.append(' '.join((email.strip()+': '+res.group ('reason')).split())) In file: mailerdaemon.py errors.append(''.join((email.strip()+': '+reason).split())) errors.append(' '.join((email.strip()+': '+reason).split())) In file: objgraph.py Replace: ! /usr/bin/env python With: #! /usr/bin/env python In file: pathfix.py Replace: if line.find("python") < 0: With: if "python" in line: In file: texi2html.py I don't understand the <<<<<< additions In file: treesync.py Replace: split(e.split('/') With: e.split('/') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-08 06:57 Message: Logged In: YES user_id=6380 Good idea to give it a careful check. I'd suggest to let Walter to check it in since he did the work though. Or you two can race for it. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 06:53 Message: Logged In: YES user_id=80475 Let me know if you want this done. If so, I'll give it a second check (line-by-line) for errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 From noreply@sourceforge.net Tue Sep 10 05:57:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Sep 2002 21:57:31 -0700 Subject: [Patches] [ python-Patches-572113 ] Remove import string in Tools/ directory Message-ID: Patches item #572113, was opened at 2002-06-21 09:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Remove import string in Tools/ directory Initial Comment: This patch replace string module functions with string methods and removes the "import string" for the stuff in the Tools directory. A few "import string" statements are still remaining: scripts/texi2html.py still uses string.ascii_letters, string.digits, etc. modulator/modulator.py still uses string.letters and string.digits freeze/win32.html still mentions the string module idle/AutoExpand.py still uses string.ascii_letters and string.digits idle/CallTips.py still uses string.uppercase, string.lowercase and string.digits idle/PyShell.py still uses string.ascii_letters and string.digits idle/UndoDelegator.py still uses string.ascii_letters and string.digits idle/testcode.py still uses string.capwords() ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-09 23:57 Message: Logged In: YES user_id=80475 In the interests of saving time and having maximum accuracy, I recommend reverting and then re-applying first patch and then making the changes on my list. Try not to make any other changes. It took half a day to thoroughly review that 6000 line diff. It doesn't make sense for me to re-check everything from scratch. To keep the integrity of the review, make as few changes as possible. Also, it does make sense for you to give a self-review to your final diff (remember, GvR believes in public floggings for those who break working code). Here are a couple of fast checks: -- scan the diff for ''.join and make sure it came from a join (strdata, "") -- grep the final files for >= 0: or < 0: to see if the 'in' operator applies. -- grep the final files for expand( to make sure an expandtabs( was not missed. -- grep the final files for join("\n"), join(" "), or join(' ') to see if there was an error moving the separator to the front A slower self check is to read the diff file line-by-line and mentally recompute each change and compare with the actual change. The diff review will certainly catch unintended changes like the merge conflict or the she- bang change. I know you can't run each script, but do as much as you can by importing each script to see if it gets a compilation error. This won't catch runtime errors but it will catch syntax glitches. One important group of scripts can be run. Try to give IDLE a thorough exercise. Then, when you're feeling brave, commit. Good luck! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-09 14:54 Message: Logged In: YES user_id=89016 diff2.txt is a new version of the patch (against current CVS). I rechecked the fixheader fix with: for i in xrange(256): c = chr(i) if (ord(c)<=0x80 and c.isalnum()) != (c in string.ascii_letters + string.digits): print i,c There are no differences. > In file: pathfix.py > Replace: if line.find("python") < 0: > With: if "python" in line: This should probably be: if "python" not in line: > In file: texi2html.py > I don't understand the <<<<<< additions Ouch, that was a merge conflict. OK, Raymond could you recheck if the new patch diff2.txt is OK now? These mindless changes really are tricky! ;) Unfortunately running the scripts isn't an option in most cases: Some require Tk, some might expect certain files and some might even transmogrify all the source files. I changed a few tests line[:x] == "xxx...xxx" to line.startswith("xxx...xxx") too. I rechecked the _find = string.find cases in idle/PyParse.py and script/gencodec.py. If I'll get your OK I'll check this in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 23:03 Message: Logged In: YES user_id=80475 Whew! It takes just as long to check as 6000 line diff as it does to create the thing in the first place. The patch is accepted and ready to commit after the following corrections and review notes are addressed. Since several errors were syntactical, they could be caught by running the script. I recommend that all of the scripts be run one time before a final commit. Also, anoter additional check would be useful. Everywhere a function defined the likes of _find=string.find, re-verify that every instance of _find was fixed-up (I cannot check this from the diff file). Corrections and review notes (also attached as a separate file): In file: AutoIndent.py Replace: have = len(chars.expand(tabwidth)) With: have = len(chars.expandtabs(tabwidth)) In file: EditorWindow.py Replace: line.find('python') >= 0 With: 'python' in line In file: FormatParagraph.py Replace: data = "\n".join("\n") With: data = "\n".join(lines) In file: PyParse.py Replace: return len(str[self.stmt_start:i].expandtabs(, With: return len(str[self.stmt_start:i].expandtabs(\ In file: byteyears.py Replace: print file.ljust(file, maxlen), With: print file.ljust(maxlen), In file: fixheader.py Reverify propriety of substitution: if ord(c)<=0x80 and c.isalnum() In file: mailerdaemon.py Replace: if sub.find('warning') >= 0: return 1 With: if 'warning' in sub: return 1 In file: mailerdaemon.py Replace: errors.append(''.join((email.strip()+': '+res.group ('reason')).split())) With: errors.append(' '.join((email.strip()+': '+res.group ('reason')).split())) In file: mailerdaemon.py errors.append(''.join((email.strip()+': '+reason).split())) errors.append(' '.join((email.strip()+': '+reason).split())) In file: objgraph.py Replace: ! /usr/bin/env python With: #! /usr/bin/env python In file: pathfix.py Replace: if line.find("python") < 0: With: if "python" in line: In file: texi2html.py I don't understand the <<<<<< additions In file: treesync.py Replace: split(e.split('/') With: e.split('/') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-07 23:57 Message: Logged In: YES user_id=6380 Good idea to give it a careful check. I'd suggest to let Walter to check it in since he did the work though. Or you two can race for it. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-07 23:53 Message: Logged In: YES user_id=80475 Let me know if you want this done. If so, I'll give it a second check (line-by-line) for errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 From noreply@sourceforge.net Tue Sep 10 12:38:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 04:38:25 -0700 Subject: [Patches] [ python-Patches-590513 ] Add popen2 like functionality to pty.py. Message-ID: Patches item #590513, was opened at 2002-08-04 00:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590513&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Rasjid Wilcox (rasjidw) Assigned to: Thomas Wouters (twouters) Summary: Add popen2 like functionality to pty.py. Initial Comment: This patch adds a popen2 like function to pty.py. Due to use of os.execlp in pty.spawn, it is not quite the same, as all the arguments (including the command to be run) must be passed as a tupple. It is only a first draft, and may need some more work, which I am willing to do if some direction is indicated. Tested on Python2.2, under RedHat Linux 7.3. Rasjid. ---------------------------------------------------------------------- >Comment By: Rasjid Wilcox (rasjidw) Date: 2002-09-10 21:38 Message: Logged In: YES user_id=39640 Thanks for the comments Thomas. a) I have not done docs or testcase yet. I wanted to be clear about the direction first. I will submit with my next version. b) No particular reason for threads, just more intuitive to me. On due reflection, os.fork is better. I shall drop the use of threads. c) I shall keep backward compatibility. Perhaps 'returning_spawn' for the new version. With luck, next version in a couple of weeks. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-09-09 23:57 Message: Logged In: YES user_id=34209 I have several comments, but I'm not sure if they've been adressed in other forums or not. Guido mentions documentation, but the patches attached don't seem to contain them; are they seperate ? I also don't see a testcase. - Why threads ? A seperate non-thread version, with a third process to handle the data trafficking, and falling back to that when threads are not available would be nice. - I concur the new behaviour is much more useful. However, I'm a stickler for backward compatibility, so I advice against renaming the old spawn :) - I don't like 'th_spawn'. 'spawn_thread' or 'threaded_spawn' or some such sound better to me (but see above about threads.) - Some minor whitespace issues (the line-wrap on line 150 is not necessary, line 179 is too long, and the backslashes on lines 190 and 205 are not necessary.) A comment describing why the tty.setraw() is done would also be nice. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-08-30 13:54 Message: Logged In: YES user_id=39640 Okay. My final version (I promise!). The code has been reorganised a little so that: a) it is cleaner to read b) the popen2 function now returns the pid of the child process Rasjid. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-21 04:33 Message: Logged In: YES user_id=6380 Assigning this to Thomas Wouters according to his wishes. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2002-08-16 23:47 Message: Logged In: YES user_id=34209 The pty module actually works on all platforms that provide openpty(). I know at least BSDI and FreeBSD do, in addition to Linux, and I suspect OpenBSD and NetBSD as well, and possibly other BSD-derived systems. Still, it is very unlikely to work on non-POSIX-ish systems, so /bin/sh is a safe bet. I can take a look at the patch, and test it on a variety of machines, but not before I leave on a two-week vacation, this sunday :) I have plenty of time to look at it when I'm back though, in the first week of September. Feel free to assign the patch to me, as a reminder. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-08-16 22:39 Message: Logged In: YES user_id=39640 Okay. This is essentially my final version, subject to an issue around the naming of a couple of the modules functions. My issue is that the pty.spawn funciton does not return. My new one 'th_spawn' function does. I believe quite strongly that to be consistent with the rest of python, 'th_spawn' should be renamed 'spawn', and the current spawn function should be renamed something like '_master' since it takes the place of the pty master. The issue of course is backward compatibility. However, I believe this to be relatively minor for two reasons. 1. I think very few (if any) people are using it, since it was a) largely undocumented, b) didn't always work c) wasn't particularly useful, since it only allowed control from an existing pty (so what was the point?) 2. If anyone is using it, they would _almost_ certainly be starting it on a new thread, so all that would happen if the functions were renamed would be that an extra (redundant) sub-thread is created. I have posted to comp.lang.python to see what other pty.py users think. Subject to the response here and there, I may post to python-dev in due course. Rasjid. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-06 01:20 Message: Logged In: YES user_id=6380 I mostly concur with Martin von Loewis's comments, though I'm not sure this is big enough for a PEP. I think that you're right in answering (yes, no, yes) but I have no information (portability of this module is already limited to IRIX and Linux, according to the docs). The docs use the word "baffle" -- I wonder if you could substitute something else or generally clarify that sentence; it's not very clear from the docs what spawn() does (nor what fork() does, to tell the truth -- all these could really use some examples). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-05 21:44 Message: Logged In: YES user_id=21627 I'm not a regular pty user. Please ask those questions in comp.lang.python, and python-dev. You can also ask previous authors to pty for comments. Uncertainty in such areas might be a hint that a library PEP is need, to justify the rationale for all the details. There is no need to hurry - Python 2.3 is still months away. That said, I do think that this functionality is desirable, so I'd encourage you to complete this task. ---------------------------------------------------------------------- Comment By: Rasjid Wilcox (rasjidw) Date: 2002-08-05 21:34 Message: Logged In: YES user_id=39640 Before I do docs etc, I have a few questions: 1. I could make it more popen2 like by changing the args to def popen2(cmd, ....) and adding argv=('/bin/sh','-c',cmd) Is this a better idea? Does it reduce portability? Is it safe to assume that all posix systems have /bin/sh? (My guess is yes, no and yes.) 2. Should the threading done in the pty.popen2 function be moved to a separate function, to allow more direct access to spawn. (The current spawn function does not return until the child exits or the parent closes the pipe). 3. Should I worry about how keyboard interrupts are handled? In some cases an uncontrolled process may be left hanging around. Or is it the job of the calling process to deal with that? Lastly, I am away for a week from Wednesday, so I won't be able to do much until I get back, but I will try and finish this off then. Cheers, Rasjid. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 18:56 Message: Logged In: YES user_id=21627 Can you please write documentation and a test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590513&group_id=5470 From noreply@sourceforge.net Tue Sep 10 19:17:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 11:17:57 -0700 Subject: [Patches] [ python-Patches-599836 ] Bugfix for urllib2.py Message-ID: Patches item #599836, was opened at 2002-08-25 00:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Jeremy Hylton (jhylton) Summary: Bugfix for urllib2.py Initial Comment: OpenerDirector has a default User-agent header. That wouldn't be a problem, except that AbstractHTTPHandler uses the headers in OpenerDirector.addheaders *after* a Request has been instantiated, thus making that default override whatever headers were given to Request. This patch checks to make sure a header isn't already in a Request before adding the OpenerDirector's headers. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-10 11:17 Message: Logged In: NO Is there any reasons to not use the same case as Mozilla, IE and the RFC in the User-Agent HTTP header? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-06 08:50 Message: Logged In: NO Unless you want problems, I suggest you to use the same case as Mozilla, IE and the RFC in the User-Agent HTTP header. --- python/dist/src/Lib/urllib.py +++ python/dist/src/Lib/urllib.py @@ -104,7 +104,7 @@ self.proxies = proxies self.key_file = x509.get('key_file') self.cert_file = x509.get('cert_file') - self.addheaders = [('User-agent', self.version)] + self.addheaders = [('User-Agent', self.version)] self.__tempfiles = [] self.__unlink = os.unlink # See cleanup() self.tempcache = None --- python/dist/src/Lib/urllib2.py +++ python/dist/src/Lib/urllib2.py @@ -247,7 +247,7 @@ class OpenerDirector: def __init__(self): server_version = "Python-urllib/%s" % __version__ - self.addheaders = [('User-agent', server_version)] + self.addheaders = [('User-Agent', server_version)] # manage the individual handlers self.handlers = [] self.handle_open = {} ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 11:56 Message: Logged In: YES user_id=6380 For Jeremy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599836&group_id=5470 From noreply@sourceforge.net Wed Sep 11 07:40:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 23:40:39 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 19:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 11:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 11:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 10:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 12:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 15:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 13:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 14:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 20:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 02:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 15:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 10:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 20:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Wed Sep 11 07:52:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Sep 2002 23:52:49 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 19:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:52 Message: Logged In: YES user_id=357491 I just re-uploaded the insensitive_fix_diff. I realized right after I posted my last comment that I didn't make sure to catch some other places where insensitive case was needed. I have fixed those and they are now contained in the diff for 2002-09-11. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 11:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 11:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 10:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 12:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 15:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 13:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 14:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 20:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 02:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 15:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 10:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 20:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Wed Sep 11 14:35:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 06:35:56 -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: https://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-09-11 09:35 Message: Logged In: YES user_id=240525 I am no longer involved in OpenBSD. Chris Humphries took over the Python ports, he is reachable at . I let him know about these patches in early July. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 06:03 Message: Logged In: YES user_id=21627 Are you still interested in this patch? If so, what are the answers to these questions? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-21 05: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-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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 From noreply@sourceforge.net Wed Sep 11 14:36:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 06:36:31 -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: https://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: Matt Behrens (mattbehrens) Date: 2002-09-11 09:36 Message: Logged In: YES user_id=240525 I am no longer involved in OpenBSD. Chris Humphries took over the Python ports, he is reachable at . I let him know about these patches in early July. ---------------------------------------------------------------------- Comment By: Myroslav Opyr (interra) Date: 2002-05-20 08: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:03:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:03:44 -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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 Category: Build Group: Python 2.1.2 >Status: Closed >Resolution: Out of Date 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-09-11 18:03 Message: Logged In: YES user_id=21627 Ok, closing this patch. If Chris Humphries shows any interest, we can reopen it, or he can submit a new patch. ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2002-09-11 15:35 Message: Logged In: YES user_id=240525 I am no longer involved in OpenBSD. Chris Humphries took over the Python ports, he is reachable at . I let him know about these patches in early July. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 12:03 Message: Logged In: YES user_id=21627 Are you still interested in this patch? If so, what are the answers to these questions? ---------------------------------------------------------------------- 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554718&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:04:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:04:51 -0700 Subject: [Patches] [ python-Patches-554841 ] THREAD_STACK_SIZE for 2.1 Message-ID: Patches item #554841, was opened at 2002-05-11 15:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 Category: Core (C code) Group: Python 2.1.2 >Status: Closed >Resolution: Out of Date 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: Martin v. Löwis (loewis) Date: 2002-09-11 18:04 Message: Logged In: YES user_id=21627 Closing this one as well (see 554718) ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2002-09-11 15:36 Message: Logged In: YES user_id=240525 I am no longer involved in OpenBSD. Chris Humphries took over the Python ports, he is reachable at . I let him know about these patches in early July. ---------------------------------------------------------------------- Comment By: Myroslav Opyr (interra) Date: 2002-05-20 14: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:30:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:30:20 -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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 Category: Core (C code) Group: Python 2.1.2 Status: Closed Resolution: Out of Date 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-09-11 19:30 Message: Logged In: YES user_id=327208 The pathch is closed but an issue remains. Do I have to apply the patch each time I update Python version? Zope with more or less complex CMS just blows out because of tiny stack! Sorry if I do not understand something in politics here... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 19:04 Message: Logged In: YES user_id=21627 Closing this one as well (see 554718) ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2002-09-11 16:36 Message: Logged In: YES user_id=240525 I am no longer involved in OpenBSD. Chris Humphries took over the Python ports, he is reachable at . I let him know about these patches in early July. ---------------------------------------------------------------------- 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 From noreply@sourceforge.net Wed Sep 11 17:59:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 09:59:16 -0700 Subject: [Patches] [ python-Patches-554841 ] THREAD_STACK_SIZE for 2.1 Message-ID: Patches item #554841, was opened at 2002-05-11 15:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 Category: Core (C code) Group: Python 2.1.2 Status: Closed Resolution: Out of Date 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: Martin v. Löwis (loewis) Date: 2002-09-11 18:59 Message: Logged In: YES user_id=21627 It is highly unlikely that there will be a Python 2.1.4 release. In the absence of this release, the patch is not needed. If you update to a newer Python version, it will be Python 2.2.x or Python 2.3.x; I understand that the patch is not needed on such a system. This is not at all about politics. There simply is no volunteer to make another Python 2.1 release. ---------------------------------------------------------------------- Comment By: Myroslav Opyr (interra) Date: 2002-09-11 18:30 Message: Logged In: YES user_id=327208 The pathch is closed but an issue remains. Do I have to apply the patch each time I update Python version? Zope with more or less complex CMS just blows out because of tiny stack! Sorry if I do not understand something in politics here... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:04 Message: Logged In: YES user_id=21627 Closing this one as well (see 554718) ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2002-09-11 15:36 Message: Logged In: YES user_id=240525 I am no longer involved in OpenBSD. Chris Humphries took over the Python ports, he is reachable at . I let him know about these patches in early July. ---------------------------------------------------------------------- Comment By: Myroslav Opyr (interra) Date: 2002-05-20 14: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 From noreply@sourceforge.net Wed Sep 11 18:11:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 10:11:15 -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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 Category: Core (C code) Group: Python 2.1.2 Status: Closed Resolution: Out of Date 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-09-11 20:11 Message: Logged In: YES user_id=327208 Why the increase of thread stack is not needed on Python 2.2? I just do not know that yet, because there is no Zope for Python 2.2 relesed yet. Thus I did no stress tests against Pyhton 2.2. AFAIK, there have to be Zope 2.7 which will require Python 2.2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 19:59 Message: Logged In: YES user_id=21627 It is highly unlikely that there will be a Python 2.1.4 release. In the absence of this release, the patch is not needed. If you update to a newer Python version, it will be Python 2.2.x or Python 2.3.x; I understand that the patch is not needed on such a system. This is not at all about politics. There simply is no volunteer to make another Python 2.1 release. ---------------------------------------------------------------------- Comment By: Myroslav Opyr (interra) Date: 2002-09-11 19:30 Message: Logged In: YES user_id=327208 The pathch is closed but an issue remains. Do I have to apply the patch each time I update Python version? Zope with more or less complex CMS just blows out because of tiny stack! Sorry if I do not understand something in politics here... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 19:04 Message: Logged In: YES user_id=21627 Closing this one as well (see 554718) ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2002-09-11 16:36 Message: Logged In: YES user_id=240525 I am no longer involved in OpenBSD. Chris Humphries took over the Python ports, he is reachable at . I let him know about these patches in early July. ---------------------------------------------------------------------- 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 From noreply@sourceforge.net Wed Sep 11 19:28:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 11:28:16 -0700 Subject: [Patches] [ python-Patches-554841 ] THREAD_STACK_SIZE for 2.1 Message-ID: Patches item #554841, was opened at 2002-05-11 15:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 Category: Core (C code) Group: Python 2.1.2 Status: Closed Resolution: Out of Date 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: Martin v. Löwis (loewis) Date: 2002-09-11 20:28 Message: Logged In: YES user_id=21627 Increasing the stack size might be still needed, but this patch is not - Python 2.2 already incorporates it. To quote the summary of this patch "so we could bump up the pthread stack size in the same way it is done for Python 2.2" ---------------------------------------------------------------------- Comment By: Myroslav Opyr (interra) Date: 2002-09-11 19:11 Message: Logged In: YES user_id=327208 Why the increase of thread stack is not needed on Python 2.2? I just do not know that yet, because there is no Zope for Python 2.2 relesed yet. Thus I did no stress tests against Pyhton 2.2. AFAIK, there have to be Zope 2.7 which will require Python 2.2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:59 Message: Logged In: YES user_id=21627 It is highly unlikely that there will be a Python 2.1.4 release. In the absence of this release, the patch is not needed. If you update to a newer Python version, it will be Python 2.2.x or Python 2.3.x; I understand that the patch is not needed on such a system. This is not at all about politics. There simply is no volunteer to make another Python 2.1 release. ---------------------------------------------------------------------- Comment By: Myroslav Opyr (interra) Date: 2002-09-11 18:30 Message: Logged In: YES user_id=327208 The pathch is closed but an issue remains. Do I have to apply the patch each time I update Python version? Zope with more or less complex CMS just blows out because of tiny stack! Sorry if I do not understand something in politics here... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:04 Message: Logged In: YES user_id=21627 Closing this one as well (see 554718) ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2002-09-11 15:36 Message: Logged In: YES user_id=240525 I am no longer involved in OpenBSD. Chris Humphries took over the Python ports, he is reachable at . I let him know about these patches in early July. ---------------------------------------------------------------------- Comment By: Myroslav Opyr (interra) Date: 2002-05-20 14: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554841&group_id=5470 From noreply@sourceforge.net Wed Sep 11 19:30:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 11:30:28 -0700 Subject: [Patches] [ python-Patches-606132 ] Mac OS X keydefs Message-ID: Patches item #606132, was opened at 2002-09-07 23:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606132&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X keydefs Initial Comment: Adds keydefs that are more suitable to Mac OS X; also disable CallTips in config-mac.txt due to broken tooltips in Tk. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 20:30 Message: Logged In: YES user_id=21627 The patch looks fine to me, but I'd like to get confirmation from another Mac user that these are indeed reasonable key bindings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606132&group_id=5470 From noreply@sourceforge.net Wed Sep 11 20:25:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 12:25:38 -0700 Subject: [Patches] [ python-Patches-606132 ] Mac OS X keydefs Message-ID: Patches item #606132, was opened at 2002-09-07 21:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606132&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X keydefs Initial Comment: Adds keydefs that are more suitable to Mac OS X; also disable CallTips in config-mac.txt due to broken tooltips in Tk. ---------------------------------------------------------------------- >Comment By: Tony Lownds (tonylownds) Date: 2002-09-11 19:25 Message: Logged In: YES user_id=24100 Good idea Martin, will do. Guido wants this patch to be ported to idlefork, so I guess it can be closed here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 18:30 Message: Logged In: YES user_id=21627 The patch looks fine to me, but I'd like to get confirmation from another Mac user that these are indeed reasonable key bindings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606132&group_id=5470 From noreply@sourceforge.net Wed Sep 11 21:48:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 13:48:54 -0700 Subject: [Patches] [ python-Patches-572113 ] Remove import string in Tools/ directory Message-ID: Patches item #572113, was opened at 2002-06-21 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Remove import string in Tools/ directory Initial Comment: This patch replace string module functions with string methods and removes the "import string" for the stuff in the Tools directory. A few "import string" statements are still remaining: scripts/texi2html.py still uses string.ascii_letters, string.digits, etc. modulator/modulator.py still uses string.letters and string.digits freeze/win32.html still mentions the string module idle/AutoExpand.py still uses string.ascii_letters and string.digits idle/CallTips.py still uses string.uppercase, string.lowercase and string.digits idle/PyShell.py still uses string.ascii_letters and string.digits idle/UndoDelegator.py still uses string.ascii_letters and string.digits idle/testcode.py still uses string.capwords() ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2002-09-11 22:48 Message: Logged In: YES user_id=89016 I rechecked the patch line-by-line and imported every module that seemed to be importable (and found a (last?) bug in bgen/bgen/scantools.py), so I finally checked it in as: audiopy/audiopy 1.20 bgen/bgen/bgenGenerator.py 1.14 bgen/bgen/bgenOutput.py 1.4 bgen/bgen/scantools.py 1.32 faqwiz/faqwiz.py 1.28 freeze/checkextensions.py 1.5 freeze/checkextensions_win32.py 1.7 freeze/freeze.py 1.42 freeze/makefreeze.py 1.14 freeze/makemakefile.py 1.7 freeze/modulefinder.py 1.20 freeze/parsesetup.py 1.4 freeze/winmakemakefile.py 1.12 idle/AutoIndent.py 1.20 idle/Bindings.py 1.16 idle/CallTips.py 1.12 idle/ClassBrowser.py 1.13 idle/ColorDelegator.py 1.13 idle/EditorWindow.py 1.44 idle/FormatParagraph.py 1.10 idle/GrepDialog.py 1.4 idle/IdleHistory.py 1.5 idle/MultiScrolledLists.py 1.3 idle/OldStackViewer.py 1.2 idle/ParenMatch.py 1.6 idle/PyParse.py 1.10 idle/PyShell.py 1.40 idle/ReplaceDialog.py 1.8 idle/SearchDialogBase.py 1.2 idle/SearchEngine.py 1.3 idle/StackViewer.py 1.17 idle/TreeWidget.py 1.8 idle/UndoDelegator.py 1.5 idle/eventparse.py 1.2 modulator/genmodule.py 1.5 modulator/modulator.py 1.10 modulator/varsubst.py 1.4 scripts/byteyears.py 1.8 scripts/checkappend.py 1.3 scripts/classfix.py 1.12 scripts/cvsfiles.py 1.5 scripts/dutree.py 1.11 scripts/fixcid.py 1.10 scripts/fixheader.py 1.5 scripts/ftpmirror.py 1.15 scripts/gencodec.py 1.7 scripts/ifdef.py 1.5 scripts/logmerge.py 1.8 scripts/mailerdaemon.py 1.10 scripts/methfix.py 1.7 scripts/nm2def.py 1.5 scripts/objgraph.py 1.6 scripts/pathfix.py 1.5 scripts/pdeps.py 1.6 scripts/pindent.py 1.11 scripts/rgrep.py 1.2 scripts/sum5.py 1.5 scripts/trace.py 1.9 scripts/treesync.py 1.6 scripts/untabify.py 1.3 scripts/which.py 1.10 scripts/xxci.py 1.15 unicode/makeunicodedata.py 1.12 versioncheck/checkversions.py 1.3 versioncheck/pyversioncheck.py 1.4 webchecker/tktools.py 1.3 webchecker/wcgui.py 1.9 webchecker/webchecker.py 1.28 webchecker/websucker.py 1.10 webchecker/wsgui.py 1.6 Waiting for the public floggings now... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 06:57 Message: Logged In: YES user_id=80475 In the interests of saving time and having maximum accuracy, I recommend reverting and then re-applying first patch and then making the changes on my list. Try not to make any other changes. It took half a day to thoroughly review that 6000 line diff. It doesn't make sense for me to re-check everything from scratch. To keep the integrity of the review, make as few changes as possible. Also, it does make sense for you to give a self-review to your final diff (remember, GvR believes in public floggings for those who break working code). Here are a couple of fast checks: -- scan the diff for ''.join and make sure it came from a join (strdata, "") -- grep the final files for >= 0: or < 0: to see if the 'in' operator applies. -- grep the final files for expand( to make sure an expandtabs( was not missed. -- grep the final files for join("\n"), join(" "), or join(' ') to see if there was an error moving the separator to the front A slower self check is to read the diff file line-by-line and mentally recompute each change and compare with the actual change. The diff review will certainly catch unintended changes like the merge conflict or the she- bang change. I know you can't run each script, but do as much as you can by importing each script to see if it gets a compilation error. This won't catch runtime errors but it will catch syntax glitches. One important group of scripts can be run. Try to give IDLE a thorough exercise. Then, when you're feeling brave, commit. Good luck! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-09 21:54 Message: Logged In: YES user_id=89016 diff2.txt is a new version of the patch (against current CVS). I rechecked the fixheader fix with: for i in xrange(256): c = chr(i) if (ord(c)<=0x80 and c.isalnum()) != (c in string.ascii_letters + string.digits): print i,c There are no differences. > In file: pathfix.py > Replace: if line.find("python") < 0: > With: if "python" in line: This should probably be: if "python" not in line: > In file: texi2html.py > I don't understand the <<<<<< additions Ouch, that was a merge conflict. OK, Raymond could you recheck if the new patch diff2.txt is OK now? These mindless changes really are tricky! ;) Unfortunately running the scripts isn't an option in most cases: Some require Tk, some might expect certain files and some might even transmogrify all the source files. I changed a few tests line[:x] == "xxx...xxx" to line.startswith("xxx...xxx") too. I rechecked the _find = string.find cases in idle/PyParse.py and script/gencodec.py. If I'll get your OK I'll check this in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-09 06:03 Message: Logged In: YES user_id=80475 Whew! It takes just as long to check as 6000 line diff as it does to create the thing in the first place. The patch is accepted and ready to commit after the following corrections and review notes are addressed. Since several errors were syntactical, they could be caught by running the script. I recommend that all of the scripts be run one time before a final commit. Also, anoter additional check would be useful. Everywhere a function defined the likes of _find=string.find, re-verify that every instance of _find was fixed-up (I cannot check this from the diff file). Corrections and review notes (also attached as a separate file): In file: AutoIndent.py Replace: have = len(chars.expand(tabwidth)) With: have = len(chars.expandtabs(tabwidth)) In file: EditorWindow.py Replace: line.find('python') >= 0 With: 'python' in line In file: FormatParagraph.py Replace: data = "\n".join("\n") With: data = "\n".join(lines) In file: PyParse.py Replace: return len(str[self.stmt_start:i].expandtabs(, With: return len(str[self.stmt_start:i].expandtabs(\ In file: byteyears.py Replace: print file.ljust(file, maxlen), With: print file.ljust(maxlen), In file: fixheader.py Reverify propriety of substitution: if ord(c)<=0x80 and c.isalnum() In file: mailerdaemon.py Replace: if sub.find('warning') >= 0: return 1 With: if 'warning' in sub: return 1 In file: mailerdaemon.py Replace: errors.append(''.join((email.strip()+': '+res.group ('reason')).split())) With: errors.append(' '.join((email.strip()+': '+res.group ('reason')).split())) In file: mailerdaemon.py errors.append(''.join((email.strip()+': '+reason).split())) errors.append(' '.join((email.strip()+': '+reason).split())) In file: objgraph.py Replace: ! /usr/bin/env python With: #! /usr/bin/env python In file: pathfix.py Replace: if line.find("python") < 0: With: if "python" in line: In file: texi2html.py I don't understand the <<<<<< additions In file: treesync.py Replace: split(e.split('/') With: e.split('/') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-08 06:57 Message: Logged In: YES user_id=6380 Good idea to give it a careful check. I'd suggest to let Walter to check it in since he did the work though. Or you two can race for it. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 06:53 Message: Logged In: YES user_id=80475 Let me know if you want this done. If so, I'll give it a second check (line-by-line) for errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 From noreply@sourceforge.net Wed Sep 11 22:11:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 14:11:03 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 19:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2002-09-11 14:11 Message: Logged In: YES user_id=357491 OK, so I have uploaded a bunch of files (thanks, Neal, for deleting the old files): cleanup_diff -- cleans up __getitem__() in TimeRE. comments_diff -- adds a single comment and adds an "a" in a doc string. c_test_diff -- fixes test_strptime.py's %c, %x, and %X tests to use the magic date so as to avoid the issue that cropped up of strftime using the funky ANSI space-leading day of the month. missing_info_test_diff -- Adds a test for the lacking locale info bug. case_test_diff -- Adds tests to make sure that case-insensitivity is handled. So, for _strptime.py, the order that the patches were generated are: missing_info_diff insensitive_fix_diff cleanup_diff comments_diff For test/test_strptime.py, the order of the patches were generated are: c_test_diff missing_info_test_diff case_test_diff For all of these patches I just edited my local copy of the CVS version of the file following my altered copy as a guide. When I did a set of edits, I generated a diff. I then continued to edit that same for the next diff. Is that the right way to do it? Should I have deleted my edited copy, get the CVS version, and edited that one? Now I realize that test/test_strptime.py is not formatted very well. I am happy to fix my messy code and make all the lines break at 80 characters, but I have a question about my test patches before I do the reformatting. For the new patches I added the tests to the test methods I thought they belonged in. But I noticed after I generated the patches that Barry put his 12-hour test as a completely separate testing suite. Should I redo my patches so that the tests are separate? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:52 Message: Logged In: YES user_id=357491 I just re-uploaded the insensitive_fix_diff. I realized right after I posted my last comment that I didn't make sure to catch some other places where insensitive case was needed. I have fixed those and they are now contained in the diff for 2002-09-11. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 11:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 11:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 10:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 12:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 15:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 13:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 14:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 20:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 02:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 15:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 10:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 20:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Thu Sep 12 00:08:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 16:08:23 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 19:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2002-09-11 16:08 Message: Logged In: YES user_id=357491 I really need to stop playing with this code. =) I generated another diff for _strptime.py that changes the loop in TimeRE._seqToRE to use '|'.join(). Cleaner and also alters the regex so that it doesn't explicitly use (?:) since | binds so weakly. The diff is join_diff. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 14:11 Message: Logged In: YES user_id=357491 OK, so I have uploaded a bunch of files (thanks, Neal, for deleting the old files): cleanup_diff -- cleans up __getitem__() in TimeRE. comments_diff -- adds a single comment and adds an "a" in a doc string. c_test_diff -- fixes test_strptime.py's %c, %x, and %X tests to use the magic date so as to avoid the issue that cropped up of strftime using the funky ANSI space-leading day of the month. missing_info_test_diff -- Adds a test for the lacking locale info bug. case_test_diff -- Adds tests to make sure that case-insensitivity is handled. So, for _strptime.py, the order that the patches were generated are: missing_info_diff insensitive_fix_diff cleanup_diff comments_diff For test/test_strptime.py, the order of the patches were generated are: c_test_diff missing_info_test_diff case_test_diff For all of these patches I just edited my local copy of the CVS version of the file following my altered copy as a guide. When I did a set of edits, I generated a diff. I then continued to edit that same for the next diff. Is that the right way to do it? Should I have deleted my edited copy, get the CVS version, and edited that one? Now I realize that test/test_strptime.py is not formatted very well. I am happy to fix my messy code and make all the lines break at 80 characters, but I have a question about my test patches before I do the reformatting. For the new patches I added the tests to the test methods I thought they belonged in. But I noticed after I generated the patches that Barry put his 12-hour test as a completely separate testing suite. Should I redo my patches so that the tests are separate? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:52 Message: Logged In: YES user_id=357491 I just re-uploaded the insensitive_fix_diff. I realized right after I posted my last comment that I didn't make sure to catch some other places where insensitive case was needed. I have fixed those and they are now contained in the diff for 2002-09-11. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 11:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 11:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 10:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 12:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 15:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 13:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 14:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 20:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 02:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 15:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 10:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 20:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Thu Sep 12 04:42:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 20:42:26 -0700 Subject: [Patches] [ python-Patches-536578 ] patch for bug 462783 mmap bus error Message-ID: Patches item #536578, was opened at 2002-03-28 22:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=536578&group_id=5470 Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Green (gpgreen) >Assigned to: Neal Norwitz (nnorwitz) Summary: patch for bug 462783 mmap bus error Initial Comment: This patch fixes SF 462783. The problem was that an mmap'ed file caused a bus error when reading data from the file. The root cause is that the file wasn't flushed following a write. The patched module will throw an OSError exception if the mmap object was created without being flushed, fseek'ed, or closed, following a write. This patch only applies to unix systems. Windows seems to handle the condition ok. The problem with the patch is that existing code can be broken. On some systems, (FreeBSD, irix), as long as the file was flushed before attempting to read from the mmap object, it would work with no bus error. Linux gets a bus error no matter what. So existing code that did flush (or fseek) before a read will now get an OSError exception during mmap creation instead. I tried this on the cvs version of python 2.3, on linux redhat 7.2, FreeBSD 4.5, irix 6.5 n32, and windows 2000. -- Greg Green ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-11 23:42 Message: Logged In: YES user_id=33168 Greg, thanks for the patch. Unfortunately, I didn't notice this patch or the original bug report until after fixing bug 585792. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-05 10:18 Message: Logged In: YES user_id=6380 One comment from Andrew Dalke (who submitted bug 462783) about the patch: There's a small typo in the patch to test_mmap.py. Line 277 says ... not in ('win32'): when it should say ... not in ('win32', ): (Personally, I'd write ... != 'win32' or ... not in ['win32'] --GvR) Assigning to AMK since it's his module. ---------------------------------------------------------------------- Comment By: Greg Green (gpgreen) Date: 2002-03-29 13:49 Message: Logged In: YES user_id=499627 my email is gregory.p.green@boeing.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=536578&group_id=5470 From noreply@sourceforge.net Thu Sep 12 04:45:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 20:45:19 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-11 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taral (taral) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced file constructor Initial Comment: This patch allows the file constructor to take a file descriptor, allowing for much easier extension of its functionality. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 From noreply@sourceforge.net Thu Sep 12 04:47:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 20:47:19 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-11 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taral (taral) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced file constructor Initial Comment: This patch allows the file constructor to take a file descriptor, allowing for much easier extension of its functionality. ---------------------------------------------------------------------- >Comment By: Taral (taral) Date: 2002-09-11 22:47 Message: Logged In: YES user_id=25129 Bah, forgot the variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 From noreply@sourceforge.net Thu Sep 12 05:10:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 21:10:07 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-11 23:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taral (taral) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced file constructor Initial Comment: This patch allows the file constructor to take a file descriptor, allowing for much easier extension of its functionality. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-12 00:10 Message: Logged In: YES user_id=33168 fp's and fd's are not interchangable. The variable should be called fd, since it's an int. fill_file_fields() 2nd arg is a FILE*, not an int. So you would need to do file = fdopen(fd, mode), then pass file as the 2nd arg. In order for this patch to be accepted, a test would also need to be added (see Lib/test/test_file.py) and doc should be updated (see Doc/lib/libfuncs.tex). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-11 23:47 Message: Logged In: YES user_id=25129 Bah, forgot the variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 From noreply@sourceforge.net Thu Sep 12 05:24:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 21:24:51 -0700 Subject: [Patches] [ python-Patches-531491 ] PEP 4 update: deprecations Message-ID: Patches item #531491, was opened at 2002-03-18 14:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531491&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Martin v. Löwis (loewis) Summary: PEP 4 update: deprecations Initial Comment: The following modules should be deprecated for Python 2.3: mimify.py, rfc822.py, MIMEWriter.py, and mimetools.py. All are supplanted by Python 2.2's email package. Attached is the proposed mod to PEP 4 as per procedure described therein. I am not including mods to the module documents as those should be easy to add. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-12 00:24 Message: Logged In: YES user_id=33168 Martin, is there anything else that needs to be done or can we update PEP 4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531491&group_id=5470 From noreply@sourceforge.net Thu Sep 12 05:39:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 21:39:57 -0700 Subject: [Patches] [ python-Patches-572113 ] Remove import string in Tools/ directory Message-ID: Patches item #572113, was opened at 2002-06-21 10:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Remove import string in Tools/ directory Initial Comment: This patch replace string module functions with string methods and removes the "import string" for the stuff in the Tools directory. A few "import string" statements are still remaining: scripts/texi2html.py still uses string.ascii_letters, string.digits, etc. modulator/modulator.py still uses string.letters and string.digits freeze/win32.html still mentions the string module idle/AutoExpand.py still uses string.ascii_letters and string.digits idle/CallTips.py still uses string.uppercase, string.lowercase and string.digits idle/PyShell.py still uses string.ascii_letters and string.digits idle/UndoDelegator.py still uses string.ascii_letters and string.digits idle/testcode.py still uses string.capwords() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-12 00:39 Message: Logged In: YES user_id=33168 Walter, can this be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-11 16:48 Message: Logged In: YES user_id=89016 I rechecked the patch line-by-line and imported every module that seemed to be importable (and found a (last?) bug in bgen/bgen/scantools.py), so I finally checked it in as: audiopy/audiopy 1.20 bgen/bgen/bgenGenerator.py 1.14 bgen/bgen/bgenOutput.py 1.4 bgen/bgen/scantools.py 1.32 faqwiz/faqwiz.py 1.28 freeze/checkextensions.py 1.5 freeze/checkextensions_win32.py 1.7 freeze/freeze.py 1.42 freeze/makefreeze.py 1.14 freeze/makemakefile.py 1.7 freeze/modulefinder.py 1.20 freeze/parsesetup.py 1.4 freeze/winmakemakefile.py 1.12 idle/AutoIndent.py 1.20 idle/Bindings.py 1.16 idle/CallTips.py 1.12 idle/ClassBrowser.py 1.13 idle/ColorDelegator.py 1.13 idle/EditorWindow.py 1.44 idle/FormatParagraph.py 1.10 idle/GrepDialog.py 1.4 idle/IdleHistory.py 1.5 idle/MultiScrolledLists.py 1.3 idle/OldStackViewer.py 1.2 idle/ParenMatch.py 1.6 idle/PyParse.py 1.10 idle/PyShell.py 1.40 idle/ReplaceDialog.py 1.8 idle/SearchDialogBase.py 1.2 idle/SearchEngine.py 1.3 idle/StackViewer.py 1.17 idle/TreeWidget.py 1.8 idle/UndoDelegator.py 1.5 idle/eventparse.py 1.2 modulator/genmodule.py 1.5 modulator/modulator.py 1.10 modulator/varsubst.py 1.4 scripts/byteyears.py 1.8 scripts/checkappend.py 1.3 scripts/classfix.py 1.12 scripts/cvsfiles.py 1.5 scripts/dutree.py 1.11 scripts/fixcid.py 1.10 scripts/fixheader.py 1.5 scripts/ftpmirror.py 1.15 scripts/gencodec.py 1.7 scripts/ifdef.py 1.5 scripts/logmerge.py 1.8 scripts/mailerdaemon.py 1.10 scripts/methfix.py 1.7 scripts/nm2def.py 1.5 scripts/objgraph.py 1.6 scripts/pathfix.py 1.5 scripts/pdeps.py 1.6 scripts/pindent.py 1.11 scripts/rgrep.py 1.2 scripts/sum5.py 1.5 scripts/trace.py 1.9 scripts/treesync.py 1.6 scripts/untabify.py 1.3 scripts/which.py 1.10 scripts/xxci.py 1.15 unicode/makeunicodedata.py 1.12 versioncheck/checkversions.py 1.3 versioncheck/pyversioncheck.py 1.4 webchecker/tktools.py 1.3 webchecker/wcgui.py 1.9 webchecker/webchecker.py 1.28 webchecker/websucker.py 1.10 webchecker/wsgui.py 1.6 Waiting for the public floggings now... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 00:57 Message: Logged In: YES user_id=80475 In the interests of saving time and having maximum accuracy, I recommend reverting and then re-applying first patch and then making the changes on my list. Try not to make any other changes. It took half a day to thoroughly review that 6000 line diff. It doesn't make sense for me to re-check everything from scratch. To keep the integrity of the review, make as few changes as possible. Also, it does make sense for you to give a self-review to your final diff (remember, GvR believes in public floggings for those who break working code). Here are a couple of fast checks: -- scan the diff for ''.join and make sure it came from a join (strdata, "") -- grep the final files for >= 0: or < 0: to see if the 'in' operator applies. -- grep the final files for expand( to make sure an expandtabs( was not missed. -- grep the final files for join("\n"), join(" "), or join(' ') to see if there was an error moving the separator to the front A slower self check is to read the diff file line-by-line and mentally recompute each change and compare with the actual change. The diff review will certainly catch unintended changes like the merge conflict or the she- bang change. I know you can't run each script, but do as much as you can by importing each script to see if it gets a compilation error. This won't catch runtime errors but it will catch syntax glitches. One important group of scripts can be run. Try to give IDLE a thorough exercise. Then, when you're feeling brave, commit. Good luck! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-09 15:54 Message: Logged In: YES user_id=89016 diff2.txt is a new version of the patch (against current CVS). I rechecked the fixheader fix with: for i in xrange(256): c = chr(i) if (ord(c)<=0x80 and c.isalnum()) != (c in string.ascii_letters + string.digits): print i,c There are no differences. > In file: pathfix.py > Replace: if line.find("python") < 0: > With: if "python" in line: This should probably be: if "python" not in line: > In file: texi2html.py > I don't understand the <<<<<< additions Ouch, that was a merge conflict. OK, Raymond could you recheck if the new patch diff2.txt is OK now? These mindless changes really are tricky! ;) Unfortunately running the scripts isn't an option in most cases: Some require Tk, some might expect certain files and some might even transmogrify all the source files. I changed a few tests line[:x] == "xxx...xxx" to line.startswith("xxx...xxx") too. I rechecked the _find = string.find cases in idle/PyParse.py and script/gencodec.py. If I'll get your OK I'll check this in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-09 00:03 Message: Logged In: YES user_id=80475 Whew! It takes just as long to check as 6000 line diff as it does to create the thing in the first place. The patch is accepted and ready to commit after the following corrections and review notes are addressed. Since several errors were syntactical, they could be caught by running the script. I recommend that all of the scripts be run one time before a final commit. Also, anoter additional check would be useful. Everywhere a function defined the likes of _find=string.find, re-verify that every instance of _find was fixed-up (I cannot check this from the diff file). Corrections and review notes (also attached as a separate file): In file: AutoIndent.py Replace: have = len(chars.expand(tabwidth)) With: have = len(chars.expandtabs(tabwidth)) In file: EditorWindow.py Replace: line.find('python') >= 0 With: 'python' in line In file: FormatParagraph.py Replace: data = "\n".join("\n") With: data = "\n".join(lines) In file: PyParse.py Replace: return len(str[self.stmt_start:i].expandtabs(, With: return len(str[self.stmt_start:i].expandtabs(\ In file: byteyears.py Replace: print file.ljust(file, maxlen), With: print file.ljust(maxlen), In file: fixheader.py Reverify propriety of substitution: if ord(c)<=0x80 and c.isalnum() In file: mailerdaemon.py Replace: if sub.find('warning') >= 0: return 1 With: if 'warning' in sub: return 1 In file: mailerdaemon.py Replace: errors.append(''.join((email.strip()+': '+res.group ('reason')).split())) With: errors.append(' '.join((email.strip()+': '+res.group ('reason')).split())) In file: mailerdaemon.py errors.append(''.join((email.strip()+': '+reason).split())) errors.append(' '.join((email.strip()+': '+reason).split())) In file: objgraph.py Replace: ! /usr/bin/env python With: #! /usr/bin/env python In file: pathfix.py Replace: if line.find("python") < 0: With: if "python" in line: In file: texi2html.py I don't understand the <<<<<< additions In file: treesync.py Replace: split(e.split('/') With: e.split('/') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-08 00:57 Message: Logged In: YES user_id=6380 Good idea to give it a careful check. I'd suggest to let Walter to check it in since he did the work though. Or you two can race for it. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 00:53 Message: Logged In: YES user_id=80475 Let me know if you want this done. If so, I'll give it a second check (line-by-line) for errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 From noreply@sourceforge.net Thu Sep 12 06:31:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 22:31:56 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-11 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taral (taral) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced file constructor Initial Comment: This patch allows the file constructor to take a file descriptor, allowing for much easier extension of its functionality. ---------------------------------------------------------------------- >Comment By: Taral (taral) Date: 2002-09-12 00:31 Message: Logged In: YES user_id=25129 Okay, fixed it all. Passes 'make test' on linux/x86 with default configure (does not test dbm/gdbm/mpz/bsddb). (btw, old versions can be deleted) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-11 23:10 Message: Logged In: YES user_id=33168 fp's and fd's are not interchangable. The variable should be called fd, since it's an int. fill_file_fields() 2nd arg is a FILE*, not an int. So you would need to do file = fdopen(fd, mode), then pass file as the 2nd arg. In order for this patch to be accepted, a test would also need to be added (see Lib/test/test_file.py) and doc should be updated (see Doc/lib/libfuncs.tex). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-11 22:47 Message: Logged In: YES user_id=25129 Bah, forgot the variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 From noreply@sourceforge.net Thu Sep 12 07:59:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Sep 2002 23:59:10 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-12 05:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taral (taral) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced file constructor Initial Comment: This patch allows the file constructor to take a file descriptor, allowing for much easier extension of its functionality. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-12 08:59 Message: Logged In: YES user_id=21627 What's wrong with os.fdopen? Why is f = file(10, "r") much easier than f = os.fdopen(10, "r") ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-12 07:31 Message: Logged In: YES user_id=25129 Okay, fixed it all. Passes 'make test' on linux/x86 with default configure (does not test dbm/gdbm/mpz/bsddb). (btw, old versions can be deleted) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-12 06:10 Message: Logged In: YES user_id=33168 fp's and fd's are not interchangable. The variable should be called fd, since it's an int. fill_file_fields() 2nd arg is a FILE*, not an int. So you would need to do file = fdopen(fd, mode), then pass file as the 2nd arg. In order for this patch to be accepted, a test would also need to be added (see Lib/test/test_file.py) and doc should be updated (see Doc/lib/libfuncs.tex). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-12 05:47 Message: Logged In: YES user_id=25129 Bah, forgot the variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 From noreply@sourceforge.net Thu Sep 12 10:58:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 02:58:55 -0700 Subject: [Patches] [ python-Patches-572113 ] Remove import string in Tools/ directory Message-ID: Patches item #572113, was opened at 2002-06-21 16:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Remove import string in Tools/ directory Initial Comment: This patch replace string module functions with string methods and removes the "import string" for the stuff in the Tools directory. A few "import string" statements are still remaining: scripts/texi2html.py still uses string.ascii_letters, string.digits, etc. modulator/modulator.py still uses string.letters and string.digits freeze/win32.html still mentions the string module idle/AutoExpand.py still uses string.ascii_letters and string.digits idle/CallTips.py still uses string.uppercase, string.lowercase and string.digits idle/PyShell.py still uses string.ascii_letters and string.digits idle/UndoDelegator.py still uses string.ascii_letters and string.digits idle/testcode.py still uses string.capwords() ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-12 06:39 Message: Logged In: YES user_id=33168 Walter, can this be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-11 22:48 Message: Logged In: YES user_id=89016 I rechecked the patch line-by-line and imported every module that seemed to be importable (and found a (last?) bug in bgen/bgen/scantools.py), so I finally checked it in as: audiopy/audiopy 1.20 bgen/bgen/bgenGenerator.py 1.14 bgen/bgen/bgenOutput.py 1.4 bgen/bgen/scantools.py 1.32 faqwiz/faqwiz.py 1.28 freeze/checkextensions.py 1.5 freeze/checkextensions_win32.py 1.7 freeze/freeze.py 1.42 freeze/makefreeze.py 1.14 freeze/makemakefile.py 1.7 freeze/modulefinder.py 1.20 freeze/parsesetup.py 1.4 freeze/winmakemakefile.py 1.12 idle/AutoIndent.py 1.20 idle/Bindings.py 1.16 idle/CallTips.py 1.12 idle/ClassBrowser.py 1.13 idle/ColorDelegator.py 1.13 idle/EditorWindow.py 1.44 idle/FormatParagraph.py 1.10 idle/GrepDialog.py 1.4 idle/IdleHistory.py 1.5 idle/MultiScrolledLists.py 1.3 idle/OldStackViewer.py 1.2 idle/ParenMatch.py 1.6 idle/PyParse.py 1.10 idle/PyShell.py 1.40 idle/ReplaceDialog.py 1.8 idle/SearchDialogBase.py 1.2 idle/SearchEngine.py 1.3 idle/StackViewer.py 1.17 idle/TreeWidget.py 1.8 idle/UndoDelegator.py 1.5 idle/eventparse.py 1.2 modulator/genmodule.py 1.5 modulator/modulator.py 1.10 modulator/varsubst.py 1.4 scripts/byteyears.py 1.8 scripts/checkappend.py 1.3 scripts/classfix.py 1.12 scripts/cvsfiles.py 1.5 scripts/dutree.py 1.11 scripts/fixcid.py 1.10 scripts/fixheader.py 1.5 scripts/ftpmirror.py 1.15 scripts/gencodec.py 1.7 scripts/ifdef.py 1.5 scripts/logmerge.py 1.8 scripts/mailerdaemon.py 1.10 scripts/methfix.py 1.7 scripts/nm2def.py 1.5 scripts/objgraph.py 1.6 scripts/pathfix.py 1.5 scripts/pdeps.py 1.6 scripts/pindent.py 1.11 scripts/rgrep.py 1.2 scripts/sum5.py 1.5 scripts/trace.py 1.9 scripts/treesync.py 1.6 scripts/untabify.py 1.3 scripts/which.py 1.10 scripts/xxci.py 1.15 unicode/makeunicodedata.py 1.12 versioncheck/checkversions.py 1.3 versioncheck/pyversioncheck.py 1.4 webchecker/tktools.py 1.3 webchecker/wcgui.py 1.9 webchecker/webchecker.py 1.28 webchecker/websucker.py 1.10 webchecker/wsgui.py 1.6 Waiting for the public floggings now... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 06:57 Message: Logged In: YES user_id=80475 In the interests of saving time and having maximum accuracy, I recommend reverting and then re-applying first patch and then making the changes on my list. Try not to make any other changes. It took half a day to thoroughly review that 6000 line diff. It doesn't make sense for me to re-check everything from scratch. To keep the integrity of the review, make as few changes as possible. Also, it does make sense for you to give a self-review to your final diff (remember, GvR believes in public floggings for those who break working code). Here are a couple of fast checks: -- scan the diff for ''.join and make sure it came from a join (strdata, "") -- grep the final files for >= 0: or < 0: to see if the 'in' operator applies. -- grep the final files for expand( to make sure an expandtabs( was not missed. -- grep the final files for join("\n"), join(" "), or join(' ') to see if there was an error moving the separator to the front A slower self check is to read the diff file line-by-line and mentally recompute each change and compare with the actual change. The diff review will certainly catch unintended changes like the merge conflict or the she- bang change. I know you can't run each script, but do as much as you can by importing each script to see if it gets a compilation error. This won't catch runtime errors but it will catch syntax glitches. One important group of scripts can be run. Try to give IDLE a thorough exercise. Then, when you're feeling brave, commit. Good luck! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-09 21:54 Message: Logged In: YES user_id=89016 diff2.txt is a new version of the patch (against current CVS). I rechecked the fixheader fix with: for i in xrange(256): c = chr(i) if (ord(c)<=0x80 and c.isalnum()) != (c in string.ascii_letters + string.digits): print i,c There are no differences. > In file: pathfix.py > Replace: if line.find("python") < 0: > With: if "python" in line: This should probably be: if "python" not in line: > In file: texi2html.py > I don't understand the <<<<<< additions Ouch, that was a merge conflict. OK, Raymond could you recheck if the new patch diff2.txt is OK now? These mindless changes really are tricky! ;) Unfortunately running the scripts isn't an option in most cases: Some require Tk, some might expect certain files and some might even transmogrify all the source files. I changed a few tests line[:x] == "xxx...xxx" to line.startswith("xxx...xxx") too. I rechecked the _find = string.find cases in idle/PyParse.py and script/gencodec.py. If I'll get your OK I'll check this in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-09 06:03 Message: Logged In: YES user_id=80475 Whew! It takes just as long to check as 6000 line diff as it does to create the thing in the first place. The patch is accepted and ready to commit after the following corrections and review notes are addressed. Since several errors were syntactical, they could be caught by running the script. I recommend that all of the scripts be run one time before a final commit. Also, anoter additional check would be useful. Everywhere a function defined the likes of _find=string.find, re-verify that every instance of _find was fixed-up (I cannot check this from the diff file). Corrections and review notes (also attached as a separate file): In file: AutoIndent.py Replace: have = len(chars.expand(tabwidth)) With: have = len(chars.expandtabs(tabwidth)) In file: EditorWindow.py Replace: line.find('python') >= 0 With: 'python' in line In file: FormatParagraph.py Replace: data = "\n".join("\n") With: data = "\n".join(lines) In file: PyParse.py Replace: return len(str[self.stmt_start:i].expandtabs(, With: return len(str[self.stmt_start:i].expandtabs(\ In file: byteyears.py Replace: print file.ljust(file, maxlen), With: print file.ljust(maxlen), In file: fixheader.py Reverify propriety of substitution: if ord(c)<=0x80 and c.isalnum() In file: mailerdaemon.py Replace: if sub.find('warning') >= 0: return 1 With: if 'warning' in sub: return 1 In file: mailerdaemon.py Replace: errors.append(''.join((email.strip()+': '+res.group ('reason')).split())) With: errors.append(' '.join((email.strip()+': '+res.group ('reason')).split())) In file: mailerdaemon.py errors.append(''.join((email.strip()+': '+reason).split())) errors.append(' '.join((email.strip()+': '+reason).split())) In file: objgraph.py Replace: ! /usr/bin/env python With: #! /usr/bin/env python In file: pathfix.py Replace: if line.find("python") < 0: With: if "python" in line: In file: texi2html.py I don't understand the <<<<<< additions In file: treesync.py Replace: split(e.split('/') With: e.split('/') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-08 06:57 Message: Logged In: YES user_id=6380 Good idea to give it a careful check. I'd suggest to let Walter to check it in since he did the work though. Or you two can race for it. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 06:53 Message: Logged In: YES user_id=80475 Let me know if you want this done. If so, I'll give it a second check (line-by-line) for errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 From noreply@sourceforge.net Thu Sep 12 14:17:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 06:17:59 -0700 Subject: [Patches] [ python-Patches-572113 ] Remove import string in Tools/ directory Message-ID: Patches item #572113, was opened at 2002-06-21 10:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Walter Dörwald (doerwalter) Summary: Remove import string in Tools/ directory Initial Comment: This patch replace string module functions with string methods and removes the "import string" for the stuff in the Tools directory. A few "import string" statements are still remaining: scripts/texi2html.py still uses string.ascii_letters, string.digits, etc. modulator/modulator.py still uses string.letters and string.digits freeze/win32.html still mentions the string module idle/AutoExpand.py still uses string.ascii_letters and string.digits idle/CallTips.py still uses string.uppercase, string.lowercase and string.digits idle/PyShell.py still uses string.ascii_letters and string.digits idle/UndoDelegator.py still uses string.ascii_letters and string.digits idle/testcode.py still uses string.capwords() ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-12 09:17 Message: Logged In: YES user_id=6380 I'd just like to say, thanks! to Walter and Raymond for doing this thankless work. :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-12 00:39 Message: Logged In: YES user_id=33168 Walter, can this be closed now? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-11 16:48 Message: Logged In: YES user_id=89016 I rechecked the patch line-by-line and imported every module that seemed to be importable (and found a (last?) bug in bgen/bgen/scantools.py), so I finally checked it in as: audiopy/audiopy 1.20 bgen/bgen/bgenGenerator.py 1.14 bgen/bgen/bgenOutput.py 1.4 bgen/bgen/scantools.py 1.32 faqwiz/faqwiz.py 1.28 freeze/checkextensions.py 1.5 freeze/checkextensions_win32.py 1.7 freeze/freeze.py 1.42 freeze/makefreeze.py 1.14 freeze/makemakefile.py 1.7 freeze/modulefinder.py 1.20 freeze/parsesetup.py 1.4 freeze/winmakemakefile.py 1.12 idle/AutoIndent.py 1.20 idle/Bindings.py 1.16 idle/CallTips.py 1.12 idle/ClassBrowser.py 1.13 idle/ColorDelegator.py 1.13 idle/EditorWindow.py 1.44 idle/FormatParagraph.py 1.10 idle/GrepDialog.py 1.4 idle/IdleHistory.py 1.5 idle/MultiScrolledLists.py 1.3 idle/OldStackViewer.py 1.2 idle/ParenMatch.py 1.6 idle/PyParse.py 1.10 idle/PyShell.py 1.40 idle/ReplaceDialog.py 1.8 idle/SearchDialogBase.py 1.2 idle/SearchEngine.py 1.3 idle/StackViewer.py 1.17 idle/TreeWidget.py 1.8 idle/UndoDelegator.py 1.5 idle/eventparse.py 1.2 modulator/genmodule.py 1.5 modulator/modulator.py 1.10 modulator/varsubst.py 1.4 scripts/byteyears.py 1.8 scripts/checkappend.py 1.3 scripts/classfix.py 1.12 scripts/cvsfiles.py 1.5 scripts/dutree.py 1.11 scripts/fixcid.py 1.10 scripts/fixheader.py 1.5 scripts/ftpmirror.py 1.15 scripts/gencodec.py 1.7 scripts/ifdef.py 1.5 scripts/logmerge.py 1.8 scripts/mailerdaemon.py 1.10 scripts/methfix.py 1.7 scripts/nm2def.py 1.5 scripts/objgraph.py 1.6 scripts/pathfix.py 1.5 scripts/pdeps.py 1.6 scripts/pindent.py 1.11 scripts/rgrep.py 1.2 scripts/sum5.py 1.5 scripts/trace.py 1.9 scripts/treesync.py 1.6 scripts/untabify.py 1.3 scripts/which.py 1.10 scripts/xxci.py 1.15 unicode/makeunicodedata.py 1.12 versioncheck/checkversions.py 1.3 versioncheck/pyversioncheck.py 1.4 webchecker/tktools.py 1.3 webchecker/wcgui.py 1.9 webchecker/webchecker.py 1.28 webchecker/websucker.py 1.10 webchecker/wsgui.py 1.6 Waiting for the public floggings now... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-10 00:57 Message: Logged In: YES user_id=80475 In the interests of saving time and having maximum accuracy, I recommend reverting and then re-applying first patch and then making the changes on my list. Try not to make any other changes. It took half a day to thoroughly review that 6000 line diff. It doesn't make sense for me to re-check everything from scratch. To keep the integrity of the review, make as few changes as possible. Also, it does make sense for you to give a self-review to your final diff (remember, GvR believes in public floggings for those who break working code). Here are a couple of fast checks: -- scan the diff for ''.join and make sure it came from a join (strdata, "") -- grep the final files for >= 0: or < 0: to see if the 'in' operator applies. -- grep the final files for expand( to make sure an expandtabs( was not missed. -- grep the final files for join("\n"), join(" "), or join(' ') to see if there was an error moving the separator to the front A slower self check is to read the diff file line-by-line and mentally recompute each change and compare with the actual change. The diff review will certainly catch unintended changes like the merge conflict or the she- bang change. I know you can't run each script, but do as much as you can by importing each script to see if it gets a compilation error. This won't catch runtime errors but it will catch syntax glitches. One important group of scripts can be run. Try to give IDLE a thorough exercise. Then, when you're feeling brave, commit. Good luck! ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-09 15:54 Message: Logged In: YES user_id=89016 diff2.txt is a new version of the patch (against current CVS). I rechecked the fixheader fix with: for i in xrange(256): c = chr(i) if (ord(c)<=0x80 and c.isalnum()) != (c in string.ascii_letters + string.digits): print i,c There are no differences. > In file: pathfix.py > Replace: if line.find("python") < 0: > With: if "python" in line: This should probably be: if "python" not in line: > In file: texi2html.py > I don't understand the <<<<<< additions Ouch, that was a merge conflict. OK, Raymond could you recheck if the new patch diff2.txt is OK now? These mindless changes really are tricky! ;) Unfortunately running the scripts isn't an option in most cases: Some require Tk, some might expect certain files and some might even transmogrify all the source files. I changed a few tests line[:x] == "xxx...xxx" to line.startswith("xxx...xxx") too. I rechecked the _find = string.find cases in idle/PyParse.py and script/gencodec.py. If I'll get your OK I'll check this in. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-09 00:03 Message: Logged In: YES user_id=80475 Whew! It takes just as long to check as 6000 line diff as it does to create the thing in the first place. The patch is accepted and ready to commit after the following corrections and review notes are addressed. Since several errors were syntactical, they could be caught by running the script. I recommend that all of the scripts be run one time before a final commit. Also, anoter additional check would be useful. Everywhere a function defined the likes of _find=string.find, re-verify that every instance of _find was fixed-up (I cannot check this from the diff file). Corrections and review notes (also attached as a separate file): In file: AutoIndent.py Replace: have = len(chars.expand(tabwidth)) With: have = len(chars.expandtabs(tabwidth)) In file: EditorWindow.py Replace: line.find('python') >= 0 With: 'python' in line In file: FormatParagraph.py Replace: data = "\n".join("\n") With: data = "\n".join(lines) In file: PyParse.py Replace: return len(str[self.stmt_start:i].expandtabs(, With: return len(str[self.stmt_start:i].expandtabs(\ In file: byteyears.py Replace: print file.ljust(file, maxlen), With: print file.ljust(maxlen), In file: fixheader.py Reverify propriety of substitution: if ord(c)<=0x80 and c.isalnum() In file: mailerdaemon.py Replace: if sub.find('warning') >= 0: return 1 With: if 'warning' in sub: return 1 In file: mailerdaemon.py Replace: errors.append(''.join((email.strip()+': '+res.group ('reason')).split())) With: errors.append(' '.join((email.strip()+': '+res.group ('reason')).split())) In file: mailerdaemon.py errors.append(''.join((email.strip()+': '+reason).split())) errors.append(' '.join((email.strip()+': '+reason).split())) In file: objgraph.py Replace: ! /usr/bin/env python With: #! /usr/bin/env python In file: pathfix.py Replace: if line.find("python") < 0: With: if "python" in line: In file: texi2html.py I don't understand the <<<<<< additions In file: treesync.py Replace: split(e.split('/') With: e.split('/') ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-08 00:57 Message: Logged In: YES user_id=6380 Good idea to give it a careful check. I'd suggest to let Walter to check it in since he did the work though. Or you two can race for it. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 00:53 Message: Logged In: YES user_id=80475 Let me know if you want this done. If so, I'll give it a second check (line-by-line) for errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572113&group_id=5470 From noreply@sourceforge.net Thu Sep 12 15:43:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 07:43:34 -0700 Subject: [Patches] [ python-Patches-590119 ] types.BoolType Message-ID: Patches item #590119, was opened at 2002-08-02 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590119&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None >Priority: 4 Submitted By: Markus F.X.J. Oberhumer (mfx) >Assigned to: Guido van Rossum (gvanrossum) Summary: types.BoolType Initial Comment: I know that types is getting deprecated, but for orthogonality we really should have a BoolType. Also, IMHO we should _not_ have a BooleanType (or DictionaryType), but that might break code. Index: types.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/types.py,v retrieving revision 1.29 diff -u -r1.29 types.py --- types.py 14 Jun 2002 20:41:13 -0000 1.29 +++ types.py 2 Aug 2002 13:22:22 -0000 @@ -16,7 +16,7 @@ IntType = int LongType = long FloatType = float -BooleanType = bool +BoolType = BooleanType = bool try: ComplexType = complex except NameError: ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-12 09:43 Message: Logged In: YES user_id=80475 I think the OP doesn't have a bugfix in mind, he is trying to keep a parallel to the line: DictType = DictionaryType = dict DictionaryType had already been in out in Py2.1. Tim added DictType to maintain the naming rule: type(obj).__name__ .title() + "Type" Since we are not already locked into BooleanType, a better solution would be: -BooleanType = bool +BoolType = bool Guido, do you care if I make this change or is there a reason for keeping BooleanType? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 03:59 Message: Logged In: YES user_id=21627 What bug does this fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590119&group_id=5470 From noreply@sourceforge.net Thu Sep 12 16:04:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 08:04:06 -0700 Subject: [Patches] [ python-Patches-590119 ] types.BoolType Message-ID: Patches item #590119, was opened at 2002-08-02 09:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590119&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 4 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Guido van Rossum (gvanrossum) Summary: types.BoolType Initial Comment: I know that types is getting deprecated, but for orthogonality we really should have a BoolType. Also, IMHO we should _not_ have a BooleanType (or DictionaryType), but that might break code. Index: types.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/types.py,v retrieving revision 1.29 diff -u -r1.29 types.py --- types.py 14 Jun 2002 20:41:13 -0000 1.29 +++ types.py 2 Aug 2002 13:22:22 -0000 @@ -16,7 +16,7 @@ IntType = int LongType = long FloatType = float -BooleanType = bool +BoolType = BooleanType = bool try: ComplexType = complex except NameError: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-12 11:04 Message: Logged In: YES user_id=6380 I see no bug here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-12 11:02 Message: Logged In: YES user_id=21627 The requirement that getattr(types, X).__name__.title()+"Type" == X for all X in dir(types) if endswith("Type") is reasonable; the following types currently break that: BooleanType (bool) BuiltinFunctionType (builtin_function_or_method) BuiltinMethodType (builtin_function_or_method) ClassType (classobj) DictProxyType (dictproxy) DictionaryType (dict) LambdaType (function) MethodType (instancemethod) NoneType (NoneType) StringType (str) UnboundMethodType (instancemethod) XRangeType (xrange) If it is desirable tha the predicate above holds, then I'd encourage the following fix: - produce a test case that tests the predicate - provide a patch that makes the test pass. It certainly needs to be taken into account that some names are synonyms of others, so they can be removed, so the test should deal with that (by accepting cases where the canonical type name is in types); cases that only show case problems (xrange, dictproxy) probably can also pass as-is. If that property is not desirable, I again ask what the problem is. If BoolType is added (for whatever reason), I agree with Raymond that removing BooleanType is sensible. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-12 10:43 Message: Logged In: YES user_id=80475 I think the OP doesn't have a bugfix in mind, he is trying to keep a parallel to the line: DictType = DictionaryType = dict DictionaryType had already been in out in Py2.1. Tim added DictType to maintain the naming rule: type(obj).__name__ .title() + "Type" Since we are not already locked into BooleanType, a better solution would be: -BooleanType = bool +BoolType = bool Guido, do you care if I make this change or is there a reason for keeping BooleanType? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 04:59 Message: Logged In: YES user_id=21627 What bug does this fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590119&group_id=5470 From noreply@sourceforge.net Thu Sep 12 16:02:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 08:02:09 -0700 Subject: [Patches] [ python-Patches-590119 ] types.BoolType Message-ID: Patches item #590119, was opened at 2002-08-02 15:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590119&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Markus F.X.J. Oberhumer (mfx) Assigned to: Guido van Rossum (gvanrossum) Summary: types.BoolType Initial Comment: I know that types is getting deprecated, but for orthogonality we really should have a BoolType. Also, IMHO we should _not_ have a BooleanType (or DictionaryType), but that might break code. Index: types.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/types.py,v retrieving revision 1.29 diff -u -r1.29 types.py --- types.py 14 Jun 2002 20:41:13 -0000 1.29 +++ types.py 2 Aug 2002 13:22:22 -0000 @@ -16,7 +16,7 @@ IntType = int LongType = long FloatType = float -BooleanType = bool +BoolType = BooleanType = bool try: ComplexType = complex except NameError: ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-12 17:02 Message: Logged In: YES user_id=21627 The requirement that getattr(types, X).__name__.title()+"Type" == X for all X in dir(types) if endswith("Type") is reasonable; the following types currently break that: BooleanType (bool) BuiltinFunctionType (builtin_function_or_method) BuiltinMethodType (builtin_function_or_method) ClassType (classobj) DictProxyType (dictproxy) DictionaryType (dict) LambdaType (function) MethodType (instancemethod) NoneType (NoneType) StringType (str) UnboundMethodType (instancemethod) XRangeType (xrange) If it is desirable tha the predicate above holds, then I'd encourage the following fix: - produce a test case that tests the predicate - provide a patch that makes the test pass. It certainly needs to be taken into account that some names are synonyms of others, so they can be removed, so the test should deal with that (by accepting cases where the canonical type name is in types); cases that only show case problems (xrange, dictproxy) probably can also pass as-is. If that property is not desirable, I again ask what the problem is. If BoolType is added (for whatever reason), I agree with Raymond that removing BooleanType is sensible. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-12 16:43 Message: Logged In: YES user_id=80475 I think the OP doesn't have a bugfix in mind, he is trying to keep a parallel to the line: DictType = DictionaryType = dict DictionaryType had already been in out in Py2.1. Tim added DictType to maintain the naming rule: type(obj).__name__ .title() + "Type" Since we are not already locked into BooleanType, a better solution would be: -BooleanType = bool +BoolType = bool Guido, do you care if I make this change or is there a reason for keeping BooleanType? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 10:59 Message: Logged In: YES user_id=21627 What bug does this fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590119&group_id=5470 From noreply@sourceforge.net Thu Sep 12 19:04:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 11:04:56 -0700 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Riehl (jriehl) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- >Comment By: Jon Riehl (jriehl) Date: 2002-09-12 13:04 Message: Logged In: YES user_id=22448 Guido, as per my private message, I'll attempt to submit another patch by the end of the month, pending resumption of "work" on the 23rd. Commitment of the memory allocation patch is fine, and any future patches would be against the updated pgen code (I don't have commit permissions, so someone else will have to do this possibly.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 07:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply@sourceforge.net Thu Sep 12 19:39:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 11:39:07 -0700 Subject: [Patches] [ python-Patches-608182 ] Enhanced file constructor Message-ID: Patches item #608182, was opened at 2002-09-11 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Taral (taral) Assigned to: Nobody/Anonymous (nobody) Summary: Enhanced file constructor Initial Comment: This patch allows the file constructor to take a file descriptor, allowing for much easier extension of its functionality. ---------------------------------------------------------------------- >Comment By: Taral (taral) Date: 2002-09-12 13:39 Message: Logged In: YES user_id=25129 class some_class(file): def __init__(self, arg): fd = do_some_os_stuff_with_forks_and_pipes_or_sockets return file.__init__(self, fd, 'r') def close(self): do_some_cleanup_stuff return file.close(self) and so on. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-12 01:59 Message: Logged In: YES user_id=21627 What's wrong with os.fdopen? Why is f = file(10, "r") much easier than f = os.fdopen(10, "r") ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-12 00:31 Message: Logged In: YES user_id=25129 Okay, fixed it all. Passes 'make test' on linux/x86 with default configure (does not test dbm/gdbm/mpz/bsddb). (btw, old versions can be deleted) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-11 23:10 Message: Logged In: YES user_id=33168 fp's and fd's are not interchangable. The variable should be called fd, since it's an int. fill_file_fields() 2nd arg is a FILE*, not an int. So you would need to do file = fdopen(fd, mode), then pass file as the 2nd arg. In order for this patch to be accepted, a test would also need to be added (see Lib/test/test_file.py) and doc should be updated (see Doc/lib/libfuncs.tex). ---------------------------------------------------------------------- Comment By: Taral (taral) Date: 2002-09-11 22:47 Message: Logged In: YES user_id=25129 Bah, forgot the variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608182&group_id=5470 From noreply@sourceforge.net Thu Sep 12 21:47:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 13:47:28 -0700 Subject: [Patches] [ python-Patches-608595 ] Problems in IDLE Browsers & Viewers Message-ID: Patches item #608595, was opened at 2002-09-12 16:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608595&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: Problems in IDLE Browsers & Viewers Initial Comment: ClassBrowser and PathBrowser mains don't work. PyShell is imported as a module, then an flist attribute is referenced which is not in the module. Not sure if PyShell the class should be used and if so, how it should work. Also mainloop() is not defined. Should it be some_tk_object.mainloop()? ~ lines: ClassBrowser.py:215 & PathBrowser.py:87 Another (cut-n-paste?) problem is in OldStackViewer & StackViewer. A function was apparently refactored from a method, since self is referenced. Should the if statements be removed? ~ lines: OldStackViewer.py:179 & StackViewer.py:111 In SearchDialogBase.py:126, the local variable f is not used, should it be removed? Finally, should these bug reports go to IDLEfork? What about bug fixes? Should changes be made in both places? (I'm not a developer on IDLEfork.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608595&group_id=5470 From noreply@sourceforge.net Thu Sep 12 22:17:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 14:17:28 -0700 Subject: [Patches] [ python-Patches-608595 ] Problems in IDLE Browsers & Viewers Message-ID: Patches item #608595, was opened at 2002-09-12 16:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608595&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: Problems in IDLE Browsers & Viewers Initial Comment: ClassBrowser and PathBrowser mains don't work. PyShell is imported as a module, then an flist attribute is referenced which is not in the module. Not sure if PyShell the class should be used and if so, how it should work. Also mainloop() is not defined. Should it be some_tk_object.mainloop()? ~ lines: ClassBrowser.py:215 & PathBrowser.py:87 Another (cut-n-paste?) problem is in OldStackViewer & StackViewer. A function was apparently refactored from a method, since self is referenced. Should the if statements be removed? ~ lines: OldStackViewer.py:179 & StackViewer.py:111 In SearchDialogBase.py:126, the local variable f is not used, should it be removed? Finally, should these bug reports go to IDLEfork? What about bug fixes? Should changes be made in both places? (I'm not a developer on IDLEfork.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-12 17:17 Message: Logged In: YES user_id=6380 Those mains were only used for testing. I'd like to keep them around, I'll fix them when I need them. Or you can fix them, I don't care. I don't know what happened to get_stack(). It can't work?! What does idlefork do? Sure, remove that variable f. Do you want to be a developer on idlefork? They can use some help! I hope that Python 2.3 can incorporate idlefork's codebase, so we shouldn't be backing on Tools/idle too much... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608595&group_id=5470 From noreply@sourceforge.net Thu Sep 12 22:51:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 14:51:29 -0700 Subject: [Patches] [ python-Patches-606067 ] Tweaks to calls to AH/Help Message-ID: Patches item #606067, was opened at 2002-09-07 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606067&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: Tweaks to calls to AH/Help Initial Comment: An import was missing from FrameWork.py; and choosing the "Help | Python Documentation" menu item in the IDE was causing an error. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-09-12 23:51 Message: Logged In: YES user_id=45365 Tony, for some reason I didn't get an email notification that this patch was waiting for me... But anyway: simplar patches have been checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606067&group_id=5470 From noreply@sourceforge.net Thu Sep 12 22:52:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 14:52:33 -0700 Subject: [Patches] [ python-Patches-606067 ] Tweaks to calls to AH/Help Message-ID: Patches item #606067, was opened at 2002-09-07 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606067&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: Tweaks to calls to AH/Help Initial Comment: An import was missing from FrameWork.py; and choosing the "Help | Python Documentation" menu item in the IDE was causing an error. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-09-12 23:51 Message: Logged In: YES user_id=45365 Tony, for some reason I didn't get an email notification that this patch was waiting for me... But anyway: simplar patches have been checked in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606067&group_id=5470 From noreply@sourceforge.net Thu Sep 12 23:04:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 15:04:57 -0700 Subject: [Patches] [ python-Patches-606134 ] install_IDLE target in Mac/OSX/Makefile Message-ID: Patches item #606134, was opened at 2002-09-07 23:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606134&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: install_IDLE target in Mac/OSX/Makefile Initial Comment: With this patch, IDLE is installed if _tkinter is found, just like the IDE. Also, /Library/Frameworks, ~/Library/Frameworks and /Network/Library/Frameworks are added to the path. Includes the diffs from patch 606067. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-09-13 00:04 Message: Logged In: YES user_id=45365 Tony, I'm applying the patches except for the one that adds the /Library/Python and friends to sys.path. I want to think about the right location for these a bit longer. On the one hand I think that /Library/Application Support/Python may be better (but you might argue that these aren't specifically bound to the Python *application* but to the framework, which may also be used by other things). On the second hand I may want to add a python version number in there somewhere. On the third hand I may want to add a "Lib" bit in there as well, as I also want to use that base folder as a place to keep IDE scripts, Python Install Manager packages, etc. And on the fourth hand:-) this isn't very useful until distutils learns about it. Actually, it may be more confusing to unsuspecting users... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606134&group_id=5470 From noreply@sourceforge.net Thu Sep 12 23:14:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 15:14:48 -0700 Subject: [Patches] [ python-Patches-608595 ] Problems in IDLE Browsers & Viewers Message-ID: Patches item #608595, was opened at 2002-09-12 16:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608595&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: Problems in IDLE Browsers & Viewers Initial Comment: ClassBrowser and PathBrowser mains don't work. PyShell is imported as a module, then an flist attribute is referenced which is not in the module. Not sure if PyShell the class should be used and if so, how it should work. Also mainloop() is not defined. Should it be some_tk_object.mainloop()? ~ lines: ClassBrowser.py:215 & PathBrowser.py:87 Another (cut-n-paste?) problem is in OldStackViewer & StackViewer. A function was apparently refactored from a method, since self is referenced. Should the if statements be removed? ~ lines: OldStackViewer.py:179 & StackViewer.py:111 In SearchDialogBase.py:126, the local variable f is not used, should it be removed? Finally, should these bug reports go to IDLEfork? What about bug fixes? Should changes be made in both places? (I'm not a developer on IDLEfork.) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-12 18:14 Message: Logged In: YES user_id=33168 You can make me an idlefork developer. Probably won't do much on it. But if the changes are supposed to flow from idlefork into python, it will be easier if I change idlefork. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-12 17:17 Message: Logged In: YES user_id=6380 Those mains were only used for testing. I'd like to keep them around, I'll fix them when I need them. Or you can fix them, I don't care. I don't know what happened to get_stack(). It can't work?! What does idlefork do? Sure, remove that variable f. Do you want to be a developer on idlefork? They can use some help! I hope that Python 2.3 can incorporate idlefork's codebase, so we shouldn't be backing on Tools/idle too much... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608595&group_id=5470 From noreply@sourceforge.net Thu Sep 12 23:20:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 15:20:15 -0700 Subject: [Patches] [ python-Patches-606134 ] install_IDLE target in Mac/OSX/Makefile Message-ID: Patches item #606134, was opened at 2002-09-07 23:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606134&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Jack Jansen (jackjansen) Summary: install_IDLE target in Mac/OSX/Makefile Initial Comment: With this patch, IDLE is installed if _tkinter is found, just like the IDE. Also, /Library/Frameworks, ~/Library/Frameworks and /Network/Library/Frameworks are added to the path. Includes the diffs from patch 606067. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-09-13 00:04 Message: Logged In: YES user_id=45365 Tony, I'm applying the patches except for the one that adds the /Library/Python and friends to sys.path. I want to think about the right location for these a bit longer. On the one hand I think that /Library/Application Support/Python may be better (but you might argue that these aren't specifically bound to the Python *application* but to the framework, which may also be used by other things). On the second hand I may want to add a python version number in there somewhere. On the third hand I may want to add a "Lib" bit in there as well, as I also want to use that base folder as a place to keep IDE scripts, Python Install Manager packages, etc. And on the fourth hand:-) this isn't very useful until distutils learns about it. Actually, it may be more confusing to unsuspecting users... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606134&group_id=5470 From noreply@sourceforge.net Fri Sep 13 05:35:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Sep 2002 21:35:34 -0700 Subject: [Patches] [ python-Patches-599331 ] PEP 269 Implementation Message-ID: Patches item #599331, was opened at 2002-08-23 13:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jon Riehl (jriehl) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 269 Implementation Initial Comment: The following are files for the implementation of PEP 269. The primary changes to the core involve moving required pgen modules from the pgen only module list to the Python library module list in Makefile.pre.in. Some of the modules required better memory allocation and management and the corresponding deallocators are in the Python extension module (maybe these should be moved into the pgen modules in Parser). Initially included are two implementations. The first is a basic implementation that follows the PEP API more or less. The second (currently unfinished) implementation provides a more object oriented interface to the extension module. Please note there are some commented out modifications to setup.py as I was unable to build the extension module(s) automagically. For some reason the linker I was using (on a BSD box) complained that it couldn't find the _Py_pgen symbol, even though I verified its existence in the new Python library. Maybe it is checking against an older Python library on the system? Things to be done (as of initial submission) include resolving on a single interface, documenting the one true interface, and finishing any unimplemented routines (such as are found in the OO implementation). In the final integration, a pgenmodule.c file should be added to the Modules directory in the main distribution. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-13 00:35 Message: Logged In: YES user_id=6380 Cool. Maybe I'll get to it, maybe not. :-( ---------------------------------------------------------------------- Comment By: Jon Riehl (jriehl) Date: 2002-09-12 14:04 Message: Logged In: YES user_id=22448 Guido, as per my private message, I'll attempt to submit another patch by the end of the month, pending resumption of "work" on the 23rd. Commitment of the memory allocation patch is fine, and any future patches would be against the updated pgen code (I don't have commit permissions, so someone else will have to do this possibly.) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-09 08:09 Message: Logged In: YES user_id=6380 I looked a bit, and it's very raw - the author admits that. Jon, are you still working on this? Do you have a more polished version? Maybe we can separate out the memory allocation patches and commit these already? They don't break anything. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 15:44 Message: Logged In: YES user_id=6380 I guess I'm going to hve to look at this to pronounce... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=599331&group_id=5470 From noreply@sourceforge.net Fri Sep 13 15:41:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Sep 2002 07:41:45 -0700 Subject: [Patches] [ python-Patches-602108 ] improper use of strncpy in getpath Message-ID: Patches item #602108, was opened at 2002-08-29 17:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: improper use of strncpy in getpath Initial Comment: Many uses of strncpy() in Modules/getpath and PC/getpathp do not copy the terminating null character onto the string. This patch makes sure the strings are null terminated after strncpy(). Should this be backported? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 10:41 Message: Logged In: YES user_id=33168 Checked in as Modules/getpath.c 1.42 and 1.40.6.2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-06 01:07 Message: Logged In: YES user_id=6380 Good catch. Can you check a fix along those lines in for just that variable? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-05 16:32 Message: Logged In: YES user_id=33168 I spoke too soon. Not all the variables are global static. In Modules/getpath.c::calculate_path() (line 363), argv0_path is a local, non-static variable. In the original patch, this was set to the null char in 4 places. I think it would be easier to do: argv0_path[MAXPATHLEN] = '\0'; once, before argv0_path is used rather than after each strncpy(). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 17:51 Message: Logged In: YES user_id=33168 You are correct. There should always be a null byte since all the variables are static. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:55 Message: Logged In: YES user_id=6380 Since the variables affected are all globals, there is already a null byte in the final position. So there's no need to write one explicitly. I therefore reject this patch. I'm leaving it open in case I'm misunderstanding something. If you agree, please close it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=602108&group_id=5470 From noreply@sourceforge.net Fri Sep 13 16:19:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Sep 2002 08:19:44 -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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Guido van Rossum (gvanrossum) 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. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 11:19 Message: Logged In: YES user_id=33168 I've updated the patch. It's more of the same types of changes: * intobject stuff is the same, ie allocate small ints on startup - the only change is to bump NSMALLNEGINTS from 1 to 5 * frameobject: intern "__builtins__" on startup not in Frame_New * DECREF instead of XDECREF in frame for code, builtins, and globals (note, INCREF was used for these, not XINCREF) I've been running with these for months, so I'm pretty sure they are safe. Unless you changed your mind about the int changes, these changes should be ok too. Just giving you one last chance to change your mind. :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-08 20:28 Message: Logged In: YES user_id=33168 No, I've still got some outstanding modifications. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 00:57 Message: Logged In: YES user_id=80475 Are these all done now? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-03 11:59 Message: Logged In: YES user_id=33168 Checked in the memset()s in: {list,tuple}object.c and _sre.c. object.c 2.178 Still have to do int and frame. I've cleaned up int so that if there is an init failure, a fatal error is raised similar to other initializations. I will get around to checking that in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 17:43 Message: Logged In: YES user_id=6380 I like all of these, even PyInt_Init(). Go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-31 18:11 Message: Logged In: YES user_id=80475 Wow, you plowed through a lot of code! Two sets of optimizations look worthwhile, the memsets() and the XINCREFs to INCREFS. Probably the fastlocals substitutions should be done also, but more for beauty and clarity than speed. I checked those three categories of changes on my machine. They compile fine, pass the standard regression tests and checkout okay on my personal, realcode testfarm. I don't think the PyInt_Init() addition buys us anything. The register and macro tweaks may cost more in review time and potential errors than they could ever save in cumulative computer time. Recommend you get these in before someone changes the codebase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&group_id=5470 From noreply@sourceforge.net Fri Sep 13 18:47:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Sep 2002 10:47:47 -0700 Subject: [Patches] [ python-Patches-608999 ] configure on Irix (sockets, posix) Message-ID: Patches item #608999, was opened at 2002-09-13 20:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: configure on Irix (sockets, posix) Initial Comment: The configure script checks for various library calls just by calling them prefixed with (void), thus verifying they exist but not checking if their type is correctly declared. On Irix and MIPSPro cc, various _r functions (ctermid_r, gethostbyaddr_r etc) need extra directives in order to be declared. This is what the patch does. Note: in the patch, the check against the CC var is "cc*)" and not "cc)". This is deliberate, because if there is a SGI_ABI env var set to something (eg. -64 for 64bit executable), the configure script changes the CC var to include the SGI_ABI contents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 From noreply@sourceforge.net Sun Sep 15 23:34:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Sep 2002 15:34:14 -0700 Subject: [Patches] [ python-Patches-609700 ] always build with same $(CC) on Linux Message-ID: Patches item #609700, was opened at 2002-09-15 22:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: always build with same $(CC) on Linux Initial Comment: When configuring python with --with-gcc and/or --with- cxx, the shared modules are not built with the configured compilers and not linked with the configured compilers. The patch attached uses the configured compiler when building the shared modules. Python fails to build, when configured --with-gcc=gcc-3.2 on ia64-linux. Distilled code (thanks to Martin v. Loewis): #include int main(int argc, char*argv[]) { printf("%d\n", 16/argc); } Translate with: gcc-3.2 -c div.c gcc-2.95 -o div div.o call: ./div onearg prints 7, not 8. Should be fixed in 2.1 and 2.2 as well and maybe for other architectures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 From noreply@sourceforge.net Sun Sep 15 23:40:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Sep 2002 15:40:52 -0700 Subject: [Patches] [ python-Patches-609700 ] always build with same $(CC) on Linux Message-ID: Patches item #609700, was opened at 2002-09-15 22:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: always build with same $(CC) on Linux Initial Comment: When configuring python with --with-gcc and/or --with- cxx, the shared modules are not built with the configured compilers and not linked with the configured compilers. The patch attached uses the configured compiler when building the shared modules. Python fails to build, when configured --with-gcc=gcc-3.2 on ia64-linux. Distilled code (thanks to Martin v. Loewis): #include int main(int argc, char*argv[]) { printf("%d\n", 16/argc); } Translate with: gcc-3.2 -c div.c gcc-2.95 -o div div.o call: ./div onearg prints 7, not 8. Should be fixed in 2.1 and 2.2 as well and maybe for other architectures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 From noreply@sourceforge.net Mon Sep 16 18:19:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Sep 2002 10:19:57 -0700 Subject: [Patches] [ python-Patches-554807 ] Add _winreg support for Cygwin Message-ID: Patches item #554807, was opened at 2002-05-11 05:01 You can respond by visiting: https://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: Nobody/Anonymous (nobody) Date: 2002-09-16 10:19 Message: Logged In: NO I'm prepared to try to help if there's still energy here, and there are specific things to do. However I agree that _if_ the cygwin /proc/registry story is going to become writeable, then there's not much point. ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-07-30 07:04 Message: Logged In: YES user_id=329402 I plan to get back to this eventually, although held off for three reasons: - Cygwin is incorporating a registry file system that may be a better way to implement this - saw some posts about possible Unicode changes - Real Life (job priorities, vacation) I probably won't get back to this until the middle of August. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 03:02 Message: Logged In: YES user_id=21627 Is any kind of tweaking forthcoming? ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-15 06: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 05: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 05: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 15: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 From noreply@sourceforge.net Mon Sep 16 18:52:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Sep 2002 10:52:08 -0700 Subject: [Patches] [ python-Patches-609700 ] always build with same $(CC) on Linux Message-ID: Patches item #609700, was opened at 2002-09-16 00:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: always build with same $(CC) on Linux Initial Comment: When configuring python with --with-gcc and/or --with- cxx, the shared modules are not built with the configured compilers and not linked with the configured compilers. The patch attached uses the configured compiler when building the shared modules. Python fails to build, when configured --with-gcc=gcc-3.2 on ia64-linux. Distilled code (thanks to Martin v. Loewis): #include int main(int argc, char*argv[]) { printf("%d\n", 16/argc); } Translate with: gcc-3.2 -c div.c gcc-2.95 -o div div.o call: ./div onearg prints 7, not 8. Should be fixed in 2.1 and 2.2 as well and maybe for other architectures. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 19:52 Message: Logged In: YES user_id=21627 Your patch was incorrect: it breaks if CC is not set in the environment. I committed a modified patch as configure.in 1.345 and configure 1.334. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=609700&group_id=5470 From noreply@sourceforge.net Mon Sep 16 18:54:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Sep 2002 10:54:56 -0700 Subject: [Patches] [ python-Patches-608999 ] configure on Irix (sockets, posix) Message-ID: Patches item #608999, was opened at 2002-09-13 19:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: configure on Irix (sockets, posix) Initial Comment: The configure script checks for various library calls just by calling them prefixed with (void), thus verifying they exist but not checking if their type is correctly declared. On Irix and MIPSPro cc, various _r functions (ctermid_r, gethostbyaddr_r etc) need extra directives in order to be declared. This is what the patch does. Note: in the patch, the check against the CC var is "cc*)" and not "cc)". This is deliberate, because if there is a SGI_ABI env var set to something (eg. -64 for 64bit executable), the configure script changes the CC var to include the SGI_ABI contents. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 19:54 Message: Logged In: YES user_id=21627 Can you please add a comment (in the patch) which of these defines is necessary to activate what specific feature? Five years from now, the need for these defines may be gone, but nobody will dare to remove the defines since nobod knows why they are there in the first place. Also, what versions of Irix has this patch been tested on? Which additional versions is it supposed to work on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 From noreply@sourceforge.net Mon Sep 16 18:57:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Sep 2002 10:57:09 -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: https://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-09-16 19:57 Message: Logged In: YES user_id=21627 If a convincing patch comes along, I'd happily apply it. Supporting _winreg is still reasonable even if /proc/registry exists, for compatibility with other Win32 ports. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-16 19:19 Message: Logged In: NO I'm prepared to try to help if there's still energy here, and there are specific things to do. However I agree that _if_ the cygwin /proc/registry story is going to become writeable, then there's not much point. ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-07-30 16:04 Message: Logged In: YES user_id=329402 I plan to get back to this eventually, although held off for three reasons: - Cygwin is incorporating a registry file system that may be a better way to implement this - saw some posts about possible Unicode changes - Real Life (job priorities, vacation) I probably won't get back to this until the middle of August. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 12:02 Message: Logged In: YES user_id=21627 Is any kind of tweaking forthcoming? ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-15 15: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 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 From noreply@sourceforge.net Tue Sep 17 11:22:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 03:22:20 -0700 Subject: [Patches] [ python-Patches-608999 ] configure on Irix (sockets, posix) Message-ID: Patches item #608999, was opened at 2002-09-13 20:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: configure on Irix (sockets, posix) Initial Comment: The configure script checks for various library calls just by calling them prefixed with (void), thus verifying they exist but not checking if their type is correctly declared. On Irix and MIPSPro cc, various _r functions (ctermid_r, gethostbyaddr_r etc) need extra directives in order to be declared. This is what the patch does. Note: in the patch, the check against the CC var is "cc*)" and not "cc)". This is deliberate, because if there is a SGI_ABI env var set to something (eg. -64 for 64bit executable), the configure script changes the CC var to include the SGI_ABI contents. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2002-09-17 13:22 Message: Logged In: YES user_id=539787 These defines apply for the compiler MIPSPro 7.x. Since it is cumbersome to make that clear in the configure script, I chose to make patches directly to the three modules that failed to compile, where it's easiest to check for OS and compiler version. The three modules are _hotshot, posixmodule and socketmodule. The patch has been tested on Irix 6.5 (I have no access to older versions) and on three separate machines (Indy, Octane and an Origin2K), and that is why I was a little slow in replying. Please delete the previous patch (if you have permission to). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 20:54 Message: Logged In: YES user_id=21627 Can you please add a comment (in the patch) which of these defines is necessary to activate what specific feature? Five years from now, the need for these defines may be gone, but nobody will dare to remove the defines since nobod knows why they are there in the first place. Also, what versions of Irix has this patch been tested on? Which additional versions is it supposed to work on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 From noreply@sourceforge.net Tue Sep 17 13:56:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 05:56:03 -0700 Subject: [Patches] [ python-Patches-610522 ] IDLE TODO:left,right when selected text Message-ID: Patches item #610522, was opened at 2002-09-17 15:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=610522&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE TODO:left,right when selected text Initial Comment: This patch makes sure that when text is selected in an IDLE editor window, pressing left or right cursor key moves the caret to the corresponding end of the selection. The patch works correctly in Red Hat Linux 6.2 (Python 2.3a0, Tcl/Tk 8.0), Mandrake Linux 8.2 (Python 2.3a0, Tcl/Tk 8.3), Win2K (Python 2.2.1, Tcl/Tk 8.3), SGI Irix 6.5.17 (Python 2.3a0, Tcl/Tk 8.0). Please read additional info supplied as the first comment to this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=610522&group_id=5470 From noreply@sourceforge.net Tue Sep 17 15:19:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 07:19:22 -0700 Subject: [Patches] [ python-Patches-610522 ] IDLE TODO:left,right when selected text Message-ID: Patches item #610522, was opened at 2002-09-17 15:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=610522&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE TODO:left,right when selected text Initial Comment: This patch makes sure that when text is selected in an IDLE editor window, pressing left or right cursor key moves the caret to the corresponding end of the selection. The patch works correctly in Red Hat Linux 6.2 (Python 2.3a0, Tcl/Tk 8.0), Mandrake Linux 8.2 (Python 2.3a0, Tcl/Tk 8.3), Win2K (Python 2.2.1, Tcl/Tk 8.3), SGI Irix 6.5.17 (Python 2.3a0, Tcl/Tk 8.0). Please read additional info supplied as the first comment to this patch. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2002-09-17 17:19 Message: Logged In: YES user_id=539787 (I hope this does not show as a duplicate, it seems my earlier comment did not get posted). I do not like two things in my patch. 1. Where I did the keyboard bindings (EditorWindow.set_status_bar where there were two other keyboard bindings). Anyway, I put the event procedure right after set_status_bar so that it can be refactored easily by somebody else. 2. The mask to check whether Shift or Control is pressed with Left or Right is hardcoded. (5 because Shift turns on bit 0, Control turns on bit 2). Although I verified that this applies to all the platforms referenced in the patch description, it still isn't the Right Thing. Any hints as to find documentation for platform-independent checking of the event.state attribute? I won't dare to check for Alt modifiers, since the bits turned on vary heavily depending on the window server getting the keypresses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=610522&group_id=5470 From noreply@sourceforge.net Tue Sep 17 15:19:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 07:19:45 -0700 Subject: [Patches] [ python-Patches-610522 ] IDLE TODO:left,right when selected text Message-ID: Patches item #610522, was opened at 2002-09-17 15:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=610522&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE TODO:left,right when selected text Initial Comment: This patch makes sure that when text is selected in an IDLE editor window, pressing left or right cursor key moves the caret to the corresponding end of the selection. The patch works correctly in Red Hat Linux 6.2 (Python 2.3a0, Tcl/Tk 8.0), Mandrake Linux 8.2 (Python 2.3a0, Tcl/Tk 8.3), Win2K (Python 2.2.1, Tcl/Tk 8.3), SGI Irix 6.5.17 (Python 2.3a0, Tcl/Tk 8.0). Please read additional info supplied as the first comment to this patch. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2002-09-17 17:19 Message: Logged In: YES user_id=539787 (I hope this does not show as a duplicate, it seems my earlier comment did not get posted). I do not like two things in my patch. 1. Where I did the keyboard bindings (EditorWindow.set_status_bar where there were two other keyboard bindings). Anyway, I put the event procedure right after set_status_bar so that it can be refactored easily by somebody else. 2. The mask to check whether Shift or Control is pressed with Left or Right is hardcoded. (5 because Shift turns on bit 0, Control turns on bit 2). Although I verified that this applies to all the platforms referenced in the patch description, it still isn't the Right Thing. Any hints as to find documentation for platform-independent checking of the event.state attribute? I won't dare to check for Alt modifiers, since the bits turned on vary heavily depending on the window server getting the keypresses. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-17 17:19 Message: Logged In: YES user_id=539787 (I hope this does not show as a duplicate, it seems my earlier comment did not get posted). I do not like two things in my patch. 1. Where I did the keyboard bindings (EditorWindow.set_status_bar where there were two other keyboard bindings). Anyway, I put the event procedure right after set_status_bar so that it can be refactored easily by somebody else. 2. The mask to check whether Shift or Control is pressed with Left or Right is hardcoded. (5 because Shift turns on bit 0, Control turns on bit 2). Although I verified that this applies to all the platforms referenced in the patch description, it still isn't the Right Thing. Any hints as to find documentation for platform-independent checking of the event.state attribute? I won't dare to check for Alt modifiers, since the bits turned on vary heavily depending on the window server getting the keypresses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=610522&group_id=5470 From noreply@sourceforge.net Tue Sep 17 16:14:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 08:14:11 -0700 Subject: [Patches] [ python-Patches-608999 ] configure on Irix (sockets, posix) Message-ID: Patches item #608999, was opened at 2002-09-13 19:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: configure on Irix (sockets, posix) Initial Comment: The configure script checks for various library calls just by calling them prefixed with (void), thus verifying they exist but not checking if their type is correctly declared. On Irix and MIPSPro cc, various _r functions (ctermid_r, gethostbyaddr_r etc) need extra directives in order to be declared. This is what the patch does. Note: in the patch, the check against the CC var is "cc*)" and not "cc)". This is deliberate, because if there is a SGI_ABI env var set to something (eg. -64 for 64bit executable), the configure script changes the CC var to include the SGI_ABI contents. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 17:14 Message: Logged In: YES user_id=21627 The patch looks good, but I still must request a summary comment above each of the changes that indicates what compilation or runtime changes are fixed. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-17 12:22 Message: Logged In: YES user_id=539787 These defines apply for the compiler MIPSPro 7.x. Since it is cumbersome to make that clear in the configure script, I chose to make patches directly to the three modules that failed to compile, where it's easiest to check for OS and compiler version. The three modules are _hotshot, posixmodule and socketmodule. The patch has been tested on Irix 6.5 (I have no access to older versions) and on three separate machines (Indy, Octane and an Origin2K), and that is why I was a little slow in replying. Please delete the previous patch (if you have permission to). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 19:54 Message: Logged In: YES user_id=21627 Can you please add a comment (in the patch) which of these defines is necessary to activate what specific feature? Five years from now, the need for these defines may be gone, but nobody will dare to remove the defines since nobod knows why they are there in the first place. Also, what versions of Irix has this patch been tested on? Which additional versions is it supposed to work on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 From noreply@sourceforge.net Tue Sep 17 16:28:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 08:28:51 -0700 Subject: [Patches] [ python-Patches-610522 ] IDLE TODO:left,right when selected text Message-ID: Patches item #610522, was opened at 2002-09-17 14:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=610522&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE TODO:left,right when selected text Initial Comment: This patch makes sure that when text is selected in an IDLE editor window, pressing left or right cursor key moves the caret to the corresponding end of the selection. The patch works correctly in Red Hat Linux 6.2 (Python 2.3a0, Tcl/Tk 8.0), Mandrake Linux 8.2 (Python 2.3a0, Tcl/Tk 8.3), Win2K (Python 2.2.1, Tcl/Tk 8.3), SGI Irix 6.5.17 (Python 2.3a0, Tcl/Tk 8.0). Please read additional info supplied as the first comment to this patch. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 17:28 Message: Logged In: YES user_id=21627 There has been posted a memorandum on IDLE patches recently; all change *must* be contributed to the idlefork project here on SF. Rejecting this patch. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-17 16:19 Message: Logged In: YES user_id=539787 (I hope this does not show as a duplicate, it seems my earlier comment did not get posted). I do not like two things in my patch. 1. Where I did the keyboard bindings (EditorWindow.set_status_bar where there were two other keyboard bindings). Anyway, I put the event procedure right after set_status_bar so that it can be refactored easily by somebody else. 2. The mask to check whether Shift or Control is pressed with Left or Right is hardcoded. (5 because Shift turns on bit 0, Control turns on bit 2). Although I verified that this applies to all the platforms referenced in the patch description, it still isn't the Right Thing. Any hints as to find documentation for platform-independent checking of the event.state attribute? I won't dare to check for Alt modifiers, since the bits turned on vary heavily depending on the window server getting the keypresses. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-17 16:19 Message: Logged In: YES user_id=539787 (I hope this does not show as a duplicate, it seems my earlier comment did not get posted). I do not like two things in my patch. 1. Where I did the keyboard bindings (EditorWindow.set_status_bar where there were two other keyboard bindings). Anyway, I put the event procedure right after set_status_bar so that it can be refactored easily by somebody else. 2. The mask to check whether Shift or Control is pressed with Left or Right is hardcoded. (5 because Shift turns on bit 0, Control turns on bit 2). Although I verified that this applies to all the platforms referenced in the patch description, it still isn't the Right Thing. Any hints as to find documentation for platform-independent checking of the event.state attribute? I won't dare to check for Alt modifiers, since the bits turned on vary heavily depending on the window server getting the keypresses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=610522&group_id=5470 From noreply@sourceforge.net Tue Sep 17 16:29:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 08:29:27 -0700 Subject: [Patches] [ python-Patches-525109 ] Extension to Calltips / Show attributes Message-ID: Patches item #525109, was opened at 2002-03-03 12:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=525109&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Martin Liebmann (mliebmann) Assigned to: Nobody/Anonymous (nobody) Summary: Extension to Calltips / Show attributes Initial Comment: The attached files (unified diff files) implement a (quick and dirty but usefull) extension to IDLE 0.8 (Python 2.2) - Tested on WINDOWS 95/98/NT/2000 - Similar to "CallTips" this extension shows (context sensitive) all available member functions and attributes of the current object after hitting the 'dot'-key. The toplevel help widget now supports scrolling. (Key- Up and Key-Down events) ...that is why I changed among else the first argument of 'showtip' from 'text string' to a 'list of text strings' ... The 'space'-key is used to insert the topmost item of the help widget into an IDLE text window. ...the even handling seems to be a critical part of the current IDLE implementation. That is why I added the new functionallity as a patch of CallTips.py and CallTipWindow.py. May be you still have a better implementation ... Greetings Martin Liebmann ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 17:29 Message: Logged In: YES user_id=21627 There has been posted a memorandum on IDLE patches recently; all change *must* be contributed to the idlefork project here on SF. Rejecting this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-18 17:36 Message: Logged In: YES user_id=6380 I'm really sorry, I just don't have the time to hack on IDLE. Perhaps you can resubmit this patch to the IDLEFORK project (also at SF)? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-16 17:40 Message: Logged In: YES user_id=6656 feature --> not in 2.2.x ---------------------------------------------------------------------- Comment By: Martin Liebmann (mliebmann) Date: 2002-03-07 22:41 Message: Logged In: YES user_id=475133 Patched and more robust version of the extended files CallTips.py and CallTipWindows.py. (Now more compatible to earlier versions of python) ---------------------------------------------------------------------- Comment By: Martin Liebmann (mliebmann) Date: 2002-03-03 23:02 Message: Logged In: YES user_id=475133 '' must be substituted by '.' within CallTip.py ! ( Linux do not support an event named ) Running idle on Linux, I found the warning, that 'import *' is not allowed within function '_dir_main' of CallTip.py ??? Nevertheless CallTips works fine on Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=525109&group_id=5470 From noreply@sourceforge.net Tue Sep 17 16:29:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 08:29:50 -0700 Subject: [Patches] [ python-Patches-539043 ] Support PyChecker in IDLE Message-ID: Patches item #539043, was opened at 2002-04-04 03:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=539043&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Support PyChecker in IDLE Initial Comment: This patch adds SIMPLE support for pychecker in IDLE. It is not complete. It pops up a window, you can enter filenames (not even a file dialog!), and run pychecker. You cannot change examples. If someone wants to really integrate this, they should add the user interface in pychecker (pychecker/options.py), use a file dialog to enter files, and handle file modifications. Since pychecker imports the files, they need to be removed from sys.modules, so modifications will be seen. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 17:29 Message: Logged In: YES user_id=21627 There has been posted a memorandum on IDLE patches recently; all change *must* be contributed to the idlefork project here on SF. Rejecting this patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-04-05 21:24 Message: Logged In: YES user_id=33168 No need to worry. Really, just want to have MetaSlash mentioned. But note, this patch is still incomplete and more work needs to be done before this should be accepted. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-05 21:08 Message: Logged In: YES user_id=21627 I'm concerned about the copyright notice. "All rights reserved" means "you cannot copy it". Could you consider licensing this under the PSF license? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=539043&group_id=5470 From noreply@sourceforge.net Tue Sep 17 16:30:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 08:30:12 -0700 Subject: [Patches] [ python-Patches-606132 ] Mac OS X keydefs Message-ID: Patches item #606132, was opened at 2002-09-07 23:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606132&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X keydefs Initial Comment: Adds keydefs that are more suitable to Mac OS X; also disable CallTips in config-mac.txt due to broken tooltips in Tk. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 17:30 Message: Logged In: YES user_id=21627 There has been posted a memorandum on IDLE patches recently; all change *must* be contributed to the idlefork project here on SF. Rejecting this patch. ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2002-09-11 21:25 Message: Logged In: YES user_id=24100 Good idea Martin, will do. Guido wants this patch to be ported to idlefork, so I guess it can be closed here. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-11 20:30 Message: Logged In: YES user_id=21627 The patch looks fine to me, but I'd like to get confirmation from another Mac user that these are indeed reasonable key bindings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=606132&group_id=5470 From noreply@sourceforge.net Tue Sep 17 22:22:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 14:22:25 -0700 Subject: [Patches] [ python-Patches-591713 ] Fix "file:" URL to have right no. of /'s Message-ID: Patches item #591713, was opened at 2002-08-06 15:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=591713&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruce Atherton (callenish) >Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Fix "file:" URL to have right no. of /'s Initial Comment: If you run urlparse.urljoin() on a file: URL, the resulting URL has together with the wrong number of '/'s in it. Properly formed, the URL (assuming no netloc) should have three slashes, so that it looks like "file:///...". The current code drops that down to one. The error appears to be in a condition in urlunsplit(). It doesn't show up except in this one instance because the test is only run iff the scheme is in the list of those that can take a netloc and there is no netloc present in the URL. Apparently, this is pretty rare. Patch attached that corrects the condition. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-17 17:22 Message: Logged In: YES user_id=33168 Not sure who is best to review this? Fred? Jeremy? Someone else? This patch works for me. I have a test too. Assign back to me if you want me to check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=591713&group_id=5470 From noreply@sourceforge.net Wed Sep 18 03:57:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 19:57:24 -0700 Subject: [Patches] [ python-Patches-554807 ] Add _winreg support for Cygwin Message-ID: Patches item #554807, was opened at 2002-05-11 22:01 You can respond by visiting: https://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: Mark Hammond (mhammond) 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: Mark Hammond (mhammond) Date: 2002-09-18 12:57 Message: Logged In: YES user_id=14198 I'll take this on. I have a number of other patches and bugs to look at, so if someone wants to beat me to it, be my guest. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 03:57 Message: Logged In: YES user_id=21627 If a convincing patch comes along, I'd happily apply it. Supporting _winreg is still reasonable even if /proc/registry exists, for compatibility with other Win32 ports. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-17 03:19 Message: Logged In: NO I'm prepared to try to help if there's still energy here, and there are specific things to do. However I agree that _if_ the cygwin /proc/registry story is going to become writeable, then there's not much point. ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-07-31 00:04 Message: Logged In: YES user_id=329402 I plan to get back to this eventually, although held off for three reasons: - Cygwin is incorporating a registry file system that may be a better way to implement this - saw some posts about possible Unicode changes - Real Life (job priorities, vacation) I probably won't get back to this until the middle of August. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-28 20:02 Message: Logged In: YES user_id=21627 Is any kind of tweaking forthcoming? ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-15 23: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 22: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 22: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 08: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=554807&group_id=5470 From noreply@sourceforge.net Wed Sep 18 10:42:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Sep 2002 02:42:20 -0700 Subject: [Patches] [ python-Patches-608999 ] configure on Irix (sockets, posix) Message-ID: Patches item #608999, was opened at 2002-09-13 20:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: configure on Irix (sockets, posix) Initial Comment: The configure script checks for various library calls just by calling them prefixed with (void), thus verifying they exist but not checking if their type is correctly declared. On Irix and MIPSPro cc, various _r functions (ctermid_r, gethostbyaddr_r etc) need extra directives in order to be declared. This is what the patch does. Note: in the patch, the check against the CC var is "cc*)" and not "cc)". This is deliberate, because if there is a SGI_ABI env var set to something (eg. -64 for 64bit executable), the configure script changes the CC var to include the SGI_ABI contents. ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2002-09-18 12:42 Message: Logged In: YES user_id=539787 Inserted the comments requested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 18:14 Message: Logged In: YES user_id=21627 The patch looks good, but I still must request a summary comment above each of the changes that indicates what compilation or runtime changes are fixed. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-17 13:22 Message: Logged In: YES user_id=539787 These defines apply for the compiler MIPSPro 7.x. Since it is cumbersome to make that clear in the configure script, I chose to make patches directly to the three modules that failed to compile, where it's easiest to check for OS and compiler version. The three modules are _hotshot, posixmodule and socketmodule. The patch has been tested on Irix 6.5 (I have no access to older versions) and on three separate machines (Indy, Octane and an Origin2K), and that is why I was a little slow in replying. Please delete the previous patch (if you have permission to). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 20:54 Message: Logged In: YES user_id=21627 Can you please add a comment (in the patch) which of these defines is necessary to activate what specific feature? Five years from now, the need for these defines may be gone, but nobody will dare to remove the defines since nobod knows why they are there in the first place. Also, what versions of Irix has this patch been tested on? Which additional versions is it supposed to work on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 From noreply@sourceforge.net Wed Sep 18 10:51:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Sep 2002 02:51:42 -0700 Subject: [Patches] [ python-Patches-608999 ] configure on Irix (sockets, posix) Message-ID: Patches item #608999, was opened at 2002-09-13 19:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) >Assigned to: Martin v. Löwis (loewis) Summary: configure on Irix (sockets, posix) Initial Comment: The configure script checks for various library calls just by calling them prefixed with (void), thus verifying they exist but not checking if their type is correctly declared. On Irix and MIPSPro cc, various _r functions (ctermid_r, gethostbyaddr_r etc) need extra directives in order to be declared. This is what the patch does. Note: in the patch, the check against the CC var is "cc*)" and not "cc)". This is deliberate, because if there is a SGI_ABI env var set to something (eg. -64 for 64bit executable), the configure script changes the CC var to include the SGI_ABI contents. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-18 11:42 Message: Logged In: YES user_id=539787 Inserted the comments requested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 17:14 Message: Logged In: YES user_id=21627 The patch looks good, but I still must request a summary comment above each of the changes that indicates what compilation or runtime changes are fixed. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-17 12:22 Message: Logged In: YES user_id=539787 These defines apply for the compiler MIPSPro 7.x. Since it is cumbersome to make that clear in the configure script, I chose to make patches directly to the three modules that failed to compile, where it's easiest to check for OS and compiler version. The three modules are _hotshot, posixmodule and socketmodule. The patch has been tested on Irix 6.5 (I have no access to older versions) and on three separate machines (Indy, Octane and an Origin2K), and that is why I was a little slow in replying. Please delete the previous patch (if you have permission to). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 19:54 Message: Logged In: YES user_id=21627 Can you please add a comment (in the patch) which of these defines is necessary to activate what specific feature? Five years from now, the need for these defines may be gone, but nobody will dare to remove the defines since nobod knows why they are there in the first place. Also, what versions of Irix has this patch been tested on? Which additional versions is it supposed to work on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 From noreply@sourceforge.net Wed Sep 18 18:35:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Sep 2002 10:35:32 -0700 Subject: [Patches] [ python-Patches-611191 ] Updated .spec file for 2.2 series. Message-ID: Patches item #611191, was opened at 2002-09-18 17:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611191&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Updated .spec file for 2.2 series. Initial Comment: Attached is a new .spec file which sould be pushed into CVS. Changes include adding a Makefile.pre.in to the -devel package, and fixing the historic lack of a "python2.2" binary when building "python2". Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611191&group_id=5470 From noreply@sourceforge.net Thu Sep 19 01:36:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Sep 2002 17:36: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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open >Resolution: Remind Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) 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. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-18 20:36 Message: Logged In: YES user_id=6380 Setting the Resolution to Remind because it's not done IMO. It's possible for an app embedding Python to call Py_Initialize() more than once, with Py_Finalize() in between. Then Py_Frame_Init() would leak a string and PyInt_Init() would leak 105 int objects, plus the free list. And, how do you know that all small ints fit in one freelist block? But please go on, I (still :-) like the idea. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 11:19 Message: Logged In: YES user_id=33168 I've updated the patch. It's more of the same types of changes: * intobject stuff is the same, ie allocate small ints on startup - the only change is to bump NSMALLNEGINTS from 1 to 5 * frameobject: intern "__builtins__" on startup not in Frame_New * DECREF instead of XDECREF in frame for code, builtins, and globals (note, INCREF was used for these, not XINCREF) I've been running with these for months, so I'm pretty sure they are safe. Unless you changed your mind about the int changes, these changes should be ok too. Just giving you one last chance to change your mind. :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-08 20:28 Message: Logged In: YES user_id=33168 No, I've still got some outstanding modifications. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-09-08 00:57 Message: Logged In: YES user_id=80475 Are these all done now? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-03 11:59 Message: Logged In: YES user_id=33168 Checked in the memset()s in: {list,tuple}object.c and _sre.c. object.c 2.178 Still have to do int and frame. I've cleaned up int so that if there is an init failure, a fatal error is raised similar to other initializations. I will get around to checking that in. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-05 17:43 Message: Logged In: YES user_id=6380 I like all of these, even PyInt_Init(). Go for it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-05-31 18:11 Message: Logged In: YES user_id=80475 Wow, you plowed through a lot of code! Two sets of optimizations look worthwhile, the memsets() and the XINCREFs to INCREFS. Probably the fastlocals substitutions should be done also, but more for beauty and clarity than speed. I checked those three categories of changes on my machine. They compile fine, pass the standard regression tests and checkout okay on my personal, realcode testfarm. I don't think the PyInt_Init() addition buys us anything. The register and macro tweaks may cost more in review time and potential errors than they could ever save in cumulative computer time. Recommend you get these in before someone changes the codebase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&group_id=5470 From noreply@sourceforge.net Thu Sep 19 08:44:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 00:44:44 -0700 Subject: [Patches] [ python-Patches-611464 ] asyncore dies on Windows Message-ID: Patches item #611464, was opened at 2002-09-19 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore dies on Windows Initial Comment: On windows, select.select raises select.error(2, 'No such file or directory) if called with 3 empty lists. This is not caught in asyncore's loop. The attached patch fixes this by simply ignoring the exception (2 is ENOENT) in the same way as is done for EINTR already. It may be argued that it would be better to catch this exception in the select implementation on Windows itself... IMO this is also a bugfix candidate for 2.2 and 2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 From noreply@sourceforge.net Thu Sep 19 09:04:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 01:04:09 -0700 Subject: [Patches] [ python-Patches-608999 ] configure on Irix (sockets, posix) Message-ID: Patches item #608999, was opened at 2002-09-13 19:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 Category: Build Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. Löwis (loewis) Summary: configure on Irix (sockets, posix) Initial Comment: The configure script checks for various library calls just by calling them prefixed with (void), thus verifying they exist but not checking if their type is correctly declared. On Irix and MIPSPro cc, various _r functions (ctermid_r, gethostbyaddr_r etc) need extra directives in order to be declared. This is what the patch does. Note: in the patch, the check against the CC var is "cc*)" and not "cc)". This is deliberate, because if there is a SGI_ABI env var set to something (eg. -64 for 64bit executable), the configure script changes the CC var to include the SGI_ABI contents. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-19 10:04 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as _hotshot.c 1.29; posixmodule.c 2.260; socketmodule.c 1.245; ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-18 11:42 Message: Logged In: YES user_id=539787 Inserted the comments requested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 17:14 Message: Logged In: YES user_id=21627 The patch looks good, but I still must request a summary comment above each of the changes that indicates what compilation or runtime changes are fixed. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-17 12:22 Message: Logged In: YES user_id=539787 These defines apply for the compiler MIPSPro 7.x. Since it is cumbersome to make that clear in the configure script, I chose to make patches directly to the three modules that failed to compile, where it's easiest to check for OS and compiler version. The three modules are _hotshot, posixmodule and socketmodule. The patch has been tested on Irix 6.5 (I have no access to older versions) and on three separate machines (Indy, Octane and an Origin2K), and that is why I was a little slow in replying. Please delete the previous patch (if you have permission to). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 19:54 Message: Logged In: YES user_id=21627 Can you please add a comment (in the patch) which of these defines is necessary to activate what specific feature? Five years from now, the need for these defines may be gone, but nobody will dare to remove the defines since nobod knows why they are there in the first place. Also, what versions of Irix has this patch been tested on? Which additional versions is it supposed to work on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 From noreply@sourceforge.net Thu Sep 19 09:04:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 01:04:43 -0700 Subject: [Patches] [ python-Patches-608999 ] configure on Irix (sockets, posix) Message-ID: Patches item #608999, was opened at 2002-09-13 19:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. Löwis (loewis) Summary: configure on Irix (sockets, posix) Initial Comment: The configure script checks for various library calls just by calling them prefixed with (void), thus verifying they exist but not checking if their type is correctly declared. On Irix and MIPSPro cc, various _r functions (ctermid_r, gethostbyaddr_r etc) need extra directives in order to be declared. This is what the patch does. Note: in the patch, the check against the CC var is "cc*)" and not "cc)". This is deliberate, because if there is a SGI_ABI env var set to something (eg. -64 for 64bit executable), the configure script changes the CC var to include the SGI_ABI contents. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-19 10:04 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as _hotshot.c 1.29; posixmodule.c 2.260; socketmodule.c 1.245; ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-18 11:42 Message: Logged In: YES user_id=539787 Inserted the comments requested. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 17:14 Message: Logged In: YES user_id=21627 The patch looks good, but I still must request a summary comment above each of the changes that indicates what compilation or runtime changes are fixed. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-17 12:22 Message: Logged In: YES user_id=539787 These defines apply for the compiler MIPSPro 7.x. Since it is cumbersome to make that clear in the configure script, I chose to make patches directly to the three modules that failed to compile, where it's easiest to check for OS and compiler version. The three modules are _hotshot, posixmodule and socketmodule. The patch has been tested on Irix 6.5 (I have no access to older versions) and on three separate machines (Indy, Octane and an Origin2K), and that is why I was a little slow in replying. Please delete the previous patch (if you have permission to). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-16 19:54 Message: Logged In: YES user_id=21627 Can you please add a comment (in the patch) which of these defines is necessary to activate what specific feature? Five years from now, the need for these defines may be gone, but nobody will dare to remove the defines since nobod knows why they are there in the first place. Also, what versions of Irix has this patch been tested on? Which additional versions is it supposed to work on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=608999&group_id=5470 From noreply@sourceforge.net Thu Sep 19 09:09:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 01:09:34 -0700 Subject: [Patches] [ python-Patches-611464 ] asyncore dies on Windows Message-ID: Patches item #611464, was opened at 2002-09-19 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore dies on Windows Initial Comment: On windows, select.select raises select.error(2, 'No such file or directory) if called with 3 empty lists. This is not caught in asyncore's loop. The attached patch fixes this by simply ignoring the exception (2 is ENOENT) in the same way as is done for EINTR already. It may be argued that it would be better to catch this exception in the select implementation on Windows itself... IMO this is also a bugfix candidate for 2.2 and 2.1. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-19 10:09 Message: Logged In: YES user_id=21627 I would indeed argue that select should behave uniformly in this case. On Unix, it blocks until there is a timeout, or until a signal occurs. Can you come up with a patch that does the same on Windows? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 From noreply@sourceforge.net Thu Sep 19 15:31:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 07:31:26 -0700 Subject: [Patches] [ python-Patches-525109 ] Extension to Calltips / Show attributes Message-ID: Patches item #525109, was opened at 2002-03-03 06:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=525109&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Martin Liebmann (mliebmann) Assigned to: Nobody/Anonymous (nobody) Summary: Extension to Calltips / Show attributes Initial Comment: The attached files (unified diff files) implement a (quick and dirty but usefull) extension to IDLE 0.8 (Python 2.2) - Tested on WINDOWS 95/98/NT/2000 - Similar to "CallTips" this extension shows (context sensitive) all available member functions and attributes of the current object after hitting the 'dot'-key. The toplevel help widget now supports scrolling. (Key- Up and Key-Down events) ...that is why I changed among else the first argument of 'showtip' from 'text string' to a 'list of text strings' ... The 'space'-key is used to insert the topmost item of the help widget into an IDLE text window. ...the even handling seems to be a critical part of the current IDLE implementation. That is why I added the new functionallity as a patch of CallTips.py and CallTipWindow.py. May be you still have a better implementation ... Greetings Martin Liebmann ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-19 09:31 Message: Logged In: YES user_id=149084 Accepted this as an Idlefork patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-17 10:29 Message: Logged In: YES user_id=21627 There has been posted a memorandum on IDLE patches recently; all change *must* be contributed to the idlefork project here on SF. Rejecting this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-07-18 10:36 Message: Logged In: YES user_id=6380 I'm really sorry, I just don't have the time to hack on IDLE. Perhaps you can resubmit this patch to the IDLEFORK project (also at SF)? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-16 11:40 Message: Logged In: YES user_id=6656 feature --> not in 2.2.x ---------------------------------------------------------------------- Comment By: Martin Liebmann (mliebmann) Date: 2002-03-07 16:41 Message: Logged In: YES user_id=475133 Patched and more robust version of the extended files CallTips.py and CallTipWindows.py. (Now more compatible to earlier versions of python) ---------------------------------------------------------------------- Comment By: Martin Liebmann (mliebmann) Date: 2002-03-03 17:02 Message: Logged In: YES user_id=475133 '' must be substituted by '.' within CallTip.py ! ( Linux do not support an event named ) Running idle on Linux, I found the warning, that 'import *' is not allowed within function '_dir_main' of CallTip.py ??? Nevertheless CallTips works fine on Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=525109&group_id=5470 From noreply@sourceforge.net Thu Sep 19 16:00:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 08:00:46 -0700 Subject: [Patches] [ python-Patches-611464 ] asyncore dies on Windows Message-ID: Patches item #611464, was opened at 2002-09-19 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore dies on Windows Initial Comment: On windows, select.select raises select.error(2, 'No such file or directory) if called with 3 empty lists. This is not caught in asyncore's loop. The attached patch fixes this by simply ignoring the exception (2 is ENOENT) in the same way as is done for EINTR already. It may be argued that it would be better to catch this exception in the select implementation on Windows itself... IMO this is also a bugfix candidate for 2.2 and 2.1. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-09-19 17:00 Message: Logged In: YES user_id=11105 Yes, select must be fixed. There is another problem I noticed in the meantime: the error codes raised by select() on Windows are bogus, because Windows doesn't set errno, one must use WSAGetLastError(). I have patched selectmodule.c, but currently I cannot create a diff because of CVS problems. This patch class Sleep() if the lists are empty. It does not interrupt on a signal. This would require the same code than someone (Mark?) changed recently in timemodule.c, so that sleep() can be interrupted. I'm unsure what to do: Leave it uninterruptable, copy the C code over into selectmodule.c, or PyImport_Import the time module and use the sleep() function, or whatever. The function in question is timemodule.c, floatsleep(). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-19 10:09 Message: Logged In: YES user_id=21627 I would indeed argue that select should behave uniformly in this case. On Unix, it blocks until there is a timeout, or until a signal occurs. Can you come up with a patch that does the same on Windows? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 From noreply@sourceforge.net Thu Sep 19 18:24:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 10:24:54 -0700 Subject: [Patches] [ python-Patches-611464 ] asyncore dies on Windows Message-ID: Patches item #611464, was opened at 2002-09-19 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore dies on Windows Initial Comment: On windows, select.select raises select.error(2, 'No such file or directory) if called with 3 empty lists. This is not caught in asyncore's loop. The attached patch fixes this by simply ignoring the exception (2 is ENOENT) in the same way as is done for EINTR already. It may be argued that it would be better to catch this exception in the select implementation on Windows itself... IMO this is also a bugfix candidate for 2.2 and 2.1. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-09-19 19:24 Message: Logged In: YES user_id=11105 CVS works again, so here is the patch. Fixes the two problems: bogus error codes, and can be called with empty lists. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-19 17:00 Message: Logged In: YES user_id=11105 Yes, select must be fixed. There is another problem I noticed in the meantime: the error codes raised by select() on Windows are bogus, because Windows doesn't set errno, one must use WSAGetLastError(). I have patched selectmodule.c, but currently I cannot create a diff because of CVS problems. This patch class Sleep() if the lists are empty. It does not interrupt on a signal. This would require the same code than someone (Mark?) changed recently in timemodule.c, so that sleep() can be interrupted. I'm unsure what to do: Leave it uninterruptable, copy the C code over into selectmodule.c, or PyImport_Import the time module and use the sleep() function, or whatever. The function in question is timemodule.c, floatsleep(). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-19 10:09 Message: Logged In: YES user_id=21627 I would indeed argue that select should behave uniformly in this case. On Unix, it blocks until there is a timeout, or until a signal occurs. Can you come up with a patch that does the same on Windows? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 From noreply@sourceforge.net Thu Sep 19 20:24:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 12:24:10 -0700 Subject: [Patches] [ python-Patches-611464 ] select problems on Windows Message-ID: Patches item #611464, was opened at 2002-09-19 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) >Summary: select problems on Windows Initial Comment: On windows, select.select raises select.error(2, 'No such file or directory) if called with 3 empty lists. This is not caught in asyncore's loop. The attached patch fixes this by simply ignoring the exception (2 is ENOENT) in the same way as is done for EINTR already. It may be argued that it would be better to catch this exception in the select implementation on Windows itself... IMO this is also a bugfix candidate for 2.2 and 2.1. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-09-19 21:24 Message: Logged In: YES user_id=11105 I've removed the original patch for asyncore, because it wasn't correct. After some reading and thinking, there does not seem to be an easy way to implement an interruptible select, so I consider the patch to selectmodule.c complete. And I changed the title line... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-19 19:24 Message: Logged In: YES user_id=11105 CVS works again, so here is the patch. Fixes the two problems: bogus error codes, and can be called with empty lists. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-19 17:00 Message: Logged In: YES user_id=11105 Yes, select must be fixed. There is another problem I noticed in the meantime: the error codes raised by select() on Windows are bogus, because Windows doesn't set errno, one must use WSAGetLastError(). I have patched selectmodule.c, but currently I cannot create a diff because of CVS problems. This patch class Sleep() if the lists are empty. It does not interrupt on a signal. This would require the same code than someone (Mark?) changed recently in timemodule.c, so that sleep() can be interrupted. I'm unsure what to do: Leave it uninterruptable, copy the C code over into selectmodule.c, or PyImport_Import the time module and use the sleep() function, or whatever. The function in question is timemodule.c, floatsleep(). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-19 10:09 Message: Logged In: YES user_id=21627 I would indeed argue that select should behave uniformly in this case. On Unix, it blocks until there is a timeout, or until a signal occurs. Can you come up with a patch that does the same on Windows? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 From noreply@sourceforge.net Thu Sep 19 20:29:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 12:29:21 -0700 Subject: [Patches] [ python-Patches-611760 ] zipfile.py reads archives with comments Message-ID: Patches item #611760, was opened at 2002-09-19 19:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611760&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile.py reads archives with comments Initial Comment: Module zipfile can not read ZIP archives which have appended archive comments. I have only gotten two complaints about this, but I feel that this limitation should be removed. Archive comments are appended to ZIP archives, and can be up to 64K bytes long. Reading them would require searching the end of the archive for the end record magic number. The attached patch will (1) seek and verify a zero length comment; and if this fails (2) search the last 4K bytes of the file for a comment. The 4K limitation (down from 64K) is for efficiency. This was tested on Python 2.2.1, but zipfile.py has changed since then. So the patch was hand edited into today's CVS zipfile.py version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611760&group_id=5470 From noreply@sourceforge.net Thu Sep 19 21:57:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 13:57:02 -0700 Subject: [Patches] [ python-Patches-590352 ] py2texi.el update Message-ID: Patches item #590352, was opened at 2002-08-02 16:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590352&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: py2texi.el update Initial Comment: [python2.3 (and python2.2)] Attached is a patch from Milan Zamazal to update py2texi.el: - allow to set the info file name - correctly generate code for nodes like: \subsubsection{File Objects\obindex{file} \label{bltin-file-objects}} ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-19 16:57 Message: Logged In: YES user_id=3066 I've attached my revised patch that adds support for some additioanal markup constructs beyond the previous version of the patch. Taken relative to the CVS HEAD. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-08-06 18:22 Message: Logged In: YES user_id=60903 An updated patch, which now matches Milan's version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590352&group_id=5470 From noreply@sourceforge.net Fri Sep 20 13:55:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Sep 2002 05:55:13 -0700 Subject: [Patches] [ python-Patches-531491 ] PEP 4 update: deprecations Message-ID: Patches item #531491, was opened at 2002-03-18 20:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531491&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Martin v. Löwis (loewis) Summary: PEP 4 update: deprecations Initial Comment: The following modules should be deprecated for Python 2.3: mimify.py, rfc822.py, MIMEWriter.py, and mimetools.py. All are supplanted by Python 2.2's email package. Attached is the proposed mod to PEP 4 as per procedure described therein. I am not including mods to the module documents as those should be easy to add. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-20 14:55 Message: Logged In: YES user_id=21627 Committed as rev 1.6. Sorry it took so long. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-12 06:24 Message: Logged In: YES user_id=33168 Martin, is there anything else that needs to be done or can we update PEP 4? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=531491&group_id=5470 From noreply@sourceforge.net Fri Sep 20 13:57:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Sep 2002 05:57:45 -0700 Subject: [Patches] [ python-Patches-611760 ] zipfile.py reads archives with comments Message-ID: Patches item #611760, was opened at 2002-09-19 21:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611760&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile.py reads archives with comments Initial Comment: Module zipfile can not read ZIP archives which have appended archive comments. I have only gotten two complaints about this, but I feel that this limitation should be removed. Archive comments are appended to ZIP archives, and can be up to 64K bytes long. Reading them would require searching the end of the archive for the end record magic number. The attached patch will (1) seek and verify a zero length comment; and if this fails (2) search the last 4K bytes of the file for a comment. The 4K limitation (down from 64K) is for efficiency. This was tested on Python 2.2.1, but zipfile.py has changed since then. So the patch was hand edited into today's CVS zipfile.py version. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-20 14:57 Message: Logged In: YES user_id=21627 Can you please attach an example zipfile to test this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611760&group_id=5470 From noreply@sourceforge.net Fri Sep 20 14:24:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Sep 2002 06:24:25 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 08:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&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: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Fri Sep 20 14:54:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Sep 2002 06:54:02 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 15:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&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: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-09-20 15:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Fri Sep 20 15:07:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Sep 2002 07:07:49 -0700 Subject: [Patches] [ python-Patches-611760 ] zipfile.py reads archives with comments Message-ID: Patches item #611760, was opened at 2002-09-19 19:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611760&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James C. Ahlstrom (ahlstromjc) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile.py reads archives with comments Initial Comment: Module zipfile can not read ZIP archives which have appended archive comments. I have only gotten two complaints about this, but I feel that this limitation should be removed. Archive comments are appended to ZIP archives, and can be up to 64K bytes long. Reading them would require searching the end of the archive for the end record magic number. The attached patch will (1) seek and verify a zero length comment; and if this fails (2) search the last 4K bytes of the file for a comment. The 4K limitation (down from 64K) is for efficiency. This was tested on Python 2.2.1, but zipfile.py has changed since then. So the patch was hand edited into today's CVS zipfile.py version. ---------------------------------------------------------------------- >Comment By: James C. Ahlstrom (ahlstromjc) Date: 2002-09-20 14:07 Message: Logged In: YES user_id=64929 OK, here is a ZIP file which has an archive (appended) multiline comment. The comment is available as the attribute ZipFile::comment. I didn't add code to write ZIP files with comments. We don't need that, right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-20 12:57 Message: Logged In: YES user_id=21627 Can you please attach an example zipfile to test this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611760&group_id=5470 From Andrew.Mackeith@ABAQUS.com Fri Sep 20 23:54:15 2002 From: Andrew.Mackeith@ABAQUS.com (Andrew MacKeith) Date: Fri, 20 Sep 2002 18:54:15 -0400 Subject: [Patches] dumbdbm.py Message-ID: <3D8BA717.5A412588@ABAQUS.com> I have been using shelve for a while with Python-2.0 and I soon found that it had a bad bug. I see that the bug has been fixed in later versions but I have, in the meantime, done some work on the dumbdbm module. My version does the following: reclaims free space recognises the flag argument is faster if the db is closed often is safer when re-writing a changed record How should I submit these changes to Python ? The files are attached: The new module: dumbdbm.py Context diff with the latest version in the cvs tree: dumbdbm.py.diff My version is designed for use with Python-2.0. I have commented the places where it should be updated for the current Python. It will save a changed record in a new location so that the old record is accessible until the new write is complete. Every write causes the _dirfile to be updated, but only by one index item. This avoids the requirement to commit every time the database is closed. The downside is that the _dirfile may contain duplicate entires for one key, but these are ignored when reading the _dirfile. The upside is that a close is faster. There is an optional flag to commit on close. Andrew MacKeith From Andrew.Mackeith@ABAQUS.com Fri Sep 20 23:58:42 2002 From: Andrew.Mackeith@ABAQUS.com (Andrew MacKeith) Date: Fri, 20 Sep 2002 18:58:42 -0400 Subject: [Patches] dumbdbm.py Message-ID: <3D8BA822.4D237066@ABAQUS.com> This is a multi-part message in MIME format. --------------6BE1C944D05101794E7C3FE9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here are the attachments promised with my earlier e-mail The files are attached: The new module: dumbdbm.py Context diff with the latest version in the cvs tree: dumbdbm.py.diff --------------6BE1C944D05101794E7C3FE9 Content-Type: text/plain; charset=us-ascii; name="dumbdbm.py" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dumbdbm.py" """A dumb and slow but simple dbm clone. For database spam, spam.dir contains the index (a text file), spam.bak *may* contain a backup of the index (also a text file), while spam.dat contains the data (a binary file). XXX TO DO: - seems to contain a bug when updating... - reclaim free space (currently, space once occupied by deleted or expanded items is never reused) - support concurrent access (currently, if two processes take turns making updates, they can mess up the index) - support efficient access to large databases (currently, the whole index is read when the database is opened, and some updates rewrite the whole index) - support opening for read-only (flag = 'm') Andrew MacKeith Sep 2002 Updating bug already fixed. Optional flag to omit unneeded commit. Reclaim free space (see above). Save new data before overwriting old. Support flag argument as described in anydbm. """ import os as _os import __builtin__ _open = __builtin__.open _BLOCKSIZE = 512 error = IOError # For anydbm if not hasattr(_os, 'extsep'): # 2.2 omit these 2 lines _os.extsep = '.' # # do non-essential write of index at close if 1 commitOnClose = 0 class _Database: def __init__(self, file, flag, mode): self._flag = flag self._mode = mode self.readonly = (flag == 'r') self._dirfile = file + _os.extsep + 'dir' self._datfile = file + _os.extsep + 'dat' self._bakfile = file + _os.extsep + 'bak' if flag[0] == 'n': # create new database - overwrite old if it exists f = _open(self._dirfile, 'w+', self._mode) f.close() f = _open(self._datfile, 'w+', self._mode) else: # Mod by Jack: create data file if needed try: f = _open(self._datfile, 'r') except IOError: if flag[0] == 'c': f = _open(self._datfile, 'w', self._mode) else: raise f.close() self._update() self._reclaim = None self._reclaimAdded = 0 def _update(self): self._index = {} try: f = _open(self._dirfile) except IOError: pass else: lines = 0 while 1: line = f.readline().rstrip() if not line: break key, (pos, siz) = eval(line) # a later key entry replaces an earlier one self._index[key] = (pos, siz) lines = lines + 1 f.close() # change to index without commit can cause multiple, ignored, # entries in self._dirfile. This is done for speed. # If _dirfile gets large, re-save the index if lines > len(self._index) * 2: self._commit() def _commit(self): try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass f = _open(self._dirfile, 'w', self._mode) for key, (pos, siz) in self._index.items(): f.write("%s, (%d, %d)\n" % (repr(key), pos, siz)) f.close() def __getitem__(self, key): pos, siz = self._index[key] # may raise KeyError f = _open(self._datfile, 'rb') f.seek(pos) dat = f.read(siz) f.close() return dat def _addval(self, val): f = _open(self._datfile, 'rb+') f.seek(0, 2) pos = int(f.tell()) ## Does not work under MW compiler ## pos = ((pos + _BLOCKSIZE - 1) / _BLOCKSIZE) * _BLOCKSIZE ## f.seek(pos) npos = self._roundblock(pos) f.write('\0'*(npos-pos)) pos = npos f.write(val) f.close() return (pos, len(val)) def _setval(self, pos, val): f = _open(self._datfile, 'rb+') f.seek(pos) f.write(val) f.close() return (pos, len(val)) def _addkey(self, key, (pos, siz)): self._index[key] = (pos, siz) f = _open(self._dirfile, 'a', self._mode) f.write("%s, (%d, %d)\n" % (repr(key), pos, siz)) f.close() def __setitem__(self, key, val): if self.readonly: raise TypeError, 'db is read only' if not type(key) == type('') == type(val): raise TypeError, "keys and values must be strings" # save new record before changing index (pos, siz) = self._insertval(key, val) if self._index.has_key(key): # 2.2 if key in self._index oldpos, oldsiz = self._index[key] avail = self._roundblock(oldsiz) self._addReclaim((avail, oldpos)) self._index[key] = (pos, siz) # add key at end of dir file; earlier entry is ignored. self._addkey(key, (pos, siz)) def _insertval(self, key, val): if self._reclaim is None: self._createReclaim() elif self._reclaimAdded: self._mergeReclaim() for space, pos in self._reclaim: if space >= len(val): self._reclaim.remove((space, pos)) sizreq = self._roundblock(len(val)) npos = pos + sizreq avail = space - sizreq if avail: self._addReclaim((avail, npos)) # put val into reclaimed space return self._setval(pos, val) # add at end of _datfile return self._addval(val) def __delitem__(self, key): if self.readonly: raise TypeError, 'db is read only' # keep track of space pos, siz = self._index[key] del self._index[key] self._commit() avail = self._roundblock(siz) self._addReclaim((avail, pos)) def keys(self): return self._index.keys() def has_key(self, key): return self._index.has_key(key) # 2.2 return key in self._index def __contains__(self, key): return self._index.has_key(key) # 2.2 return key in self._index def iterkeys(self): return self._index.iterkeys() __iter__ = iterkeys def __len__(self): return len(self._index) def close(self): if commitOnClose: self._commit() self._index = None self._datfile = self._dirfile = self._bakfile = None def __del__(self): if self._index is not None: self._commit() def _createReclaim(self): # list of (space, pos) freespace = [] indexValues = self._index.values() indexValues.sort() # order of pos endlast = 0 for pos, siz in indexValues: if pos - endlast > 0: freespace.append(pos - endlast, endlast) endlast = pos + self._roundblock(siz) freespace.sort() self._reclaim = freespace self._reclaimAdded = 0 # truncate _datfile to stop growth when adding to end f = _open(self._datfile, 'rb+') f.seek(0, 2) endpos = int(f.tell()) if endpos > endlast: f.truncate(endlast) f.close() def _addReclaim(self, item): # add an item to _reclaim if self._reclaim is None: return self._reclaim.append(item) self._reclaimAdded = 1 def _mergeReclaim(self): # merge adjacent spaces x = [[b, a] for (a, b) in self._reclaim] x.sort() i = 0 while i < len(x) - 1: if x[i][0] + x[i][1] == x[i+1][0]: x[i][1] = x[i][1] + x[i+1][1] del x[i+1] else: i = i + 1 self._reclaim = [(b, a) for (a, b) in x] self._reclaim.sort() self._reclaimAdded = 0 def _roundblock(self, pos): blocks = (pos + _BLOCKSIZE - 1) / _BLOCKSIZE # 2.2 use // return (blocks * _BLOCKSIZE) def open(file, flag='r', mode=0666): """Open the database file, filename, and return corresponding object. The flag argument is used to control how the database is opened: 'r' open an existing database for reading. 'w' open an existing database for reading and writing. 'c' as 'w' but create the database if it does not exist. 'n' create a new empty database for reading and writing. The optional mode argument is the UNIX mode of the file, used only when the database has to be created. It defaults to octal code 0666 (and will be modified by the prevailing umask). """ # flags 'r', 'w', 'c', 'n' supported return _Database(file, flag, mode) --------------6BE1C944D05101794E7C3FE9 Content-Type: text/plain; charset=us-ascii; name="dumbdbm.py.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dumbdbm.py.diff" *** ../../dd/dumbdbm.py.cvs.2002-09-18 Wed Sep 18 08:32:06 2002 --- dumbdbm.py.019.short Fri Sep 20 18:06:18 2002 *************** *** 19,24 **** --- 19,28 ---- - support opening for read-only (flag = 'm') + Andrew MacKeith Sep 2002 + Updating bug already fixed. Optional flag to omit unneeded commit. + Reclaim free space (see above). Save new data before overwriting old. + Support flag argument as described in anydbm. """ import os as _os *************** *** 30,49 **** error = IOError # For anydbm class _Database: ! def __init__(self, file, mode): self._mode = mode self._dirfile = file + _os.extsep + 'dir' self._datfile = file + _os.extsep + 'dat' self._bakfile = file + _os.extsep + 'bak' ! # Mod by Jack: create data file if needed ! try: ! f = _open(self._datfile, 'r') ! except IOError: ! f = _open(self._datfile, 'w', self._mode) f.close() self._update() def _update(self): self._index = {} --- 34,72 ---- error = IOError # For anydbm + if not hasattr(_os, 'extsep'): # 2.2 omit these 2 lines + _os.extsep = '.' # + + # do non-essential write of index at close if 1 + commitOnClose = 0 + class _Database: ! def __init__(self, file, flag, mode): ! self._flag = flag self._mode = mode + self.readonly = (flag == 'r') self._dirfile = file + _os.extsep + 'dir' self._datfile = file + _os.extsep + 'dat' self._bakfile = file + _os.extsep + 'bak' ! if flag[0] == 'n': ! # create new database - overwrite old if it exists ! f = _open(self._dirfile, 'w+', self._mode) ! f.close() ! f = _open(self._datfile, 'w+', self._mode) ! else: ! # Mod by Jack: create data file if needed ! try: ! f = _open(self._datfile, 'r') ! except IOError: ! if flag[0] == 'c': ! f = _open(self._datfile, 'w', self._mode) ! else: ! raise f.close() self._update() + self._reclaim = None + self._reclaimAdded = 0 def _update(self): self._index = {} *************** *** 52,63 **** --- 75,94 ---- except IOError: pass else: + lines = 0 while 1: line = f.readline().rstrip() if not line: break key, (pos, siz) = eval(line) + # a later key entry replaces an earlier one self._index[key] = (pos, siz) + lines = lines + 1 f.close() + # change to index without commit can cause multiple, ignored, + # entries in self._dirfile. This is done for speed. + # If _dirfile gets large, re-save the index + if lines > len(self._index) * 2: + self._commit() def _commit(self): try: _os.unlink(self._bakfile) *************** *** 66,72 **** except _os.error: pass f = _open(self._dirfile, 'w', self._mode) for key, (pos, siz) in self._index.items(): ! f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`)) f.close() def __getitem__(self, key): --- 97,103 ---- except _os.error: pass f = _open(self._dirfile, 'w', self._mode) for key, (pos, siz) in self._index.items(): ! f.write("%s, (%d, %d)\n" % (repr(key), pos, siz)) f.close() def __getitem__(self, key): *************** *** 84,90 **** ## Does not work under MW compiler ## pos = ((pos + _BLOCKSIZE - 1) / _BLOCKSIZE) * _BLOCKSIZE ## f.seek(pos) ! npos = ((pos + _BLOCKSIZE - 1) // _BLOCKSIZE) * _BLOCKSIZE f.write('\0'*(npos-pos)) pos = npos --- 115,121 ---- ## Does not work under MW compiler ## pos = ((pos + _BLOCKSIZE - 1) / _BLOCKSIZE) * _BLOCKSIZE ## f.seek(pos) ! npos = self._roundblock(pos) f.write('\0'*(npos-pos)) pos = npos *************** *** 102,139 **** def _addkey(self, key, (pos, siz)): self._index[key] = (pos, siz) f = _open(self._dirfile, 'a', self._mode) ! f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`)) f.close() def __setitem__(self, key, val): if not type(key) == type('') == type(val): raise TypeError, "keys and values must be strings" ! if not key in self._index: ! (pos, siz) = self._addval(val) ! self._addkey(key, (pos, siz)) ! else: ! pos, siz = self._index[key] ! oldblocks = (siz + _BLOCKSIZE - 1) / _BLOCKSIZE ! newblocks = (len(val) + _BLOCKSIZE - 1) / _BLOCKSIZE ! if newblocks <= oldblocks: ! pos, siz = self._setval(pos, val) ! self._index[key] = pos, siz ! else: ! pos, siz = self._addval(val) ! self._index[key] = pos, siz def __delitem__(self, key): del self._index[key] self._commit() def keys(self): return self._index.keys() def has_key(self, key): ! return key in self._index def __contains__(self, key): ! return key in self._index def iterkeys(self): return self._index.iterkeys() --- 133,194 ---- def _addkey(self, key, (pos, siz)): self._index[key] = (pos, siz) f = _open(self._dirfile, 'a', self._mode) ! f.write("%s, (%d, %d)\n" % (repr(key), pos, siz)) f.close() def __setitem__(self, key, val): + if self.readonly: + raise TypeError, 'db is read only' if not type(key) == type('') == type(val): raise TypeError, "keys and values must be strings" ! ! # save new record before changing index ! (pos, siz) = self._insertval(key, val) ! if self._index.has_key(key): # 2.2 if key in self._index ! oldpos, oldsiz = self._index[key] ! avail = self._roundblock(oldsiz) ! self._addReclaim((avail, oldpos)) ! ! self._index[key] = (pos, siz) ! # add key at end of dir file; earlier entry is ignored. ! self._addkey(key, (pos, siz)) + def _insertval(self, key, val): + if self._reclaim is None: + self._createReclaim() + elif self._reclaimAdded: + self._mergeReclaim() + for space, pos in self._reclaim: + if space >= len(val): + self._reclaim.remove((space, pos)) + sizreq = self._roundblock(len(val)) + npos = pos + sizreq + avail = space - sizreq + if avail: + self._addReclaim((avail, npos)) + # put val into reclaimed space + return self._setval(pos, val) + # add at end of _datfile + return self._addval(val) + def __delitem__(self, key): + if self.readonly: + raise TypeError, 'db is read only' + # keep track of space + pos, siz = self._index[key] del self._index[key] self._commit() + avail = self._roundblock(siz) + self._addReclaim((avail, pos)) def keys(self): return self._index.keys() def has_key(self, key): ! return self._index.has_key(key) # 2.2 return key in self._index def __contains__(self, key): ! return self._index.has_key(key) # 2.2 return key in self._index def iterkeys(self): return self._index.iterkeys() *************** *** 143,149 **** return len(self._index) def close(self): ! self._commit() self._index = None self._datfile = self._dirfile = self._bakfile = None --- 198,205 ---- return len(self._index) def close(self): ! if commitOnClose: ! self._commit() self._index = None self._datfile = self._dirfile = self._bakfile = None *************** *** 150,165 **** def __del__(self): if self._index is not None: self._commit() ! ! ! def open(file, flag=None, mode=0666): """Open the database file, filename, and return corresponding object. ! The flag argument, used to control how the database is opened in the ! other DBM implementations, is ignored in the dumbdbm module; the ! database is always opened for update, and will be created if it does ! not exist. The optional mode argument is the UNIX mode of the file, used only when the database has to be created. It defaults to octal code 0666 (and --- 206,269 ---- def __del__(self): if self._index is not None: self._commit() ! ! def _createReclaim(self): ! # list of (space, pos) ! freespace = [] ! indexValues = self._index.values() ! indexValues.sort() # order of pos ! endlast = 0 ! for pos, siz in indexValues: ! if pos - endlast > 0: ! freespace.append(pos - endlast, endlast) ! endlast = pos + self._roundblock(siz) ! freespace.sort() ! self._reclaim = freespace ! self._reclaimAdded = 0 ! ! # truncate _datfile to stop growth when adding to end ! f = _open(self._datfile, 'rb+') ! f.seek(0, 2) ! endpos = int(f.tell()) ! if endpos > endlast: ! f.truncate(endlast) ! f.close() ! ! def _addReclaim(self, item): ! # add an item to _reclaim ! if self._reclaim is None: ! return ! self._reclaim.append(item) ! self._reclaimAdded = 1 ! ! def _mergeReclaim(self): ! # merge adjacent spaces ! x = [[b, a] for (a, b) in self._reclaim] ! x.sort() ! i = 0 ! while i < len(x) - 1: ! if x[i][0] + x[i][1] == x[i+1][0]: ! x[i][1] = x[i][1] + x[i+1][1] ! del x[i+1] ! else: ! i = i + 1 ! self._reclaim = [(b, a) for (a, b) in x] ! self._reclaim.sort() ! self._reclaimAdded = 0 ! ! def _roundblock(self, pos): ! blocks = (pos + _BLOCKSIZE - 1) / _BLOCKSIZE # 2.2 use // ! return (blocks * _BLOCKSIZE) ! ! def open(file, flag='r', mode=0666): """Open the database file, filename, and return corresponding object. ! The flag argument is used to control how the database is opened: ! 'r' open an existing database for reading. ! 'w' open an existing database for reading and writing. ! 'c' as 'w' but create the database if it does not exist. ! 'n' create a new empty database for reading and writing. The optional mode argument is the UNIX mode of the file, used only when the database has to be created. It defaults to octal code 0666 (and *************** *** 166,170 **** will be modified by the prevailing umask). """ ! # flag, mode arguments are currently ignored ! return _Database(file, mode) --- 270,274 ---- will be modified by the prevailing umask). """ ! # flags 'r', 'w', 'c', 'n' supported ! return _Database(file, flag, mode) --------------6BE1C944D05101794E7C3FE9-- From noreply@sourceforge.net Sat Sep 21 19:50:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Sep 2002 11:50:39 -0700 Subject: [Patches] [ python-Patches-612602 ] "Bare" text tag_configure in Tkinter Message-ID: Patches item #612602, was opened at 2002-09-21 18:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 Category: Tkinter Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Reeves (sreeves) Assigned to: Nobody/Anonymous (nobody) Summary: "Bare" text tag_configure in Tkinter Initial Comment: In Tcl/Tk, doing a "tag configure" operation on a text widget with only a tag name as argument returns all of the attributes configured for that tag. The analogous tag_configure method in Tkinter returns nothing. The attached patch fixes this. I'm using Python 2.1, but the same bug is in 2.2 as well. Here is a typescript showing the results of the analogous commands in Tcl/Tk and Tkinter: $ wish % text .t .t % .t tag configure someTag -foreground red % .t tag configure someTag -foreground -foreground {} {} {} red % .t tag configure someTag {-background {} {} {} {}} {-bgstipple {} {} {} {}} {-borderwidth {} {} 0 {}} {-elide {} {} 0 {}} {-fgstipple {} {} {} {}} {-font {} {} {} {}} {-foreground {} {} {} red} {-justify {} {} {} {}} {-lmargin1 {} {} {} {}} {-lmargin2 {} {} {} {}} {-offset {} {} {} {}} {-overstrike {} {} {} {}} {-relief {} {} {} {}} {-rmargin {} {} {} {}} {-spacing1 {} {} {} {}} {-spacing2 {} {} {} {}} {-spacing3 {} {} {} {}} {-tabs {} {} {} {}} {-underline {} {} {} {}} {-wrap {} {} {} {}} % ^D $ python Python 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> t = Tkinter.Text(root) >>> t.tag_configure('someTag', foreground='red') >>> t.tag_configure('someTag', 'foreground') ('foreground', '', '', '', 'red') >>> t.tag_configure('someTag') >>> ^D $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 From noreply@sourceforge.net Sat Sep 21 21:32:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Sep 2002 13:32:23 -0700 Subject: [Patches] [ python-Patches-612627 ] Allow more Unicode on sys.stdout Message-ID: Patches item #612627, was opened at 2002-09-21 22:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Allow more Unicode on sys.stdout Initial Comment: This patch extends the set of Unicode strings that can be printed to sys.stdout, to support all strings that the terminal will likely support. It also adds an encoding attribute to sys.std{in,out}. To do that: - it adds a .encoding attribute to all file objects, which is normally None - initializes the encoding of sys.stdin and sys.stdout if either is a terminal. - adds a wrapper object around sys.stdout in site.py that encodes all Unicode objects according to the detected encoding, if that encoding is known to Python To find the encoding of the terminal, it - uses GetConsoleCP and GetConsoleOutputCP on Windows, - uses nl_langinfo(CODESET) on Unix, if available. The primary rationale for this change is that people should be able to print Unicode in an interactive session. A parallel change needs to be added for IDLE, so that it adds the .encoding attribute to the emulated stdout (it already supports printing of Unicode on stdout). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 From noreply@sourceforge.net Sat Sep 21 21:35:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Sep 2002 13:35:40 -0700 Subject: [Patches] [ python-Patches-612602 ] "Bare" text tag_configure in Tkinter Message-ID: Patches item #612602, was opened at 2002-09-21 20:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 Category: Tkinter Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Reeves (sreeves) Assigned to: Nobody/Anonymous (nobody) >Summary: "Bare" text tag_configure in Tkinter Initial Comment: In Tcl/Tk, doing a "tag configure" operation on a text widget with only a tag name as argument returns all of the attributes configured for that tag. The analogous tag_configure method in Tkinter returns nothing. The attached patch fixes this. I'm using Python 2.1, but the same bug is in 2.2 as well. Here is a typescript showing the results of the analogous commands in Tcl/Tk and Tkinter: $ wish % text .t .t % .t tag configure someTag -foreground red % .t tag configure someTag -foreground -foreground {} {} {} red % .t tag configure someTag {-background {} {} {} {}} {-bgstipple {} {} {} {}} {-borderwidth {} {} 0 {}} {-elide {} {} 0 {}} {-fgstipple {} {} {} {}} {-font {} {} {} {}} {-foreground {} {} {} red} {-justify {} {} {} {}} {-lmargin1 {} {} {} {}} {-lmargin2 {} {} {} {}} {-offset {} {} {} {}} {-overstrike {} {} {} {}} {-relief {} {} {} {}} {-rmargin {} {} {} {}} {-spacing1 {} {} {} {}} {-spacing2 {} {} {} {}} {-spacing3 {} {} {} {}} {-tabs {} {} {} {}} {-underline {} {} {} {}} {-wrap {} {} {} {}} % ^D $ python Python 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> t = Tkinter.Text(root) >>> t.tag_configure('someTag', foreground='red') >>> t.tag_configure('someTag', 'foreground') ('foreground', '', '', '', 'red') >>> t.tag_configure('someTag') >>> ^D $ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 22:35 Message: Logged In: YES user_id=21627 I may be missing something, but shouldn't tag_configure return a dictionary in this case? See the widget's configure for comparison. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 From noreply@sourceforge.net Sat Sep 21 22:38:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Sep 2002 14:38:25 -0700 Subject: [Patches] [ python-Patches-612602 ] "Bare" text tag_configure in Tkinter Message-ID: Patches item #612602, was opened at 2002-09-21 18:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 Category: Tkinter Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Reeves (sreeves) Assigned to: Nobody/Anonymous (nobody) >Summary: "Bare" text tag_configure in Tkinter Initial Comment: In Tcl/Tk, doing a "tag configure" operation on a text widget with only a tag name as argument returns all of the attributes configured for that tag. The analogous tag_configure method in Tkinter returns nothing. The attached patch fixes this. I'm using Python 2.1, but the same bug is in 2.2 as well. Here is a typescript showing the results of the analogous commands in Tcl/Tk and Tkinter: $ wish % text .t .t % .t tag configure someTag -foreground red % .t tag configure someTag -foreground -foreground {} {} {} red % .t tag configure someTag {-background {} {} {} {}} {-bgstipple {} {} {} {}} {-borderwidth {} {} 0 {}} {-elide {} {} 0 {}} {-fgstipple {} {} {} {}} {-font {} {} {} {}} {-foreground {} {} {} red} {-justify {} {} {} {}} {-lmargin1 {} {} {} {}} {-lmargin2 {} {} {} {}} {-offset {} {} {} {}} {-overstrike {} {} {} {}} {-relief {} {} {} {}} {-rmargin {} {} {} {}} {-spacing1 {} {} {} {}} {-spacing2 {} {} {} {}} {-spacing3 {} {} {} {}} {-tabs {} {} {} {}} {-underline {} {} {} {}} {-wrap {} {} {} {}} % ^D $ python Python 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> t = Tkinter.Text(root) >>> t.tag_configure('someTag', foreground='red') >>> t.tag_configure('someTag', 'foreground') ('foreground', '', '', '', 'red') >>> t.tag_configure('someTag') >>> ^D $ ---------------------------------------------------------------------- >Comment By: Steve Reeves (sreeves) Date: 2002-09-21 21:38 Message: Logged In: YES user_id=2647 Oops, yeah, it should return a dictionary. Now I also see the comment in configure() about generalizing it so tag_configure() can use it too. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 20:35 Message: Logged In: YES user_id=21627 I may be missing something, but shouldn't tag_configure return a dictionary in this case? See the widget's configure for comparison. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 From noreply@sourceforge.net Sun Sep 22 09:33:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 01:33:56 -0700 Subject: [Patches] [ python-Patches-544740 ] test_commands test fails under Cygwin Message-ID: Patches item #544740, was opened at 2002-04-16 18:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: test_commands test fails under Cygwin Initial Comment: The Python 2.2.1 test_commands regression test fails under Cygwin 1.3.10 because the regular expression is pickier now and because Cygwin can have spaces in user and/or group names. See the following for some more details: http://cygwin.com/ml/cygwin/2002-04/msg00774.html and a workaround. I'm submitting this as a bug report instead of a patch because I don't know the best way to fix this issue. Can test_commands use numeric IDs instead of names? Should I discuss this issue on python-dev instead of here? BTW, please add a "Test" category to the available choices for Bugs. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 10:33 Message: Logged In: YES user_id=21627 How about the regexp pat = r'''d......... # It is a directory. \s+\d+ # It has some number of links. [^/]* # Skip user, group, size, and date. /\. # and end with the name of the file. ''' If that works, please formulate it as a patch that lists (in a comment) a few possible outputs, so that anybody who wants to tighten the regexp has test cases. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 15:41 Message: Logged In: YES user_id=86216 > I'm not sure what the purpose of getstatus is - > adding -n is a behaviour change, which should be > avoided. Agreed. AFAICT, nothing in the Python source except for test_commands.py itself is using commands.getstatus(). I verified this via: find Lib -name '*.py' | xargs fgrep getstatus Obviously, Python applications could be using commands.py. > I'm still not sure what the issue with spaces in > group names is. Can you report the output of the > ls for your system? $ ls -ld / drwxr-xr-x 15 Administ Domain U 4096 Aug 12 12:50 / $ fgrep 'Domain U' /etc/group Domain Users:S-1-5-21-136257377-364972176-1563891627-513:10513: Note that "Domain U" is the truncated version of "Domain Users". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 15:22 Message: Logged In: YES user_id=21627 I'm not sure what the purpose of getstatus is - adding -n is a behaviour change, which should be avoided. I'm still not sure what the issue with spaces in group names is. Can you report the output of the ls for your system? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 15:12 Message: Logged In: YES user_id=86216 > This patch won't work in other locales. I was afraid of this. > Why do you have to put an explicit format string > for the date in there? Because without the explicit date regular expression, I could not figure out how to match the user and group names with an arbitrary number of embedded spaces. > What specific change made the expression > "pickier"? I guess that "pickier" was a bad choice of words -- I should have used "changed" instead. The original test used "ls -ld /bin/ls" which didn't seem to (but could) trigger the failure. JT> Can test_commands use numeric IDs instead of JT> names? What about changing commands.getstatus() to use numeric IDs? Is the attached (new) patch more acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 16:14 Message: Logged In: YES user_id=21627 This patch won't work in other locales. E.g. in de_DE, a date might read Mär 21 01:14 which won't match your regexp. Furthermore, recent GNU fileutils format it as 2002-09-02 10:12 in non-C locales, which is even further away. In theory, putting LC_ALL=C into the environment should solve this, but it would be better to not rely on the date formatting. Why do you have to put an explicit format string for the date in there? What specific change made the expression "pickier"? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-08-27 20:12 Message: Logged In: YES user_id=86216 Attached is a patch to fix this problem. As suggested by Guido, I am proposing a "better" regular expression. Unfortunately, I had to make an assumption on the date format in order to match the user and group names regardless of the number of embedded spaces. Is my date regular expression acceptable? Will it work in non US locales? FWIW, I tested under Cygwin and Red Hat Linux 7.1 without any ill effects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 17:48 Message: Logged In: YES user_id=33168 Jason, I presume this is still a problem. It probably would be a good idea to discuss on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 From noreply@sourceforge.net Sun Sep 22 10:32:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 02:32:39 -0700 Subject: [Patches] [ python-Patches-413766 ] Reimplementation of multifile.py Message-ID: Patches item #413766, was opened at 2001-04-04 20:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Reimplementation of multifile.py Initial Comment: This is a re-implementation of the stock multifile.py The main changes: 1. Efficiency: This version supports calling the read() method with an argument. (In many cases, I've found that reading a MultiFile line by line is just too slow --- remember multipart messages often contain large binary attachments.) This version performs reads on the underlying input stream in larger chunks as well, and uses a regular expression search to search for separator lines. 2. Buglets fixed The original version has a buglet regarding its handling of the newline which preceeds a separator line. According to RFC 2046, section 5.1.1 the newline preceeding a separator is part of the separator, not part of the preceeding content. The old version of multifile.py treats the newline as part of the content. Thus, it introduces a spurious empty line at the end of each content. Matching of the separators: RFC 2046, section 5.1.1 also states, that if the beginning of a line matches the separator, it is a separator. The old code ignores only trailing white space when looking for a separator line. This code ignores trailing anything on the separator line. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:32 Message: Logged In: YES user_id=21627 Since there has been no action on this, I consider this irrelevant; users who want advanced email processing should use the email package; multifile is for backwards compatibilty only. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-12 06:23 Message: Logged In: YES user_id=6380 Barry, is this still relevant given the email package? ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 21:40 Message: Logged In: YES user_id=45814 I just found an obscure but occasionally fatal bug. I'm attaching a new, fixed, version of multifile.py to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-11 17:30 Message: Logged In: YES user_id=45814 Oof. I wish I had found your mimelib a couple of weeks ago. :-) You'll notice I've also posted a patch to Mailman (SF#413752) which adds an option to filter MIME attachments to plain text (delete binary attachments, convert HTML to plain text, ...) To do that (without defining new interfaces) I subclassed MimeWriter --- it's a bit messy. Using mimelib probably would have/will be cleaner. The Mailman patch includes a text/{richtext,enriched} parser (same interface as HTMLParser) which you guys might be interested in. I'm about to head off for a (long) weekend of skiing, so I won't have a chance to look carefully at mimelib until next week. Do expect to hear from me then, though. -Jeff ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-04-11 07:13 Message: Logged In: YES user_id=12800 I will definitely look at this -- and soon -- but obviously not in time for the 2.1 release. Geoffrey, have you looked at mimelib (see url below)? My intent is to replace all the MIME handling stuff in the standard library with mimelib. I'm using mimelib extensively in Mailman, but I would love to get some additional outside feedback about it. E.g. how do you think your new multifile.py would fit in with mimelib, and how well do you think mimelib conforms to RFC 2046? http://barry.wooz.org/software/pyware.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 23:31 Message: Logged In: YES user_id=6380 Thanks. I'll assign this to Barry, who has been working on another replacement for multifile, so maybe he can review your contribution. Barry, please don't sit on this too long -- If you've no interest, please unassign it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-04 20:09 Message: Logged In: YES user_id=45814 PS. FWIW, This was developed and tested under python 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 From noreply@sourceforge.net Sun Sep 22 10:33:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 02:33:07 -0700 Subject: [Patches] [ python-Patches-441528 ] MSVC Preprocessor Message-ID: Patches item #441528, was opened at 2001-07-16 00:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Tarn Weisner Burton (twburton) Assigned to: Thomas Heller (theller) Summary: MSVC Preprocessor Initial Comment: The attached script has a preprocessor method for the MSVC compiler. Tarn twburton@users.sf.net ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:33 Message: Logged In: YES user_id=21627 Rejecting it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-15 12:26 Message: Logged In: YES user_id=21627 If there is no update for this patch by September 1, it will be rejected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-11 08:32 Message: Logged In: YES user_id=21627 Tarn, are you still interested in this patch? If so, please submit a unified or context diff against the current CVS. ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-08-16 22:49 Message: Logged In: YES user_id=21784 Oops, sorry. Added test.py, i.e. run with test.py config Also the msvccompiler.py file has a print line which should probably be removed ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-08-16 22:21 Message: Logged In: YES user_id=11375 config.py doesn't actually do anything when run; it's a copy of distutils.commands.config.py. Was it intended to be a setup.py script? ---------------------------------------------------------------------- Comment By: Tarn Weisner Burton (twburton) Date: 2001-07-18 20:59 Message: Logged In: YES user_id=21784 Added test script config.py To run: "python config.py config" Also added msvccompiler.py which fixes a bug from my first post of pp.py, and is a modification of the current CVS version. Tarn ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2001-07-18 09:58 Message: Logged In: YES user_id=11105 Tarn, can you supply an example where this code would be executed? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-07-16 15:40 Message: Logged In: YES user_id=11375 Reassigning to Thomas, since I can't test anything with MSVC. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-16 15:23 Message: Logged In: YES user_id=6380 Or should this go to Thomas Heller? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=441528&group_id=5470 From noreply@sourceforge.net Sun Sep 22 10:33:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 02:33:54 -0700 Subject: [Patches] [ python-Patches-454041 ] Setup and distutils changes. Message-ID: Patches item #454041, was opened at 2001-08-22 03:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=454041&group_id=5470 Category: Distutils and setup.py Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Setup and distutils changes. Initial Comment: The attached patches change setup.py and the distutils compiler modules to allow dynamically loaded modules that are built against shared libraries to be built with the appropriate runtime library search directories set as needed. The attached patches and a description of what they do follows: 1. uw7_setup.patch This patch modifies setup.py to: * have find_library_file() search for the directory where a given library file is lo- cated, and returns a tuple '(dirs, rt_dirs)' where 'dirs' is a possibly-empty list of additional directories and 'rt_dirs' is a possibly-empty list of directories to be searched at runtime. If the file couldn't be found at all, None is returned. * use the modified find_library_file() to set the runtime_library_dirs parameter to Extension() method so that the appropriate linker option to embed the runtime library directory search path in the dynamically load module will be gener- ated. Whether or not the option is generated is controlled by the distutils compiler class. * add the curses and terminfo library to the libraries searched when the readline module is built. 2. uw7_ccompiler.patch This patch modifies Lib/distutils/ccompiler.py as follows: * The runtime_library_dir_option() method was change so that it returns an empty list instead of raising the NotImplemented exception. This was done so that a reasonable default will be used for those systems that do not need to specify a runtime search path for libraries. It is possible that setup.py will determine that a directory will be needed to be searched at runtime, even if a particular system or compiler do not support or need to have a runtime directory search patch defined. In this case, the compiler class should return an empty list when runtime_library_dir_option() is called. * Changed how runtime_library_dir_option() is called. Instead of calling it once for each directory in the runtime_library_dirs list, it is called once, passing it the entire list of directories to be searched at runtime. This pushes the decision of how to format the option to the system specific compiler class. Some systems (UnixWare, for example) only allow a single -R option to be specified, followed by a colon (:) separated list of directories to search. * Added support for a new compiler class, USLCcompiler. This compiler class supports Unix System Labs style C compilers. UnixWare uses this compiler class. Sun's native compiler for Solaris use to be based on the Unix System Lab's C compiler. I don't know if this is still the case. 3. uw7_unixccompiler.patch This patch modifies Lib/distutils/unixccompier.py so that is no longer defines it's own version of runtime_library_dir_option(). Most system's that used this compiler do not need to specify a runtime directory search path via an ld option. 4. uw7_msvccompiler.patch and uw7_mwerkscompiler.patch These patches update Lib/distutils/msvccompiler.py and Lib/distutils/mwerkscompiler.py so that being passed something in runtime_library_dirs does not raise an exception. They will now print a warning message if runtime_library_dirs is not empty or None. They will return an empty list if runtime_library_dir_option() is called. 5. uw7_uslccompiler.patch This patch adds the USLCCompiler class. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:33 Message: Logged In: YES user_id=21627 There is apparently no interest in this patch, so I'm rejecting it. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-08-23 06:46 Message: Logged In: YES user_id=8500 A new version of the setup.py patch, uw7_setup_2.patch has been uploaded. This takes info account the recent change to setup.py in regards to the bsddb module. Please use this patch in place of uw7_setup_2.patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=454041&group_id=5470 From noreply@sourceforge.net Sun Sep 22 10:36:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 02:36:24 -0700 Subject: [Patches] [ python-Patches-458383 ] Start of a bgen tutorial Message-ID: Patches item #458383, was opened at 2001-09-04 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=458383&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Jack Jansen (jackjansen) Summary: Start of a bgen tutorial Initial Comment: Jack, this is (maybe) a start of a bgen tutorial. It explains some of the things I understand now from bgen. It is not finished, also it uses windows specific examples. I'm requesting comments on the general approach. I have also sent it to you via email, but probably you have not seen it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:36 Message: Logged In: YES user_id=21627 If there is no action on this patch by Nov 1, 2002, I recommend to reject it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-14 17:02 Message: Logged In: YES user_id=45365 Thomas, I'm leaving your tutorial in the patch section for now. My reason for this is that you give a nice explanation of how bgen generates code, and how you can then build the module (nifty, that one!), but you skip the whole "front end" bit: how bgen parses your C header files, and how you add support for the various C objects to Python. And in my opinion that is the biggest stumbling block for people starting to work with bgen. I'll try and come up with a framework for a tutorial, if I have something I'll let you know so you can shine your light on it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=458383&group_id=5470 From noreply@sourceforge.net Sun Sep 22 12:34:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 04:34:36 -0700 Subject: [Patches] [ python-Patches-612602 ] "Bare" text tag_configure in Tkinter Message-ID: Patches item #612602, was opened at 2002-09-21 20:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 Category: Tkinter Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Reeves (sreeves) Assigned to: Nobody/Anonymous (nobody) >Summary: "Bare" text tag_configure in Tkinter Initial Comment: In Tcl/Tk, doing a "tag configure" operation on a text widget with only a tag name as argument returns all of the attributes configured for that tag. The analogous tag_configure method in Tkinter returns nothing. The attached patch fixes this. I'm using Python 2.1, but the same bug is in 2.2 as well. Here is a typescript showing the results of the analogous commands in Tcl/Tk and Tkinter: $ wish % text .t .t % .t tag configure someTag -foreground red % .t tag configure someTag -foreground -foreground {} {} {} red % .t tag configure someTag {-background {} {} {} {}} {-bgstipple {} {} {} {}} {-borderwidth {} {} 0 {}} {-elide {} {} 0 {}} {-fgstipple {} {} {} {}} {-font {} {} {} {}} {-foreground {} {} {} red} {-justify {} {} {} {}} {-lmargin1 {} {} {} {}} {-lmargin2 {} {} {} {}} {-offset {} {} {} {}} {-overstrike {} {} {} {}} {-relief {} {} {} {}} {-rmargin {} {} {} {}} {-spacing1 {} {} {} {}} {-spacing2 {} {} {} {}} {-spacing3 {} {} {} {}} {-tabs {} {} {} {}} {-underline {} {} {} {}} {-wrap {} {} {} {}} % ^D $ python Python 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> t = Tkinter.Text(root) >>> t.tag_configure('someTag', foreground='red') >>> t.tag_configure('someTag', 'foreground') ('foreground', '', '', '', 'red') >>> t.tag_configure('someTag') >>> ^D $ ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 13:34 Message: Logged In: YES user_id=21627 So would you like to produce a new patch in that direction? ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2002-09-21 23:38 Message: Logged In: YES user_id=2647 Oops, yeah, it should return a dictionary. Now I also see the comment in configure() about generalizing it so tag_configure() can use it too. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 22:35 Message: Logged In: YES user_id=21627 I may be missing something, but shouldn't tag_configure return a dictionary in this case? See the widget's configure for comparison. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 From noreply@sourceforge.net Sun Sep 22 16:31:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 08:31:12 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 13:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Tim Peters (tim_one) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 17:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 14:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 15:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 23 13:10:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 05:10:01 -0700 Subject: [Patches] [ python-Patches-613173 ] koi8_u codec Message-ID: Patches item #613173, was opened at 2002-09-23 15:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Maxim Dzumanenko (mdzumanenko) Assigned to: Nobody/Anonymous (nobody) Summary: koi8_u codec Initial Comment: This patch adds koi8_u codec ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613173&group_id=5470 From noreply@sourceforge.net Mon Sep 23 16:47:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 08:47:16 -0700 Subject: [Patches] [ python-Patches-613256 ] add unescape method to xml.sax.saxutils Message-ID: Patches item #613256, was opened at 2002-09-23 11:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613256&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Boedicker (mboedick) Assigned to: Nobody/Anonymous (nobody) Summary: add unescape method to xml.sax.saxutils Initial Comment: This patch adds an unescape() method to saxutils to convert an xml-escaped string back to its original form It also modifies the escape() method so that the core escaping takes places after any additional escaping passed in via the dictionary. This will guarantee that returned string is properly escaped for xml no matter what is passed in via the dictionary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613256&group_id=5470 From noreply@sourceforge.net Mon Sep 23 17:35:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 09:35:35 -0700 Subject: [Patches] [ python-Patches-597907 ] Oren Tirosh's fastnames patch Message-ID: Patches item #597907, was opened at 2002-08-20 15:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: Oren Tirosh's fastnames patch Initial Comment: Oren Tirosh had a nice patch to *really* speed up global/builtin name lookup. I'm adding it here because I don't want to lose this idea. His code and some comments are here: http://www.tothink.com/python/fastnames/ I'm uploading a new version of this patch relative to current CVS. I'm still considering whether to do this; I measure at best a 1% speedup for pystone. For a modified version of Oren's benchmark (modified to use a function instead of a class for 'builtin' and 'global', so that these tests use LOAD_GLOBAL rather than LOAD_NAME, I get these test results (best of 3): builtin 1.38 global 1.54 local 1.28 fastlocal 0.90 Python 2.3 without his patch (but with my speedup hacks in LOAD_GLOBAL): builtin 1.80 global 1.52 local 1.77 fastlocal 0.91 Python 2.2 (from the 2.2 branch, which is newer than the 2.2.1 release but doesn't have any speedups) did this: builtin 2.28 global 1.86 local 1.80 fastlocal 1.10 I don't care about the speedup for the 'local' case, since this uses the LOAD_NAME opcode which is only used inside class definitions; the 'builtin' and 'global' cases are interesting. It looks like Oren's patch gives us a nice speedup for looking up a built-in name from a function. I have to think about why looking up a global from a function is slower though... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-23 12:35 Message: Logged In: YES user_id=6380 Oren, any chance that you'll submit a new version of this? ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-03 16:22 Message: Logged In: YES user_id=562624 > I'm still considering whether to do this; I measure at > best a 1% speedup for pystone. No surprising considering the fact that pystone is dominated by fastlocals (IIRC it was something like 99.7% according to my instrumented version). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 14:29 Message: Logged In: YES user_id=6380 OK. I'm holding my breath! :-) ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2002-09-02 15:59 Message: Logged In: YES user_id=562624 I'm working on an improved version. Stay tuned! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-20 15:31 Message: Logged In: YES user_id=6380 Tim explained why the 'globals' case is faster than the 'builtins' case. I used 'x' as the global to look up rather than 'hex', and it so happens that the last three bits of hash('x') and hash('MANY') are the same -- MANY is an identifier I insert in the globals. I'll attach the test suite I used (with 'hex' instead of 'x'). Now I get these times: builtin 1.39 global 1.28 local 1.29 fastlocal 0.91 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=597907&group_id=5470 From noreply@sourceforge.net Mon Sep 23 17:56:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 09:56:23 -0700 Subject: [Patches] [ python-Patches-595111 ] turtle tracer bugfixes and new functions Message-ID: Patches item #595111, was opened at 2002-08-14 12:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=595111&group_id=5470 Category: Tkinter Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Attila Babo (ababo) Assigned to: Guido van Rossum (gvanrossum) Summary: turtle tracer bugfixes and new functions Initial Comment: Environment: Python 2.2.1 on Windows Bug fixes: There is no output without tracing, i.e. with tracer(0) the module not update the canvas. Fixed in _draw_turtle and circle. Now after tracer(0) the head turns off immediatly, all drawing functions working as required without tracer mode. A few duplicates elimineted in _goto to clean up the code. Cosmetic changes with adding and removing empty lines. New functions: heading(): returns the current heading of the pen setheading(angle): sets the heading of the pen position(): returns the current position, later you can reuse it with goto() window_width(): returns the width of the window in pixels window_height(): returns the height of the window in pixels setx(xpos): moves the pen such that its y-position remains the same but its x-position is the given value. The heading of the pen is not changed. If the pen is currently down,it will draw a line along its path. sety(ypos): moves the pen such that its x-position remains the same but its y-position is the given value. The heading of the pen is not changed. If the pen is currently down, it will draw a line along its path. With these changes the turtle module maintains better funcionality with Logo turtle graphics. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-23 12:56 Message: Logged In: YES user_id=6380 I've added the new functions to the 2.3 CVS now. Martin has already fixed the circle bug (reported in 612595). Closing this patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-20 16:40 Message: Logged In: YES user_id=6380 It's a feature that when tracing is off you don't see anything drawn -- updating the screen after each line is drawn is too expensive. If you really want this, please make it a separate flag. Regarding the new methods added: can you explain why you need these? Finally, please submit a documentation patch. If you don't know LaTeX, try to emulate what's there in Doc/lib/libturtle.tex, and we'll fix it for you, but we won't write the docs for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=595111&group_id=5470 From noreply@sourceforge.net Mon Sep 23 19:44:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 11:44:58 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 22:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 14:44 Message: Logged In: YES user_id=12800 I'm finally looking at these patches so that we can get them into cvs now. They didn't apply cleanly, but I'm not sure if I'm applying them in the way that was intended. Given that all these changes are meant to be applied to a single file (or two single files ), maybe it's best to generate a patch that contains all the changes, sync'd against what's in 2.3a0 cvs right now? Would that be hard to do? If so, then let me know and I'll try to work with what's there. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 19:08 Message: Logged In: YES user_id=357491 I really need to stop playing with this code. =) I generated another diff for _strptime.py that changes the loop in TimeRE._seqToRE to use '|'.join(). Cleaner and also alters the regex so that it doesn't explicitly use (?:) since | binds so weakly. The diff is join_diff. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 17:11 Message: Logged In: YES user_id=357491 OK, so I have uploaded a bunch of files (thanks, Neal, for deleting the old files): cleanup_diff -- cleans up __getitem__() in TimeRE. comments_diff -- adds a single comment and adds an "a" in a doc string. c_test_diff -- fixes test_strptime.py's %c, %x, and %X tests to use the magic date so as to avoid the issue that cropped up of strftime using the funky ANSI space-leading day of the month. missing_info_test_diff -- Adds a test for the lacking locale info bug. case_test_diff -- Adds tests to make sure that case-insensitivity is handled. So, for _strptime.py, the order that the patches were generated are: missing_info_diff insensitive_fix_diff cleanup_diff comments_diff For test/test_strptime.py, the order of the patches were generated are: c_test_diff missing_info_test_diff case_test_diff For all of these patches I just edited my local copy of the CVS version of the file following my altered copy as a guide. When I did a set of edits, I generated a diff. I then continued to edit that same for the next diff. Is that the right way to do it? Should I have deleted my edited copy, get the CVS version, and edited that one? Now I realize that test/test_strptime.py is not formatted very well. I am happy to fix my messy code and make all the lines break at 80 characters, but I have a question about my test patches before I do the reformatting. For the new patches I added the tests to the test methods I thought they belonged in. But I noticed after I generated the patches that Barry put his 12-hour test as a completely separate testing suite. Should I redo my patches so that the tests are separate? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 02:52 Message: Logged In: YES user_id=357491 I just re-uploaded the insensitive_fix_diff. I realized right after I posted my last comment that I didn't make sure to catch some other places where insensitive case was needed. I have fixed those and they are now contained in the diff for 2002-09-11. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 02:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 14:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 14:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 13:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 15:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 18:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 16:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 17:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 23:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 05:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 18:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 13:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 23:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Mon Sep 23 20:11:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 12:11:11 -0700 Subject: [Patches] [ python-Patches-612602 ] "Bare" text tag_configure in Tkinter Message-ID: Patches item #612602, was opened at 2002-09-21 18:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 Category: Tkinter Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Reeves (sreeves) Assigned to: Nobody/Anonymous (nobody) >Summary: "Bare" text tag_configure in Tkinter Initial Comment: In Tcl/Tk, doing a "tag configure" operation on a text widget with only a tag name as argument returns all of the attributes configured for that tag. The analogous tag_configure method in Tkinter returns nothing. The attached patch fixes this. I'm using Python 2.1, but the same bug is in 2.2 as well. Here is a typescript showing the results of the analogous commands in Tcl/Tk and Tkinter: $ wish % text .t .t % .t tag configure someTag -foreground red % .t tag configure someTag -foreground -foreground {} {} {} red % .t tag configure someTag {-background {} {} {} {}} {-bgstipple {} {} {} {}} {-borderwidth {} {} 0 {}} {-elide {} {} 0 {}} {-fgstipple {} {} {} {}} {-font {} {} {} {}} {-foreground {} {} {} red} {-justify {} {} {} {}} {-lmargin1 {} {} {} {}} {-lmargin2 {} {} {} {}} {-offset {} {} {} {}} {-overstrike {} {} {} {}} {-relief {} {} {} {}} {-rmargin {} {} {} {}} {-spacing1 {} {} {} {}} {-spacing2 {} {} {} {}} {-spacing3 {} {} {} {}} {-tabs {} {} {} {}} {-underline {} {} {} {}} {-wrap {} {} {} {}} % ^D $ python Python 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> t = Tkinter.Text(root) >>> t.tag_configure('someTag', foreground='red') >>> t.tag_configure('someTag', 'foreground') ('foreground', '', '', '', 'red') >>> t.tag_configure('someTag') >>> ^D $ ---------------------------------------------------------------------- >Comment By: Steve Reeves (sreeves) Date: 2002-09-23 19:11 Message: Logged In: YES user_id=2647 Here is a revised patch that generalizes configure() into a new internal function _configure(). This is then used by Misc.configure, Canvas.itemconfigure, Listbox.itemconfigure, Menu.entryconfigure, Text.image_configure, Text.tag_configure and Text.window_configure. BTW, the Text widget's image_configure and window_configure had the same bug as tag_configure in not returning anything for a "bare" call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:34 Message: Logged In: YES user_id=21627 So would you like to produce a new patch in that direction? ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2002-09-21 21:38 Message: Logged In: YES user_id=2647 Oops, yeah, it should return a dictionary. Now I also see the comment in configure() about generalizing it so tag_configure() can use it too. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 20:35 Message: Logged In: YES user_id=21627 I may be missing something, but shouldn't tag_configure return a dictionary in this case? See the widget's configure for comparison. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 From noreply@sourceforge.net Mon Sep 23 20:14:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 12:14:18 -0700 Subject: [Patches] [ python-Patches-612602 ] "Bare" text tag_configure in Tkinter Message-ID: Patches item #612602, was opened at 2002-09-21 18:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 Category: Tkinter Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Reeves (sreeves) Assigned to: Nobody/Anonymous (nobody) >Summary: "Bare" text tag_configure in Tkinter Initial Comment: In Tcl/Tk, doing a "tag configure" operation on a text widget with only a tag name as argument returns all of the attributes configured for that tag. The analogous tag_configure method in Tkinter returns nothing. The attached patch fixes this. I'm using Python 2.1, but the same bug is in 2.2 as well. Here is a typescript showing the results of the analogous commands in Tcl/Tk and Tkinter: $ wish % text .t .t % .t tag configure someTag -foreground red % .t tag configure someTag -foreground -foreground {} {} {} red % .t tag configure someTag {-background {} {} {} {}} {-bgstipple {} {} {} {}} {-borderwidth {} {} 0 {}} {-elide {} {} 0 {}} {-fgstipple {} {} {} {}} {-font {} {} {} {}} {-foreground {} {} {} red} {-justify {} {} {} {}} {-lmargin1 {} {} {} {}} {-lmargin2 {} {} {} {}} {-offset {} {} {} {}} {-overstrike {} {} {} {}} {-relief {} {} {} {}} {-rmargin {} {} {} {}} {-spacing1 {} {} {} {}} {-spacing2 {} {} {} {}} {-spacing3 {} {} {} {}} {-tabs {} {} {} {}} {-underline {} {} {} {}} {-wrap {} {} {} {}} % ^D $ python Python 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> t = Tkinter.Text(root) >>> t.tag_configure('someTag', foreground='red') >>> t.tag_configure('someTag', 'foreground') ('foreground', '', '', '', 'red') >>> t.tag_configure('someTag') >>> ^D $ ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2002-09-23 19:11 Message: Logged In: YES user_id=2647 Here is a revised patch that generalizes configure() into a new internal function _configure(). This is then used by Misc.configure, Canvas.itemconfigure, Listbox.itemconfigure, Menu.entryconfigure, Text.image_configure, Text.tag_configure and Text.window_configure. BTW, the Text widget's image_configure and window_configure had the same bug as tag_configure in not returning anything for a "bare" call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:34 Message: Logged In: YES user_id=21627 So would you like to produce a new patch in that direction? ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2002-09-21 21:38 Message: Logged In: YES user_id=2647 Oops, yeah, it should return a dictionary. Now I also see the comment in configure() about generalizing it so tag_configure() can use it too. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 20:35 Message: Logged In: YES user_id=21627 I may be missing something, but shouldn't tag_configure return a dictionary in this case? See the widget's configure for comparison. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 From noreply@sourceforge.net Mon Sep 23 22:01:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 14:01:22 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 19:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2002-09-23 14:01 Message: Logged In: YES user_id=357491 So I uploaded two patches today (2002-09-23). Both are just cvs diff -c diffs for _strptime.py and test_strptime.py that just take my fixed up copies and diffs with cvs. Since Barry had problems (and everyone else who has ever had to deal with patches from me has had issues), here is what I did (this is all on OS X 10.2.1 and .cvsrc containing diff -c):: cd path_to_CVS/python/dist/src/Lib cvs diff _strptime.py > ~/another_path/big_strp_diff cd test cvs diff test_strptime.py > ~/another_path/big_test_diff If there is some step there that I should not be doing (only thing I can think of is doing it in the directory) please let me know! I have no clue why my patches never apply cleanly and it is starting to really irk me. And since this answers your questions, Barry, from your last personal email I won't bother replying to it. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 11:44 Message: Logged In: YES user_id=12800 I'm finally looking at these patches so that we can get them into cvs now. They didn't apply cleanly, but I'm not sure if I'm applying them in the way that was intended. Given that all these changes are meant to be applied to a single file (or two single files ), maybe it's best to generate a patch that contains all the changes, sync'd against what's in 2.3a0 cvs right now? Would that be hard to do? If so, then let me know and I'll try to work with what's there. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 16:08 Message: Logged In: YES user_id=357491 I really need to stop playing with this code. =) I generated another diff for _strptime.py that changes the loop in TimeRE._seqToRE to use '|'.join(). Cleaner and also alters the regex so that it doesn't explicitly use (?:) since | binds so weakly. The diff is join_diff. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 14:11 Message: Logged In: YES user_id=357491 OK, so I have uploaded a bunch of files (thanks, Neal, for deleting the old files): cleanup_diff -- cleans up __getitem__() in TimeRE. comments_diff -- adds a single comment and adds an "a" in a doc string. c_test_diff -- fixes test_strptime.py's %c, %x, and %X tests to use the magic date so as to avoid the issue that cropped up of strftime using the funky ANSI space-leading day of the month. missing_info_test_diff -- Adds a test for the lacking locale info bug. case_test_diff -- Adds tests to make sure that case-insensitivity is handled. So, for _strptime.py, the order that the patches were generated are: missing_info_diff insensitive_fix_diff cleanup_diff comments_diff For test/test_strptime.py, the order of the patches were generated are: c_test_diff missing_info_test_diff case_test_diff For all of these patches I just edited my local copy of the CVS version of the file following my altered copy as a guide. When I did a set of edits, I generated a diff. I then continued to edit that same for the next diff. Is that the right way to do it? Should I have deleted my edited copy, get the CVS version, and edited that one? Now I realize that test/test_strptime.py is not formatted very well. I am happy to fix my messy code and make all the lines break at 80 characters, but I have a question about my test patches before I do the reformatting. For the new patches I added the tests to the test methods I thought they belonged in. But I noticed after I generated the patches that Barry put his 12-hour test as a completely separate testing suite. Should I redo my patches so that the tests are separate? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:52 Message: Logged In: YES user_id=357491 I just re-uploaded the insensitive_fix_diff. I realized right after I posted my last comment that I didn't make sure to catch some other places where insensitive case was needed. I have fixed those and they are now contained in the diff for 2002-09-11. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 11:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 11:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 10:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 12:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 15:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 13:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 14:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 20:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 02:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 15:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 10:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 20:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Mon Sep 23 22:21:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 14:21:36 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 22:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 17:21 Message: Logged In: YES user_id=12800 Good news Brett! The patches applied cleanly. I'll now take a look at them. Two minor comments about cvs diffing (these are my opinions and maybe not shared by everyone). First, it's easiest to create the diff from the root of the Python source tree -- i.e. the parent of Lib. That way, I can cd to the top directory and do a "patch < your-diff" and won't have to supply a file name. Second, I personally prefer unified diffs to context diffs since I (now) think they are easier to read. Yes, I used to be an anti-unified diff zealot, but I've become enlightened and now generally prefer unifieds. This is a religious issue. :) Will follow up after vetting the changes. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-23 17:01 Message: Logged In: YES user_id=357491 So I uploaded two patches today (2002-09-23). Both are just cvs diff -c diffs for _strptime.py and test_strptime.py that just take my fixed up copies and diffs with cvs. Since Barry had problems (and everyone else who has ever had to deal with patches from me has had issues), here is what I did (this is all on OS X 10.2.1 and .cvsrc containing diff -c):: cd path_to_CVS/python/dist/src/Lib cvs diff _strptime.py > ~/another_path/big_strp_diff cd test cvs diff test_strptime.py > ~/another_path/big_test_diff If there is some step there that I should not be doing (only thing I can think of is doing it in the directory) please let me know! I have no clue why my patches never apply cleanly and it is starting to really irk me. And since this answers your questions, Barry, from your last personal email I won't bother replying to it. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 14:44 Message: Logged In: YES user_id=12800 I'm finally looking at these patches so that we can get them into cvs now. They didn't apply cleanly, but I'm not sure if I'm applying them in the way that was intended. Given that all these changes are meant to be applied to a single file (or two single files ), maybe it's best to generate a patch that contains all the changes, sync'd against what's in 2.3a0 cvs right now? Would that be hard to do? If so, then let me know and I'll try to work with what's there. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 19:08 Message: Logged In: YES user_id=357491 I really need to stop playing with this code. =) I generated another diff for _strptime.py that changes the loop in TimeRE._seqToRE to use '|'.join(). Cleaner and also alters the regex so that it doesn't explicitly use (?:) since | binds so weakly. The diff is join_diff. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 17:11 Message: Logged In: YES user_id=357491 OK, so I have uploaded a bunch of files (thanks, Neal, for deleting the old files): cleanup_diff -- cleans up __getitem__() in TimeRE. comments_diff -- adds a single comment and adds an "a" in a doc string. c_test_diff -- fixes test_strptime.py's %c, %x, and %X tests to use the magic date so as to avoid the issue that cropped up of strftime using the funky ANSI space-leading day of the month. missing_info_test_diff -- Adds a test for the lacking locale info bug. case_test_diff -- Adds tests to make sure that case-insensitivity is handled. So, for _strptime.py, the order that the patches were generated are: missing_info_diff insensitive_fix_diff cleanup_diff comments_diff For test/test_strptime.py, the order of the patches were generated are: c_test_diff missing_info_test_diff case_test_diff For all of these patches I just edited my local copy of the CVS version of the file following my altered copy as a guide. When I did a set of edits, I generated a diff. I then continued to edit that same for the next diff. Is that the right way to do it? Should I have deleted my edited copy, get the CVS version, and edited that one? Now I realize that test/test_strptime.py is not formatted very well. I am happy to fix my messy code and make all the lines break at 80 characters, but I have a question about my test patches before I do the reformatting. For the new patches I added the tests to the test methods I thought they belonged in. But I noticed after I generated the patches that Barry put his 12-hour test as a completely separate testing suite. Should I redo my patches so that the tests are separate? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 02:52 Message: Logged In: YES user_id=357491 I just re-uploaded the insensitive_fix_diff. I realized right after I posted my last comment that I didn't make sure to catch some other places where insensitive case was needed. I have fixed those and they are now contained in the diff for 2002-09-11. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 02:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 14:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 14:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 13:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 15:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 18:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 16:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 17:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 23:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 05:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 18:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 13:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 23:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Mon Sep 23 22:26:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 14:26:08 -0700 Subject: [Patches] [ python-Patches-613434 ] rm email package dependency on rfc822.py Message-ID: Patches item #613434, was opened at 2002-09-23 15:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613434&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: rm email package dependency on rfc822.py Initial Comment: This allows the latest email package (2.3.1) to also work on Python 2.1 and 2.1.1 instead of only 2.1.2 and beyond. For the details behind this patch, see http://article.gmane.org/gmane.comp.python.mime.devel/102 and related followups. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613434&group_id=5470 From noreply@sourceforge.net Mon Sep 23 22:27:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 14:27:49 -0700 Subject: [Patches] [ python-Patches-613434 ] rm email package dependency on rfc822.py Message-ID: Patches item #613434, was opened at 2002-09-23 15:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613434&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: rm email package dependency on rfc822.py Initial Comment: This allows the latest email package (2.3.1) to also work on Python 2.1 and 2.1.1 instead of only 2.1.2 and beyond. For the details behind this patch, see http://article.gmane.org/gmane.comp.python.mime.devel/102 and related followups. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2002-09-23 15:27 Message: Logged In: YES user_id=85984 Also attached the necessary package-private module _parseaddr.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613434&group_id=5470 From noreply@sourceforge.net Mon Sep 23 22:28:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 14:28:23 -0700 Subject: [Patches] [ python-Patches-613434 ] rm email package dependency on rfc822.py Message-ID: Patches item #613434, was opened at 2002-09-23 15:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613434&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: rm email package dependency on rfc822.py Initial Comment: This allows the latest email package (2.3.1) to also work on Python 2.1 and 2.1.1 instead of only 2.1.2 and beyond. For the details behind this patch, see http://article.gmane.org/gmane.comp.python.mime.devel/102 and related followups. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-09-23 15:27 Message: Logged In: YES user_id=85984 Also attached the necessary package-private module _parseaddr.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613434&group_id=5470 From noreply@sourceforge.net Mon Sep 23 23:22:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 15:22:02 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 22:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 18:22 Message: Logged In: YES user_id=12800 Looks good to me. I had a couple of minor nits - long lines in _strptime.py, which I fixed but I'm not going to touch test_strptime.py) - a slightly optimization in TimeRE.__getitem__() where you only need to create the constructors dict if a KeyError got raised (no comment on the use of lambda :) - test_time.py uses a %I format with no %p and this breaks the ampm test in strptime(), because you try to None.lower(). I fixed this by using found_dict.get('p', '').lower() and equating a '' return value to AM. Test passes so I assume this is okay . I'm prepared to commit these changes and close this issue, if Brett agrees. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 17:21 Message: Logged In: YES user_id=12800 Good news Brett! The patches applied cleanly. I'll now take a look at them. Two minor comments about cvs diffing (these are my opinions and maybe not shared by everyone). First, it's easiest to create the diff from the root of the Python source tree -- i.e. the parent of Lib. That way, I can cd to the top directory and do a "patch < your-diff" and won't have to supply a file name. Second, I personally prefer unified diffs to context diffs since I (now) think they are easier to read. Yes, I used to be an anti-unified diff zealot, but I've become enlightened and now generally prefer unifieds. This is a religious issue. :) Will follow up after vetting the changes. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-23 17:01 Message: Logged In: YES user_id=357491 So I uploaded two patches today (2002-09-23). Both are just cvs diff -c diffs for _strptime.py and test_strptime.py that just take my fixed up copies and diffs with cvs. Since Barry had problems (and everyone else who has ever had to deal with patches from me has had issues), here is what I did (this is all on OS X 10.2.1 and .cvsrc containing diff -c):: cd path_to_CVS/python/dist/src/Lib cvs diff _strptime.py > ~/another_path/big_strp_diff cd test cvs diff test_strptime.py > ~/another_path/big_test_diff If there is some step there that I should not be doing (only thing I can think of is doing it in the directory) please let me know! I have no clue why my patches never apply cleanly and it is starting to really irk me. And since this answers your questions, Barry, from your last personal email I won't bother replying to it. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 14:44 Message: Logged In: YES user_id=12800 I'm finally looking at these patches so that we can get them into cvs now. They didn't apply cleanly, but I'm not sure if I'm applying them in the way that was intended. Given that all these changes are meant to be applied to a single file (or two single files ), maybe it's best to generate a patch that contains all the changes, sync'd against what's in 2.3a0 cvs right now? Would that be hard to do? If so, then let me know and I'll try to work with what's there. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 19:08 Message: Logged In: YES user_id=357491 I really need to stop playing with this code. =) I generated another diff for _strptime.py that changes the loop in TimeRE._seqToRE to use '|'.join(). Cleaner and also alters the regex so that it doesn't explicitly use (?:) since | binds so weakly. The diff is join_diff. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 17:11 Message: Logged In: YES user_id=357491 OK, so I have uploaded a bunch of files (thanks, Neal, for deleting the old files): cleanup_diff -- cleans up __getitem__() in TimeRE. comments_diff -- adds a single comment and adds an "a" in a doc string. c_test_diff -- fixes test_strptime.py's %c, %x, and %X tests to use the magic date so as to avoid the issue that cropped up of strftime using the funky ANSI space-leading day of the month. missing_info_test_diff -- Adds a test for the lacking locale info bug. case_test_diff -- Adds tests to make sure that case-insensitivity is handled. So, for _strptime.py, the order that the patches were generated are: missing_info_diff insensitive_fix_diff cleanup_diff comments_diff For test/test_strptime.py, the order of the patches were generated are: c_test_diff missing_info_test_diff case_test_diff For all of these patches I just edited my local copy of the CVS version of the file following my altered copy as a guide. When I did a set of edits, I generated a diff. I then continued to edit that same for the next diff. Is that the right way to do it? Should I have deleted my edited copy, get the CVS version, and edited that one? Now I realize that test/test_strptime.py is not formatted very well. I am happy to fix my messy code and make all the lines break at 80 characters, but I have a question about my test patches before I do the reformatting. For the new patches I added the tests to the test methods I thought they belonged in. But I noticed after I generated the patches that Barry put his 12-hour test as a completely separate testing suite. Should I redo my patches so that the tests are separate? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 02:52 Message: Logged In: YES user_id=357491 I just re-uploaded the insensitive_fix_diff. I realized right after I posted my last comment that I didn't make sure to catch some other places where insensitive case was needed. I have fixed those and they are now contained in the diff for 2002-09-11. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 02:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 14:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 14:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 13:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 15:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 18:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 16:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 17:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 23:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 05:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 18:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 13:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 23:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Mon Sep 23 23:35:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 15:35:56 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 19:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2002-09-23 15:35 Message: Logged In: YES user_id=357491 So to respond to your three points:: - Sorry about that! I thought I had caught all of the long lines and broke them. - OK. I thought the dict would be created in the opcode once and thus not be a big issue. My mind must have just slipped into compiler mode. =) And as for the lambdas, I used them just because they work. I know I could have used *args, but it looked ugly in the dict and it required another dict call. I figured lambda would be faster. If I am wrong, go ahead and change it if you care to, Barry. - Damn. Overlooked that. Thanks for catching it. And as for the correctness of the test, if the test passes then it is correct. =) Since they didn't specify AM/PM for a 12-hour time they get what they get for the hour. =) So I say go ahead and apply the patches if you are happy with them, Barry. Now, about test_strptime.py being kind of a mess in terms of long lines. I am willing to clean it up. If I do, should I start another SF patch? Or is it not worth the bother? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 15:22 Message: Logged In: YES user_id=12800 Looks good to me. I had a couple of minor nits - long lines in _strptime.py, which I fixed but I'm not going to touch test_strptime.py) - a slightly optimization in TimeRE.__getitem__() where you only need to create the constructors dict if a KeyError got raised (no comment on the use of lambda :) - test_time.py uses a %I format with no %p and this breaks the ampm test in strptime(), because you try to None.lower(). I fixed this by using found_dict.get('p', '').lower() and equating a '' return value to AM. Test passes so I assume this is okay . I'm prepared to commit these changes and close this issue, if Brett agrees. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 14:21 Message: Logged In: YES user_id=12800 Good news Brett! The patches applied cleanly. I'll now take a look at them. Two minor comments about cvs diffing (these are my opinions and maybe not shared by everyone). First, it's easiest to create the diff from the root of the Python source tree -- i.e. the parent of Lib. That way, I can cd to the top directory and do a "patch < your-diff" and won't have to supply a file name. Second, I personally prefer unified diffs to context diffs since I (now) think they are easier to read. Yes, I used to be an anti-unified diff zealot, but I've become enlightened and now generally prefer unifieds. This is a religious issue. :) Will follow up after vetting the changes. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-23 14:01 Message: Logged In: YES user_id=357491 So I uploaded two patches today (2002-09-23). Both are just cvs diff -c diffs for _strptime.py and test_strptime.py that just take my fixed up copies and diffs with cvs. Since Barry had problems (and everyone else who has ever had to deal with patches from me has had issues), here is what I did (this is all on OS X 10.2.1 and .cvsrc containing diff -c):: cd path_to_CVS/python/dist/src/Lib cvs diff _strptime.py > ~/another_path/big_strp_diff cd test cvs diff test_strptime.py > ~/another_path/big_test_diff If there is some step there that I should not be doing (only thing I can think of is doing it in the directory) please let me know! I have no clue why my patches never apply cleanly and it is starting to really irk me. And since this answers your questions, Barry, from your last personal email I won't bother replying to it. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 11:44 Message: Logged In: YES user_id=12800 I'm finally looking at these patches so that we can get them into cvs now. They didn't apply cleanly, but I'm not sure if I'm applying them in the way that was intended. Given that all these changes are meant to be applied to a single file (or two single files ), maybe it's best to generate a patch that contains all the changes, sync'd against what's in 2.3a0 cvs right now? Would that be hard to do? If so, then let me know and I'll try to work with what's there. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 16:08 Message: Logged In: YES user_id=357491 I really need to stop playing with this code. =) I generated another diff for _strptime.py that changes the loop in TimeRE._seqToRE to use '|'.join(). Cleaner and also alters the regex so that it doesn't explicitly use (?:) since | binds so weakly. The diff is join_diff. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 14:11 Message: Logged In: YES user_id=357491 OK, so I have uploaded a bunch of files (thanks, Neal, for deleting the old files): cleanup_diff -- cleans up __getitem__() in TimeRE. comments_diff -- adds a single comment and adds an "a" in a doc string. c_test_diff -- fixes test_strptime.py's %c, %x, and %X tests to use the magic date so as to avoid the issue that cropped up of strftime using the funky ANSI space-leading day of the month. missing_info_test_diff -- Adds a test for the lacking locale info bug. case_test_diff -- Adds tests to make sure that case-insensitivity is handled. So, for _strptime.py, the order that the patches were generated are: missing_info_diff insensitive_fix_diff cleanup_diff comments_diff For test/test_strptime.py, the order of the patches were generated are: c_test_diff missing_info_test_diff case_test_diff For all of these patches I just edited my local copy of the CVS version of the file following my altered copy as a guide. When I did a set of edits, I generated a diff. I then continued to edit that same for the next diff. Is that the right way to do it? Should I have deleted my edited copy, get the CVS version, and edited that one? Now I realize that test/test_strptime.py is not formatted very well. I am happy to fix my messy code and make all the lines break at 80 characters, but I have a question about my test patches before I do the reformatting. For the new patches I added the tests to the test methods I thought they belonged in. But I noticed after I generated the patches that Barry put his 12-hour test as a completely separate testing suite. Should I redo my patches so that the tests are separate? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:52 Message: Logged In: YES user_id=357491 I just re-uploaded the insensitive_fix_diff. I realized right after I posted my last comment that I didn't make sure to catch some other places where insensitive case was needed. I have fixed those and they are now contained in the diff for 2002-09-11. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-10 23:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 11:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 11:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 10:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 12:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 15:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 13:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 14:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 20:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 02:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 15:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 10:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 20:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Mon Sep 23 23:43:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 15:43:32 -0700 Subject: [Patches] [ python-Patches-593560 ] bugfixes and cleanup for _strptime.py Message-ID: Patches item #593560, was opened at 2002-08-10 22:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bugfixes and cleanup for _strptime.py Initial Comment: Discovered two bugs in _strptime.py thanks to Mikael Sch?berg of AB Strakt; both were in LocaleTime.__calc_date_time(). One was where if a locale-specific format string represented the month without a leading zero, it would not be caught. The other bug was when a locale just lacked some information (in this case, Swedish's lack of an AM/PM representation); IndexError was thrown because string.replace() was being called with the empty string as the old value. I also took this opportunity to clean up some of the code (namely TimeRE.__getitem__() along with LocaleTime.__calc_date_time()). Added some comments, reformatted some code, etc. All of this was brought on thanks to the Python Cookbook's chapter 1 (good work Alex and David!). I have updated test_strptime.py to check for the second of the mentioned bug explicitly. I also commented the code and added a fxn that creates a PyUnit test suite with all of the tests. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 18:43 Message: Logged In: YES user_id=12800 It's probably not worth the bother if you have better things to do. If you do choose to clean it up, then you can either just check it in (I forget if you have cvs write access), or upload it as a new patch and assign it to me. I'm going to commit the changes and close this issue. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-23 18:35 Message: Logged In: YES user_id=357491 So to respond to your three points:: - Sorry about that! I thought I had caught all of the long lines and broke them. - OK. I thought the dict would be created in the opcode once and thus not be a big issue. My mind must have just slipped into compiler mode. =) And as for the lambdas, I used them just because they work. I know I could have used *args, but it looked ugly in the dict and it required another dict call. I figured lambda would be faster. If I am wrong, go ahead and change it if you care to, Barry. - Damn. Overlooked that. Thanks for catching it. And as for the correctness of the test, if the test passes then it is correct. =) Since they didn't specify AM/PM for a 12-hour time they get what they get for the hour. =) So I say go ahead and apply the patches if you are happy with them, Barry. Now, about test_strptime.py being kind of a mess in terms of long lines. I am willing to clean it up. If I do, should I start another SF patch? Or is it not worth the bother? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 18:22 Message: Logged In: YES user_id=12800 Looks good to me. I had a couple of minor nits - long lines in _strptime.py, which I fixed but I'm not going to touch test_strptime.py) - a slightly optimization in TimeRE.__getitem__() where you only need to create the constructors dict if a KeyError got raised (no comment on the use of lambda :) - test_time.py uses a %I format with no %p and this breaks the ampm test in strptime(), because you try to None.lower(). I fixed this by using found_dict.get('p', '').lower() and equating a '' return value to AM. Test passes so I assume this is okay . I'm prepared to commit these changes and close this issue, if Brett agrees. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 17:21 Message: Logged In: YES user_id=12800 Good news Brett! The patches applied cleanly. I'll now take a look at them. Two minor comments about cvs diffing (these are my opinions and maybe not shared by everyone). First, it's easiest to create the diff from the root of the Python source tree -- i.e. the parent of Lib. That way, I can cd to the top directory and do a "patch < your-diff" and won't have to supply a file name. Second, I personally prefer unified diffs to context diffs since I (now) think they are easier to read. Yes, I used to be an anti-unified diff zealot, but I've become enlightened and now generally prefer unifieds. This is a religious issue. :) Will follow up after vetting the changes. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-23 17:01 Message: Logged In: YES user_id=357491 So I uploaded two patches today (2002-09-23). Both are just cvs diff -c diffs for _strptime.py and test_strptime.py that just take my fixed up copies and diffs with cvs. Since Barry had problems (and everyone else who has ever had to deal with patches from me has had issues), here is what I did (this is all on OS X 10.2.1 and .cvsrc containing diff -c):: cd path_to_CVS/python/dist/src/Lib cvs diff _strptime.py > ~/another_path/big_strp_diff cd test cvs diff test_strptime.py > ~/another_path/big_test_diff If there is some step there that I should not be doing (only thing I can think of is doing it in the directory) please let me know! I have no clue why my patches never apply cleanly and it is starting to really irk me. And since this answers your questions, Barry, from your last personal email I won't bother replying to it. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-23 14:44 Message: Logged In: YES user_id=12800 I'm finally looking at these patches so that we can get them into cvs now. They didn't apply cleanly, but I'm not sure if I'm applying them in the way that was intended. Given that all these changes are meant to be applied to a single file (or two single files ), maybe it's best to generate a patch that contains all the changes, sync'd against what's in 2.3a0 cvs right now? Would that be hard to do? If so, then let me know and I'll try to work with what's there. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 19:08 Message: Logged In: YES user_id=357491 I really need to stop playing with this code. =) I generated another diff for _strptime.py that changes the loop in TimeRE._seqToRE to use '|'.join(). Cleaner and also alters the regex so that it doesn't explicitly use (?:) since | binds so weakly. The diff is join_diff. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 17:11 Message: Logged In: YES user_id=357491 OK, so I have uploaded a bunch of files (thanks, Neal, for deleting the old files): cleanup_diff -- cleans up __getitem__() in TimeRE. comments_diff -- adds a single comment and adds an "a" in a doc string. c_test_diff -- fixes test_strptime.py's %c, %x, and %X tests to use the magic date so as to avoid the issue that cropped up of strftime using the funky ANSI space-leading day of the month. missing_info_test_diff -- Adds a test for the lacking locale info bug. case_test_diff -- Adds tests to make sure that case-insensitivity is handled. So, for _strptime.py, the order that the patches were generated are: missing_info_diff insensitive_fix_diff cleanup_diff comments_diff For test/test_strptime.py, the order of the patches were generated are: c_test_diff missing_info_test_diff case_test_diff For all of these patches I just edited my local copy of the CVS version of the file following my altered copy as a guide. When I did a set of edits, I generated a diff. I then continued to edit that same for the next diff. Is that the right way to do it? Should I have deleted my edited copy, get the CVS version, and edited that one? Now I realize that test/test_strptime.py is not formatted very well. I am happy to fix my messy code and make all the lines break at 80 characters, but I have a question about my test patches before I do the reformatting. For the new patches I added the tests to the test methods I thought they belonged in. But I noticed after I generated the patches that Barry put his 12-hour test as a completely separate testing suite. Should I redo my patches so that the tests are separate? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 02:52 Message: Logged In: YES user_id=357491 I just re-uploaded the insensitive_fix_diff. I realized right after I posted my last comment that I didn't make sure to catch some other places where insensitive case was needed. I have fixed those and they are now contained in the diff for 2002-09-11. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-11 02:40 Message: Logged In: YES user_id=357491 I uploaded diffs against the CVS version of _strptime.py to patch the two bugs reported. missing_info_diff is a cvs diff -c that fixes the bug where locale info is non-existent (the missing AM/PM stuff for Swedish problem). insensitive_fix_diff fixes the bug where matching against different cases for locale info was not deal with properly. I created missing_info_diff first, then did insensitive_fix_diff. Hopefully I didn't mess anything up. I still have to do my code cleanup diff and my doc diff. Those will be done by the end of the week (or at least I plan on doing by then). Oh, and can someone delete the old files? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-09-03 14:21 Message: Logged In: YES user_id=357491 Yes, the current diffs do not have a fix for the problem you emailed me about. They are also do not correspond to the newest CVS checkin that you did a few days back. I will make separate patches for this newest bug (I think it is just a test_strptime.py bug), the case insensitivity fix, and my code cleanup/doc string cleanup. I don't have an ETA on this, though. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-03 14:02 Message: Logged In: YES user_id=12800 Brett, I think the diff that's currently uploaded here is not your latest one, which you mention in your 2002-08-30 15:26 follow up. Can you see if you can fix the test_date_time() failure that I emailed you privately today also? To recap for others reading this report, if the day of the month < 10 (as it is today 3-Sep-2002), %d writes the day-of-month field as "03" while %c writes it as " 3" in my locale (C). I don't know whether there are any guarantees about what %c will return, so it's possible that the test is just bogus. I'm not sure what the intent of the test is, so I've asked Brett in a private message for clarification or a patch. This is assigned to me, so I'll vette Brett's patch when he uploads the newest version. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 13:52 Message: Logged In: YES user_id=6380 Assigning to Barry so he can check this in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-30 15:26 Message: Logged In: YES user_id=357491 Yeah, I noticed the email on Python-dev. His patch actually overlaps mine since I did pretty much the same stylized changes in this patch (although I didn't have the AM/PM fix; wonder why that suddenly popped up?). At least I don't have to deal with that now. Since I am going to have to do a whole new diff I will try to separate the bugfix patches from the code style/doc string benign changes. And thanks for the CVS help. Hopefully I will be able to figure it out; if not, expect an email. =) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-29 18:18 Message: Logged In: YES user_id=33168 Brett, unfortunately Barry just checked in some changes to strptime, so this is out of date. (He fixed an am/pm problem.) Could you generate new patches? Also, could you separate into separate patch files the bug fix/semantic changes from docstring changes, whitespace, etc. Typically, unrelated changes are checked in separately. To produce a diff from CVS, do: cvs diff -C 5 > patch.diff If you need CVS help, you can mail me directly. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-26 16:16 Message: Logged In: YES user_id=357491 So I was right and now have submitted a patch for PyUnit on its SF patch DB to fix the problem. And now that I fixed it I can say confidently that the changes pass the testing suite. I have attached two contextual diffs below (couldn't get cvs diff to work; still learning CVS); one diff is for _strptime.py and the other is for test/test_strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-24 17:08 Message: Logged In: YES user_id=357491 So I have a patch for both _strptime.py and test_strptime.py for Jason's bug, but I want to be able to run it through PyUnit first. For some strange reason, PyUnit will not auto-execute my tests under my Python 2.3 install (unittest.main()). Hopefully the latest CVS will deal with it. If not, I might have a patch for PyUnit. =) Either way, I will have the files up, at the latest, at the end of the month even if it means I have to execute the tests at the interpreter. Oh, and I will do a CVS diff (or diff -c) this time for the patches instead of posting the whole files. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-23 23:16 Message: Logged In: YES user_id=357491 A bug issue was brought up in patch 474274 which was the original _strptime patch. I will address it and append it to this patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-14 05:07 Message: Logged In: YES user_id=357491 Just as a follow-up, I got an email from Mikael on Mon., 2002-08-12, letting me know that the patch seems to have worked for the bug he discovered. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-11 18:16 Message: Logged In: YES user_id=357491 Sorry, Martin. I thought I remembered reading somewhere that for Python files you can just post the whole thing. I will stop doing that. As for Mikael and the patch, he says that it appears to be working. I gave it to him on Tuesday and he said it appeared to be working; he has yet to say otherwise. If you prefer, I can have him post here to verify this. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-11 13:47 Message: Logged In: YES user_id=21627 Please don't post complete files. Instead, post context (-c) or unified (-u) diffs. Ideally, produce them with "cvs diff", as this will result in patches that record the CVS version number they were for. I think it would be good to get a comment from Mikael on that patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-08-10 23:31 Message: Logged In: YES user_id=357491 Just when you thought you had something done, tim_one had to go and normalize the whitespace in both _strptime.py and test_strptime.py! =) So to save Tim the time and effort of having to normalize the files again, I went ahead and applied them to the fixed files. I also reformatted test_strptime.py so that lines wrapped around 80 characters (didn't realize Guido had added it to the distro until today). So make sure to use the files that specify whitespace normalization in their descriptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=593560&group_id=5470 From noreply@sourceforge.net Tue Sep 24 07:52:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Sep 2002 23:52:06 -0700 Subject: [Patches] [ python-Patches-613605 ] Bugfix: content-type header parsing Message-ID: Patches item #613605, was opened at 2002-09-24 08:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613605&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Funk (pefu) Assigned to: Nobody/Anonymous (nobody) Summary: Bugfix: content-type header parsing Initial Comment: webchecker.py stumbles on content-type: text/html; charset=iso8859-1 This patch should fix it. Discovery is courtesy of Maik Jablonski, who posted an initial fix on the german zope user group mailing list (zope at dzug.org). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613605&group_id=5470 From noreply@sourceforge.net Tue Sep 24 08:55:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 00:55:50 -0700 Subject: [Patches] [ python-Patches-612602 ] "Bare" text tag_configure in Tkinter Message-ID: Patches item #612602, was opened at 2002-09-21 20:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 Category: Tkinter Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Reeves (sreeves) >Assigned to: Martin v. Löwis (loewis) >Summary: "Bare" text tag_configure in Tkinter Initial Comment: In Tcl/Tk, doing a "tag configure" operation on a text widget with only a tag name as argument returns all of the attributes configured for that tag. The analogous tag_configure method in Tkinter returns nothing. The attached patch fixes this. I'm using Python 2.1, but the same bug is in 2.2 as well. Here is a typescript showing the results of the analogous commands in Tcl/Tk and Tkinter: $ wish % text .t .t % .t tag configure someTag -foreground red % .t tag configure someTag -foreground -foreground {} {} {} red % .t tag configure someTag {-background {} {} {} {}} {-bgstipple {} {} {} {}} {-borderwidth {} {} 0 {}} {-elide {} {} 0 {}} {-fgstipple {} {} {} {}} {-font {} {} {} {}} {-foreground {} {} {} red} {-justify {} {} {} {}} {-lmargin1 {} {} {} {}} {-lmargin2 {} {} {} {}} {-offset {} {} {} {}} {-overstrike {} {} {} {}} {-relief {} {} {} {}} {-rmargin {} {} {} {}} {-spacing1 {} {} {} {}} {-spacing2 {} {} {} {}} {-spacing3 {} {} {} {}} {-tabs {} {} {} {}} {-underline {} {} {} {}} {-wrap {} {} {} {}} % ^D $ python Python 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "copyright", "credits" or "license" for more information. >>> import Tkinter >>> root = Tkinter.Tk() >>> t = Tkinter.Text(root) >>> t.tag_configure('someTag', foreground='red') >>> t.tag_configure('someTag', 'foreground') ('foreground', '', '', '', 'red') >>> t.tag_configure('someTag') >>> ^D $ ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2002-09-23 21:11 Message: Logged In: YES user_id=2647 Here is a revised patch that generalizes configure() into a new internal function _configure(). This is then used by Misc.configure, Canvas.itemconfigure, Listbox.itemconfigure, Menu.entryconfigure, Text.image_configure, Text.tag_configure and Text.window_configure. BTW, the Text widget's image_configure and window_configure had the same bug as tag_configure in not returning anything for a "bare" call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 13:34 Message: Logged In: YES user_id=21627 So would you like to produce a new patch in that direction? ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2002-09-21 23:38 Message: Logged In: YES user_id=2647 Oops, yeah, it should return a dictionary. Now I also see the comment in configure() about generalizing it so tag_configure() can use it too. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 22:35 Message: Logged In: YES user_id=21627 I may be missing something, but shouldn't tag_configure return a dictionary in this case? See the widget's configure for comparison. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612602&group_id=5470 From noreply@sourceforge.net Tue Sep 24 09:10:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 01:10:38 -0700 Subject: [Patches] [ python-Patches-612627 ] Allow more Unicode on sys.stdout Message-ID: Patches item #612627, was opened at 2002-09-21 13:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Allow more Unicode on sys.stdout Initial Comment: This patch extends the set of Unicode strings that can be printed to sys.stdout, to support all strings that the terminal will likely support. It also adds an encoding attribute to sys.std{in,out}. To do that: - it adds a .encoding attribute to all file objects, which is normally None - initializes the encoding of sys.stdin and sys.stdout if either is a terminal. - adds a wrapper object around sys.stdout in site.py that encodes all Unicode objects according to the detected encoding, if that encoding is known to Python To find the encoding of the terminal, it - uses GetConsoleCP and GetConsoleOutputCP on Windows, - uses nl_langinfo(CODESET) on Unix, if available. The primary rationale for this change is that people should be able to print Unicode in an interactive session. A parallel change needs to be added for IDLE, so that it adds the .encoding attribute to the emulated stdout (it already supports printing of Unicode on stdout). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-24 01:10 Message: Logged In: NO I like the .encoding concept. I don't really like the sys.stdout wrapper. Wouldn't it be better to add the functionality to the file object .write() and .writelines() methods and then only use the wrapper in case sys.stdout is not a true file object ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 From noreply@sourceforge.net Tue Sep 24 10:02:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 02:02:04 -0700 Subject: [Patches] [ python-Patches-612627 ] Allow more Unicode on sys.stdout Message-ID: Patches item #612627, was opened at 2002-09-21 22:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Allow more Unicode on sys.stdout Initial Comment: This patch extends the set of Unicode strings that can be printed to sys.stdout, to support all strings that the terminal will likely support. It also adds an encoding attribute to sys.std{in,out}. To do that: - it adds a .encoding attribute to all file objects, which is normally None - initializes the encoding of sys.stdin and sys.stdout if either is a terminal. - adds a wrapper object around sys.stdout in site.py that encodes all Unicode objects according to the detected encoding, if that encoding is known to Python To find the encoding of the terminal, it - uses GetConsoleCP and GetConsoleOutputCP on Windows, - uses nl_langinfo(CODESET) on Unix, if available. The primary rationale for this change is that people should be able to print Unicode in an interactive session. A parallel change needs to be added for IDLE, so that it adds the .encoding attribute to the emulated stdout (it already supports printing of Unicode on stdout). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 11:02 Message: Logged In: YES user_id=21627 I have considered implementing it in the file object. However, it becomes quite involved, and heavy C code: PyFile_WriteObject calls PyObject_Print. Since Unicode does not implement a tp_print, this calls str/repr, which converts using the default encoding. It is not clear at which point the file encoding should be taking into account. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-09-24 10:10 Message: Logged In: NO I like the .encoding concept. I don't really like the sys.stdout wrapper. Wouldn't it be better to add the functionality to the file object .write() and .writelines() methods and then only use the wrapper in case sys.stdout is not a true file object ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612627&group_id=5470 From noreply@sourceforge.net Tue Sep 24 10:48:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 02:48:03 -0700 Subject: [Patches] [ python-Patches-613708 ] Add smtplib support for SMTP AUTH LOGIN Message-ID: Patches item #613708, was opened at 2002-09-24 10:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Add smtplib support for SMTP AUTH LOGIN Initial Comment: Adds support for SMTP AUTH logins using the LOGIN protocol (in addition to currently supported PLAIN and CRAM-MD5 options). This is added as a "last resort" option after the other two, so no change should be visible against servers supporting either of the two currently supported methods. This patch has been tested against a Microsoft Windows 2000 SMTP server (which supports LOGIN, but not either of the other two options). The patch also includes a small change to handle MS SMTP server (broken???) behaviour in sending a line AUTH=xxxx line in response to EHLO in addition to the standard AUTH protocol protocol ... This change simply changes the feature match regular expression to ignore feature names followed by anything other than space or end of line. Alternative approaches could involve specifically trapping repeated features, and ignoring the second and subsequent occurrences, or somehow combining the repeated occurrences. I don't believe that this adds anything over the simple approach taken in the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 From noreply@sourceforge.net Tue Sep 24 16:58:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 08:58:36 -0700 Subject: [Patches] [ python-Patches-611464 ] select problems on Windows Message-ID: Patches item #611464, was opened at 2002-09-19 03:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: select problems on Windows Initial Comment: On windows, select.select raises select.error(2, 'No such file or directory) if called with 3 empty lists. This is not caught in asyncore's loop. The attached patch fixes this by simply ignoring the exception (2 is ENOENT) in the same way as is done for EINTR already. It may be argued that it would be better to catch this exception in the select implementation on Windows itself... IMO this is also a bugfix candidate for 2.2 and 2.1. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-24 11:58 Message: Logged In: YES user_id=6380 Since we don't try to hide the differences between select on Windows and on Unix in other areas (on Windows you can only select on sockets) I'm not sure it's worth trying to fix select if you lose interruptability; fixing asyncore instead is easy enough, and I don't think this is going to bite too many other applications. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-19 15:24 Message: Logged In: YES user_id=11105 I've removed the original patch for asyncore, because it wasn't correct. After some reading and thinking, there does not seem to be an easy way to implement an interruptible select, so I consider the patch to selectmodule.c complete. And I changed the title line... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-19 13:24 Message: Logged In: YES user_id=11105 CVS works again, so here is the patch. Fixes the two problems: bogus error codes, and can be called with empty lists. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-19 11:00 Message: Logged In: YES user_id=11105 Yes, select must be fixed. There is another problem I noticed in the meantime: the error codes raised by select() on Windows are bogus, because Windows doesn't set errno, one must use WSAGetLastError(). I have patched selectmodule.c, but currently I cannot create a diff because of CVS problems. This patch class Sleep() if the lists are empty. It does not interrupt on a signal. This would require the same code than someone (Mark?) changed recently in timemodule.c, so that sleep() can be interrupted. I'm unsure what to do: Leave it uninterruptable, copy the C code over into selectmodule.c, or PyImport_Import the time module and use the sleep() function, or whatever. The function in question is timemodule.c, floatsleep(). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-19 04:09 Message: Logged In: YES user_id=21627 I would indeed argue that select should behave uniformly in this case. On Unix, it blocks until there is a timeout, or until a signal occurs. Can you come up with a patch that does the same on Windows? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 From noreply@sourceforge.net Tue Sep 24 17:16:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 09:16:07 -0700 Subject: [Patches] [ python-Patches-572031 ] AUTH method LOGIN for smtplib Message-ID: Patches item #572031, was opened at 2002-06-21 12:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Barry A. Warsaw (bwarsaw) Summary: AUTH method LOGIN for smtplib Initial Comment: Unfortunately, my original SMTP auth patch doesn't work so well in real life. There are two methods to advertise the available auth methods for SMTP servers: old-style: AUTH=method1 method2 ... RFC style: AUTH method1 method2 Microsoft's MUAs are b0rken in that they only understand the old-style method. That's why most SMTP servers are configured to advertise their authentication methods in old-style _and_ new style. There are also some especially broken SMTP servers like old M$ Exchange servers that only show their auth methods via the old style. Also the (sadly but true) very widely used M$ Exchange server only supports the LOGIN auth method (I have to use that thing at work, that's why I came up with this patch). Exchange also supports some other proprietary auth methods (NTLM, ...), but we needn't care about these. My argument is that the Python SMTP AUTH support will get a lot more useful to people if we also support 1) the old-style AUTH= advertisement 2) the LOGIN auth method, which, although not standardized via RFCs and originally invented by Netscape, is still in wide use, and for some servers the only method to use them, so we should support it Please note that in the current implementation, if a server uses the old-style AUTH= method, our SMTP auth support simply breaks because of the esmtp_features parsing. I'm randomly assigning this patch to Barry, because AFAIK he knows a lot about email handling. Assign around as you please :-) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 18:16 Message: Logged In: YES user_id=21627 There is another such patch as #613708. It would be good to make progress on this patch. Barry, what is stopping this from being integrated? ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-29 16:33 Message: Logged In: YES user_id=163326 Here's a backport for Python 2.2. I did the diff against Python 2.2.1 and hope it still applies to the maintenance line. Arguments for backporting: - missing handling of old-style advertisement is a bug because it makes SMTP auth unusable for a wide range of servers - backporting support for AUTH LOGIN is safe ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-06 08:55 Message: Logged In: YES user_id=163326 Uh-oh. I made a stupid error in the code, sending the username twice. One more lesson I learnt: never use username == password for testing :-/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 15:05 Message: Logged In: YES user_id=21627 In http://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 pierslauder reports success with this patch; see his detailed report for remaining problems. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-17 15:39 Message: Logged In: YES user_id=21627 That existing SMTP servers announce LOGIN only in the old-style header is a good reason to support those as well; I hence recommend that this patch is applied. Microsoft is, strictly speaking, conforming to the RFC by *not* reporting LOGIN in the AUTH header: only registered SASL mechanism can be announced there, and LOGIN is not registered; see http://www.iana.org/assignments/sasl-mechanisms ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-07-01 00:34 Message: Logged In: YES user_id=163326 Updated patch. Changes to the previous patch: - Use email.base64MIME.encode to get rid of the added newlines. - Merge old and RFC-style auth methods in self.smtp_features instead of parsing old-style auth lines seperately. - Removed example line for changing auth method priorities (we won't list all permutations of auth methods ;-) - Removed superfluous logging call of chosen auth method. - Moved comment about SMTP features syntax into the right place again. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-30 23:14 Message: Logged In: YES user_id=163326 Martin, the reason why we need to take into account both old and RFC-style auth advertisement is that there are some smtp servers, which advertise different auth mechanisms in the old vs. RFC-style line. In particular, the MS Exchange server that I have to use at work and I think that this is even the default configuration of Exchange 2000. In my case, it advertises its LOGIN method only in the AUTH= line. I'll shortly upload a patch that takes this into account. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 18:20 Message: Logged In: YES user_id=21627 I still cannot see why support for the old-style AUTH lines is necessary. If all SMTPds announce their supported mechanisms with both syntaxes, why is it then necessary to even look at the old syntax? I'm all for adding support for the LOGIN method. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-30 17:59 Message: Logged In: YES user_id=12800 Martin, (some? most?) MUAs post messages by talking directly to their outgoing SMTPd, so that's probably why Gerhard mentions it. On the issue of base64 issue, see the comment in bug #552605, which I just took assignment of. I'll deal with both these bug reports soon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 17:41 Message: Logged In: YES user_id=21627 I cannot understand why the behaviour of MS MUAs is relevant here at all; smtplib only talks to MTAs (or MSAs). If MTAs advertise the AUTH extension in the new syntax in addition to the old syntax, why is it not good to just ignore the old advertisement? Can you point to a specific software package (ideally even a specific host) which fails to interact with the current smtplib correctly? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-06-22 05:53 Message: Logged In: YES user_id=85984 A comment on the old-style advertisement. You say that Microsoft's MUAs only understand the old-style method. I haven't found this to be the case. tmda-ofmipd is an outgoing SMTP proxy that supports SMTP authentication, and I only use the RFC style advertisement. This works perfectly well with MS clients like Outlook 2000, and Outlook Express 5. Below is an example of what the advertisement looks like. BTW, no disagreement about supporting the old-style advertisement in smtplib, as I think it's prudent, just making a point. # telnet aguirre 8025 Trying 172.18.3.5... Connected to aguirre.la.mastaler.com. Escape character is '^]'. 220 aguirre.la.mastaler.com ESMTP tmda-ofmipd EHLO aguirre.la.mastaler.com 250-aguirre.la.mastaler.com 250 AUTH LOGIN CRAM-MD5 PLAIN QUIT 221 Bye Connection closed by foreign host. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-21 12:43 Message: Logged In: YES user_id=163326 This also includes a slightly modified version of patch #552605. Even better would IMO be to add an additional parameter to base64.encode* and the corresponding binascii functions that avoids the insertion of newline characters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470 From noreply@sourceforge.net Tue Sep 24 17:16:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 09:16:10 -0700 Subject: [Patches] [ python-Patches-613708 ] Add smtplib support for SMTP AUTH LOGIN Message-ID: Patches item #613708, was opened at 2002-09-24 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Add smtplib support for SMTP AUTH LOGIN Initial Comment: Adds support for SMTP AUTH logins using the LOGIN protocol (in addition to currently supported PLAIN and CRAM-MD5 options). This is added as a "last resort" option after the other two, so no change should be visible against servers supporting either of the two currently supported methods. This patch has been tested against a Microsoft Windows 2000 SMTP server (which supports LOGIN, but not either of the other two options). The patch also includes a small change to handle MS SMTP server (broken???) behaviour in sending a line AUTH=xxxx line in response to EHLO in addition to the standard AUTH protocol protocol ... This change simply changes the feature match regular expression to ignore feature names followed by anything other than space or end of line. Alternative approaches could involve specifically trapping repeated features, and ignoring the second and subsequent occurrences, or somehow combining the repeated occurrences. I don't believe that this adds anything over the simple approach taken in the patch. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 18:16 Message: Logged In: YES user_id=21627 This appears to be a duplicate of #572031. Can you please study #572031, and comment whether your patch has features that the other patch is lacking? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 From noreply@sourceforge.net Tue Sep 24 18:32:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 10:32:35 -0700 Subject: [Patches] [ python-Patches-611464 ] select problems on Windows Message-ID: Patches item #611464, was opened at 2002-09-19 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: select problems on Windows Initial Comment: On windows, select.select raises select.error(2, 'No such file or directory) if called with 3 empty lists. This is not caught in asyncore's loop. The attached patch fixes this by simply ignoring the exception (2 is ENOENT) in the same way as is done for EINTR already. It may be argued that it would be better to catch this exception in the select implementation on Windows itself... IMO this is also a bugfix candidate for 2.2 and 2.1. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2002-09-24 19:32 Message: Logged In: YES user_id=11105 Fixed. asyncore.py, rev 1.36 selectmodule.c, rev 1.70 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-24 17:58 Message: Logged In: YES user_id=6380 Since we don't try to hide the differences between select on Windows and on Unix in other areas (on Windows you can only select on sockets) I'm not sure it's worth trying to fix select if you lose interruptability; fixing asyncore instead is easy enough, and I don't think this is going to bite too many other applications. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-19 21:24 Message: Logged In: YES user_id=11105 I've removed the original patch for asyncore, because it wasn't correct. After some reading and thinking, there does not seem to be an easy way to implement an interruptible select, so I consider the patch to selectmodule.c complete. And I changed the title line... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-19 19:24 Message: Logged In: YES user_id=11105 CVS works again, so here is the patch. Fixes the two problems: bogus error codes, and can be called with empty lists. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-19 17:00 Message: Logged In: YES user_id=11105 Yes, select must be fixed. There is another problem I noticed in the meantime: the error codes raised by select() on Windows are bogus, because Windows doesn't set errno, one must use WSAGetLastError(). I have patched selectmodule.c, but currently I cannot create a diff because of CVS problems. This patch class Sleep() if the lists are empty. It does not interrupt on a signal. This would require the same code than someone (Mark?) changed recently in timemodule.c, so that sleep() can be interrupted. I'm unsure what to do: Leave it uninterruptable, copy the C code over into selectmodule.c, or PyImport_Import the time module and use the sleep() function, or whatever. The function in question is timemodule.c, floatsleep(). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-19 10:09 Message: Logged In: YES user_id=21627 I would indeed argue that select should behave uniformly in this case. On Unix, it blocks until there is a timeout, or until a signal occurs. Can you come up with a patch that does the same on Windows? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=611464&group_id=5470 From noreply@sourceforge.net Tue Sep 24 19:23:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 11:23:58 -0700 Subject: [Patches] [ python-Patches-613708 ] Add smtplib support for SMTP AUTH LOGIN Message-ID: Patches item #613708, was opened at 2002-09-24 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Add smtplib support for SMTP AUTH LOGIN Initial Comment: Adds support for SMTP AUTH logins using the LOGIN protocol (in addition to currently supported PLAIN and CRAM-MD5 options). This is added as a "last resort" option after the other two, so no change should be visible against servers supporting either of the two currently supported methods. This patch has been tested against a Microsoft Windows 2000 SMTP server (which supports LOGIN, but not either of the other two options). The patch also includes a small change to handle MS SMTP server (broken???) behaviour in sending a line AUTH=xxxx line in response to EHLO in addition to the standard AUTH protocol protocol ... This change simply changes the feature match regular expression to ignore feature names followed by anything other than space or end of line. Alternative approaches could involve specifically trapping repeated features, and ignoring the second and subsequent occurrences, or somehow combining the repeated occurrences. I don't believe that this adds anything over the simple approach taken in the patch. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 20:23 Message: Logged In: YES user_id=163326 This part of your code is broken: (code, resp) = self.docmd(base64.encodestring(password)[:-1]) That's what you get from copy & pasting mine *cough* ;-) For why it's wrong see this patch: http://python.org/sf/552605 which I integrated my patch Martin mentioned and for which I did a Python 2.2 backport, too. I'd also kindly ask to check it out at http://python.org/sf/572031 Tested it myself against MS Exchange, Postfix and qmail so far. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 18:16 Message: Logged In: YES user_id=21627 This appears to be a duplicate of #572031. Can you please study #572031, and comment whether your patch has features that the other patch is lacking? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 From noreply@sourceforge.net Tue Sep 24 19:36:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 11:36:02 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 15:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&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: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 20:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 15:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Tue Sep 24 19:36:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 11:36:49 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 15:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&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: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 20:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 20:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 15:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Tue Sep 24 21:54:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 13:54:35 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 06:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&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: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 13:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 11:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 11:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 06:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Tue Sep 24 22:03:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 14:03:16 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 08:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&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: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-24 16:03 Message: Logged In: YES user_id=44345 skip> The attached patch gets it to quietly look for 'less' ping> It also already does this. Not quite. In situations where no PAGER was set and less was not found, as I indicated it emitted "sh: less: not found". That was the entire reason for submitting the patch. I'm more than willing to accept that my patch was incomplete or incorrect in some way, but I was trying to address the issue of pydoc noisily informing me that 'less' was not available. S ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 15:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 13:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 13:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 08:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Tue Sep 24 22:34:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 14:34:07 -0700 Subject: [Patches] [ python-Patches-614055 ] OpenVMS patches Message-ID: Patches item #614055, was opened at 2002-09-24 23:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Piéronne Jean-François (pieronne) Assigned to: Nobody/Anonymous (nobody) Summary: OpenVMS patches Initial Comment: The attach file contains the patches of the Core files necessary to build Python for OpenVMS. All the patches used conditional compilation test on __VMS, so I may not be disruptive for the initial code. 11 files have been updated: Python/exceptions.c Python/import.c Modules/getbuildinfo.c Modules/getpatch.c Modules/main.c Modules/posixmodule.c Modules/pwdmodule.c Modules/socketmodule.c Modules/stringobject.c Modules/_hotshot.c include/pyerrors.h Jean-François ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 From noreply@sourceforge.net Wed Sep 25 05:06:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Sep 2002 21:06:25 -0700 Subject: [Patches] [ python-Patches-572031 ] AUTH method LOGIN for smtplib Message-ID: Patches item #572031, was opened at 2002-06-21 06:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Barry A. Warsaw (bwarsaw) Summary: AUTH method LOGIN for smtplib Initial Comment: Unfortunately, my original SMTP auth patch doesn't work so well in real life. There are two methods to advertise the available auth methods for SMTP servers: old-style: AUTH=method1 method2 ... RFC style: AUTH method1 method2 Microsoft's MUAs are b0rken in that they only understand the old-style method. That's why most SMTP servers are configured to advertise their authentication methods in old-style _and_ new style. There are also some especially broken SMTP servers like old M$ Exchange servers that only show their auth methods via the old style. Also the (sadly but true) very widely used M$ Exchange server only supports the LOGIN auth method (I have to use that thing at work, that's why I came up with this patch). Exchange also supports some other proprietary auth methods (NTLM, ...), but we needn't care about these. My argument is that the Python SMTP AUTH support will get a lot more useful to people if we also support 1) the old-style AUTH= advertisement 2) the LOGIN auth method, which, although not standardized via RFCs and originally invented by Netscape, is still in wide use, and for some servers the only method to use them, so we should support it Please note that in the current implementation, if a server uses the old-style AUTH= method, our SMTP auth support simply breaks because of the esmtp_features parsing. I'm randomly assigning this patch to Barry, because AFAIK he knows a lot about email handling. Assign around as you please :-) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-25 00:06 Message: Logged In: YES user_id=12800 I've simply not had time to devote to this patch. If you feel so inclined, please take it from me, otherwise I will try to find some time for it soon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 12:16 Message: Logged In: YES user_id=21627 There is another such patch as #613708. It would be good to make progress on this patch. Barry, what is stopping this from being integrated? ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-29 10:33 Message: Logged In: YES user_id=163326 Here's a backport for Python 2.2. I did the diff against Python 2.2.1 and hope it still applies to the maintenance line. Arguments for backporting: - missing handling of old-style advertisement is a bug because it makes SMTP auth unusable for a wide range of servers - backporting support for AUTH LOGIN is safe ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-06 02:55 Message: Logged In: YES user_id=163326 Uh-oh. I made a stupid error in the code, sending the username twice. One more lesson I learnt: never use username == password for testing :-/ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-24 09:05 Message: Logged In: YES user_id=21627 In http://sourceforge.net/tracker/?func=detail&atid=105470&aid=581165&group_id=5470 pierslauder reports success with this patch; see his detailed report for remaining problems. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-07-17 09:39 Message: Logged In: YES user_id=21627 That existing SMTP servers announce LOGIN only in the old-style header is a good reason to support those as well; I hence recommend that this patch is applied. Microsoft is, strictly speaking, conforming to the RFC by *not* reporting LOGIN in the AUTH header: only registered SASL mechanism can be announced there, and LOGIN is not registered; see http://www.iana.org/assignments/sasl-mechanisms ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-30 18:34 Message: Logged In: YES user_id=163326 Updated patch. Changes to the previous patch: - Use email.base64MIME.encode to get rid of the added newlines. - Merge old and RFC-style auth methods in self.smtp_features instead of parsing old-style auth lines seperately. - Removed example line for changing auth method priorities (we won't list all permutations of auth methods ;-) - Removed superfluous logging call of chosen auth method. - Moved comment about SMTP features syntax into the right place again. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-30 17:14 Message: Logged In: YES user_id=163326 Martin, the reason why we need to take into account both old and RFC-style auth advertisement is that there are some smtp servers, which advertise different auth mechanisms in the old vs. RFC-style line. In particular, the MS Exchange server that I have to use at work and I think that this is even the default configuration of Exchange 2000. In my case, it advertises its LOGIN method only in the AUTH= line. I'll shortly upload a patch that takes this into account. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 12:20 Message: Logged In: YES user_id=21627 I still cannot see why support for the old-style AUTH lines is necessary. If all SMTPds announce their supported mechanisms with both syntaxes, why is it then necessary to even look at the old syntax? I'm all for adding support for the LOGIN method. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-06-30 11:59 Message: Logged In: YES user_id=12800 Martin, (some? most?) MUAs post messages by talking directly to their outgoing SMTPd, so that's probably why Gerhard mentions it. On the issue of base64 issue, see the comment in bug #552605, which I just took assignment of. I'll deal with both these bug reports soon. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-30 11:41 Message: Logged In: YES user_id=21627 I cannot understand why the behaviour of MS MUAs is relevant here at all; smtplib only talks to MTAs (or MSAs). If MTAs advertise the AUTH extension in the new syntax in addition to the old syntax, why is it not good to just ignore the old advertisement? Can you point to a specific software package (ideally even a specific host) which fails to interact with the current smtplib correctly? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-06-21 23:53 Message: Logged In: YES user_id=85984 A comment on the old-style advertisement. You say that Microsoft's MUAs only understand the old-style method. I haven't found this to be the case. tmda-ofmipd is an outgoing SMTP proxy that supports SMTP authentication, and I only use the RFC style advertisement. This works perfectly well with MS clients like Outlook 2000, and Outlook Express 5. Below is an example of what the advertisement looks like. BTW, no disagreement about supporting the old-style advertisement in smtplib, as I think it's prudent, just making a point. # telnet aguirre 8025 Trying 172.18.3.5... Connected to aguirre.la.mastaler.com. Escape character is '^]'. 220 aguirre.la.mastaler.com ESMTP tmda-ofmipd EHLO aguirre.la.mastaler.com 250-aguirre.la.mastaler.com 250 AUTH LOGIN CRAM-MD5 PLAIN QUIT 221 Bye Connection closed by foreign host. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-06-21 06:43 Message: Logged In: YES user_id=163326 This also includes a slightly modified version of patch #552605. Even better would IMO be to add an additional parameter to base64.encode* and the corresponding binascii functions that avoids the insertion of newline characters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=572031&group_id=5470 From noreply@sourceforge.net Wed Sep 25 10:45:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 02:45:28 -0700 Subject: [Patches] [ python-Patches-613708 ] Add smtplib support for SMTP AUTH LOGIN Message-ID: Patches item #613708, was opened at 2002-09-24 10:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Add smtplib support for SMTP AUTH LOGIN Initial Comment: Adds support for SMTP AUTH logins using the LOGIN protocol (in addition to currently supported PLAIN and CRAM-MD5 options). This is added as a "last resort" option after the other two, so no change should be visible against servers supporting either of the two currently supported methods. This patch has been tested against a Microsoft Windows 2000 SMTP server (which supports LOGIN, but not either of the other two options). The patch also includes a small change to handle MS SMTP server (broken???) behaviour in sending a line AUTH=xxxx line in response to EHLO in addition to the standard AUTH protocol protocol ... This change simply changes the feature match regular expression to ignore feature names followed by anything other than space or end of line. Alternative approaches could involve specifically trapping repeated features, and ignoring the second and subsequent occurrences, or somehow combining the repeated occurrences. I don't believe that this adds anything over the simple approach taken in the patch. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2002-09-25 10:45 Message: Logged In: YES user_id=113328 Looks like http://python.org/sf/572031 is a far more thorough approach. I'm happy to close this patch in favour of that one. I've set the status to "Closed" and resolution to "duplicate". BTW, was there a way I could have found the duplicate? I didn't notice it in the browse list, and I couldn't see a "search" facility in the patch tracker... ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 19:23 Message: Logged In: YES user_id=163326 This part of your code is broken: (code, resp) = self.docmd(base64.encodestring(password)[:-1]) That's what you get from copy & pasting mine *cough* ;-) For why it's wrong see this patch: http://python.org/sf/552605 which I integrated my patch Martin mentioned and for which I did a Python 2.2 backport, too. I'd also kindly ask to check it out at http://python.org/sf/572031 Tested it myself against MS Exchange, Postfix and qmail so far. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 17:16 Message: Logged In: YES user_id=21627 This appears to be a duplicate of #572031. Can you please study #572031, and comment whether your patch has features that the other patch is lacking? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 From noreply@sourceforge.net Wed Sep 25 10:46:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 02:46:24 -0700 Subject: [Patches] [ python-Patches-613708 ] Add smtplib support for SMTP AUTH LOGIN Message-ID: Patches item #613708, was opened at 2002-09-24 10:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Add smtplib support for SMTP AUTH LOGIN Initial Comment: Adds support for SMTP AUTH logins using the LOGIN protocol (in addition to currently supported PLAIN and CRAM-MD5 options). This is added as a "last resort" option after the other two, so no change should be visible against servers supporting either of the two currently supported methods. This patch has been tested against a Microsoft Windows 2000 SMTP server (which supports LOGIN, but not either of the other two options). The patch also includes a small change to handle MS SMTP server (broken???) behaviour in sending a line AUTH=xxxx line in response to EHLO in addition to the standard AUTH protocol protocol ... This change simply changes the feature match regular expression to ignore feature names followed by anything other than space or end of line. Alternative approaches could involve specifically trapping repeated features, and ignoring the second and subsequent occurrences, or somehow combining the repeated occurrences. I don't believe that this adds anything over the simple approach taken in the patch. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2002-09-25 10:46 Message: Logged In: YES user_id=113328 Looks like http://python.org/sf/572031 is a far more thorough approach. I'm happy to close this patch in favour of that one. I've set the status to "Closed" and resolution to "duplicate". BTW, was there a way I could have found the duplicate? I didn't notice it in the browse list, and I couldn't see a "search" facility in the patch tracker... ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-09-25 10:45 Message: Logged In: YES user_id=113328 Looks like http://python.org/sf/572031 is a far more thorough approach. I'm happy to close this patch in favour of that one. I've set the status to "Closed" and resolution to "duplicate". BTW, was there a way I could have found the duplicate? I didn't notice it in the browse list, and I couldn't see a "search" facility in the patch tracker... ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 19:23 Message: Logged In: YES user_id=163326 This part of your code is broken: (code, resp) = self.docmd(base64.encodestring(password)[:-1]) That's what you get from copy & pasting mine *cough* ;-) For why it's wrong see this patch: http://python.org/sf/552605 which I integrated my patch Martin mentioned and for which I did a Python 2.2 backport, too. I'd also kindly ask to check it out at http://python.org/sf/572031 Tested it myself against MS Exchange, Postfix and qmail so far. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 17:16 Message: Logged In: YES user_id=21627 This appears to be a duplicate of #572031. Can you please study #572031, and comment whether your patch has features that the other patch is lacking? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 From noreply@sourceforge.net Wed Sep 25 13:12:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 05:12:49 -0700 Subject: [Patches] [ python-Patches-613708 ] Add smtplib support for SMTP AUTH LOGIN Message-ID: Patches item #613708, was opened at 2002-09-24 05:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Add smtplib support for SMTP AUTH LOGIN Initial Comment: Adds support for SMTP AUTH logins using the LOGIN protocol (in addition to currently supported PLAIN and CRAM-MD5 options). This is added as a "last resort" option after the other two, so no change should be visible against servers supporting either of the two currently supported methods. This patch has been tested against a Microsoft Windows 2000 SMTP server (which supports LOGIN, but not either of the other two options). The patch also includes a small change to handle MS SMTP server (broken???) behaviour in sending a line AUTH=xxxx line in response to EHLO in addition to the standard AUTH protocol protocol ... This change simply changes the feature match regular expression to ignore feature names followed by anything other than space or end of line. Alternative approaches could involve specifically trapping repeated features, and ignoring the second and subsequent occurrences, or somehow combining the repeated occurrences. I don't believe that this adds anything over the simple approach taken in the patch. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 08:12 Message: Logged In: YES user_id=33168 In the upper LEFT corner of the page, there is a search area. This area is below your login information. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-09-25 05:46 Message: Logged In: YES user_id=113328 Looks like http://python.org/sf/572031 is a far more thorough approach. I'm happy to close this patch in favour of that one. I've set the status to "Closed" and resolution to "duplicate". BTW, was there a way I could have found the duplicate? I didn't notice it in the browse list, and I couldn't see a "search" facility in the patch tracker... ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-09-25 05:45 Message: Logged In: YES user_id=113328 Looks like http://python.org/sf/572031 is a far more thorough approach. I'm happy to close this patch in favour of that one. I've set the status to "Closed" and resolution to "duplicate". BTW, was there a way I could have found the duplicate? I didn't notice it in the browse list, and I couldn't see a "search" facility in the patch tracker... ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 14:23 Message: Logged In: YES user_id=163326 This part of your code is broken: (code, resp) = self.docmd(base64.encodestring(password)[:-1]) That's what you get from copy & pasting mine *cough* ;-) For why it's wrong see this patch: http://python.org/sf/552605 which I integrated my patch Martin mentioned and for which I did a Python 2.2 backport, too. I'd also kindly ask to check it out at http://python.org/sf/572031 Tested it myself against MS Exchange, Postfix and qmail so far. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 12:16 Message: Logged In: YES user_id=21627 This appears to be a duplicate of #572031. Can you please study #572031, and comment whether your patch has features that the other patch is lacking? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 From noreply@sourceforge.net Wed Sep 25 13:15:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 05:15:17 -0700 Subject: [Patches] [ python-Patches-613708 ] Add smtplib support for SMTP AUTH LOGIN Message-ID: Patches item #613708, was opened at 2002-09-24 11:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Add smtplib support for SMTP AUTH LOGIN Initial Comment: Adds support for SMTP AUTH logins using the LOGIN protocol (in addition to currently supported PLAIN and CRAM-MD5 options). This is added as a "last resort" option after the other two, so no change should be visible against servers supporting either of the two currently supported methods. This patch has been tested against a Microsoft Windows 2000 SMTP server (which supports LOGIN, but not either of the other two options). The patch also includes a small change to handle MS SMTP server (broken???) behaviour in sending a line AUTH=xxxx line in response to EHLO in addition to the standard AUTH protocol protocol ... This change simply changes the feature match regular expression to ignore feature names followed by anything other than space or end of line. Alternative approaches could involve specifically trapping repeated features, and ignoring the second and subsequent occurrences, or somehow combining the repeated occurrences. I don't believe that this adds anything over the simple approach taken in the patch. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 14:15 Message: Logged In: YES user_id=21627 There should be a search box in the left column, which should have Patches preselected. Searching for SMTP LOGIN brings up the other patch, and a few more. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 14:12 Message: Logged In: YES user_id=33168 In the upper LEFT corner of the page, there is a search area. This area is below your login information. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-09-25 11:46 Message: Logged In: YES user_id=113328 Looks like http://python.org/sf/572031 is a far more thorough approach. I'm happy to close this patch in favour of that one. I've set the status to "Closed" and resolution to "duplicate". BTW, was there a way I could have found the duplicate? I didn't notice it in the browse list, and I couldn't see a "search" facility in the patch tracker... ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-09-25 11:45 Message: Logged In: YES user_id=113328 Looks like http://python.org/sf/572031 is a far more thorough approach. I'm happy to close this patch in favour of that one. I've set the status to "Closed" and resolution to "duplicate". BTW, was there a way I could have found the duplicate? I didn't notice it in the browse list, and I couldn't see a "search" facility in the patch tracker... ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 20:23 Message: Logged In: YES user_id=163326 This part of your code is broken: (code, resp) = self.docmd(base64.encodestring(password)[:-1]) That's what you get from copy & pasting mine *cough* ;-) For why it's wrong see this patch: http://python.org/sf/552605 which I integrated my patch Martin mentioned and for which I did a Python 2.2 backport, too. I'd also kindly ask to check it out at http://python.org/sf/572031 Tested it myself against MS Exchange, Postfix and qmail so far. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-24 18:16 Message: Logged In: YES user_id=21627 This appears to be a duplicate of #572031. Can you please study #572031, and comment whether your patch has features that the other patch is lacking? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=613708&group_id=5470 From noreply@sourceforge.net Wed Sep 25 14:02:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 06:02:10 -0700 Subject: [Patches] [ python-Patches-614055 ] OpenVMS patches Message-ID: Patches item #614055, was opened at 2002-09-24 23:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Piéronne Jean-François (pieronne) Assigned to: Nobody/Anonymous (nobody) Summary: OpenVMS patches Initial Comment: The attach file contains the patches of the Core files necessary to build Python for OpenVMS. All the patches used conditional compilation test on __VMS, so I may not be disruptive for the initial code. 11 files have been updated: Python/exceptions.c Python/import.c Modules/getbuildinfo.c Modules/getpatch.c Modules/main.c Modules/posixmodule.c Modules/pwdmodule.c Modules/socketmodule.c Modules/stringobject.c Modules/_hotshot.c include/pyerrors.h Jean-François ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 15:02 Message: Logged In: YES user_id=21627 I have a number of comments and questions: - What is the purpose of VMSerror? It appears to be unused. Can you use just OSError instead? If not, it should be VMSError. - There are various formatting problems (indentation, spaces after function names). - Is it really necessary to compute the link time? - Why do you need psxmod_gat_psxpath? Copying into psxmod_gt_psxpath appears to do the same thing? - what is the purpose of psxmod_to_vms_action? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 From noreply@sourceforge.net Wed Sep 25 15:46:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 07:46:46 -0700 Subject: [Patches] [ python-Patches-591713 ] Fix "file:" URL to have right no. of /'s Message-ID: Patches item #591713, was opened at 2002-08-06 15:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=591713&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Bruce Atherton (callenish) >Assigned to: Neal Norwitz (nnorwitz) >Summary: Fix "file:" URL to have right no. of /'s Initial Comment: If you run urlparse.urljoin() on a file: URL, the resulting URL has together with the wrong number of '/'s in it. Properly formed, the URL (assuming no netloc) should have three slashes, so that it looks like "file:///...". The current code drops that down to one. The error appears to be in a condition in urlunsplit(). It doesn't show up except in this one instance because the test is only run iff the scheme is in the list of those that can take a netloc and there is no netloc present in the URL. Apparently, this is pretty rare. Patch attached that corrects the condition. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-25 10:46 Message: Logged In: YES user_id=3066 Looks good to me; go ahead and check it in with the tests. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-17 17:22 Message: Logged In: YES user_id=33168 Not sure who is best to review this? Fred? Jeremy? Someone else? This patch works for me. I have a test too. Assign back to me if you want me to check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=591713&group_id=5470 From noreply@sourceforge.net Wed Sep 25 20:22:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 12:22:58 -0700 Subject: [Patches] [ python-Patches-591713 ] Fix "file:" URL to have right no. of /'s Message-ID: Patches item #591713, was opened at 2002-08-06 15:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=591713&group_id=5470 Category: Library (Lib) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Bruce Atherton (callenish) Assigned to: Neal Norwitz (nnorwitz) >Summary: Fix "file:" URL to have right no. of /'s Initial Comment: If you run urlparse.urljoin() on a file: URL, the resulting URL has together with the wrong number of '/'s in it. Properly formed, the URL (assuming no netloc) should have three slashes, so that it looks like "file:///...". The current code drops that down to one. The error appears to be in a condition in urlunsplit(). It doesn't show up except in this one instance because the test is only run iff the scheme is in the list of those that can take a netloc and there is no netloc present in the URL. Apparently, this is pretty rare. Patch attached that corrects the condition. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 15:22 Message: Logged In: YES user_id=33168 Checked in as: * urlparse.py 1.33 and 1.31.6.2 * test_urlparse.py 1.7 and 1.2.24.2 * output/test_urlparse 1.2.24.2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-25 10:46 Message: Logged In: YES user_id=3066 Looks good to me; go ahead and check it in with the tests. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-17 17:22 Message: Logged In: YES user_id=33168 Not sure who is best to review this? Fred? Jeremy? Someone else? This patch works for me. I have a test too. Assign back to me if you want me to check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=591713&group_id=5470 From noreply@sourceforge.net Wed Sep 25 20:38:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 12:38:51 -0700 Subject: [Patches] [ python-Patches-614587 ] configure.in patch Message-ID: Patches item #614587, was opened at 2002-09-25 12:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: configure.in patch Initial Comment: Configure fails if you are not using gcc. $GCC needs to be quoted in a couple of places. patch attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 From noreply@sourceforge.net Wed Sep 25 20:41:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 12:41:42 -0700 Subject: [Patches] [ python-Patches-614587 ] configure.in patch Message-ID: Patches item #614587, was opened at 2002-09-25 12:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: configure.in patch Initial Comment: Configure fails if you are not using gcc. $GCC needs to be quoted in a couple of places. patch attached ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2002-09-25 12:41 Message: Logged In: YES user_id=618097 Sorry, forgot to mention this patch is against the release22-maint branch pulled 25 Sep 2002 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 From noreply@sourceforge.net Wed Sep 25 20:43:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 12:43:24 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 07:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-09-25 15:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 08:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 09:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Wed Sep 25 20:58:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 12:58:29 -0700 Subject: [Patches] [ python-Patches-614596 ] fix for urllib2.AbstractBasicAuthHandler Message-ID: Patches item #614596, was opened at 2002-09-25 14:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614596&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Williams (johnw42) Assigned to: Nobody/Anonymous (nobody) Summary: fix for urllib2.AbstractBasicAuthHandler Initial Comment: This one-line patch fixes the authentication in urllib2 by making a regex case-insensitive. I don't know if this is "correct" HTTP behavior, but at last one web site (www.lexis.com) has a "Realm=" field in the www-authenticate header, causing the current version to fail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614596&group_id=5470 From noreply@sourceforge.net Wed Sep 25 21:03:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 13:03:10 -0700 Subject: [Patches] [ python-Patches-614055 ] OpenVMS patches Message-ID: Patches item #614055, was opened at 2002-09-24 23:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Piéronne Jean-François (pieronne) Assigned to: Nobody/Anonymous (nobody) Summary: OpenVMS patches Initial Comment: The attach file contains the patches of the Core files necessary to build Python for OpenVMS. All the patches used conditional compilation test on __VMS, so I may not be disruptive for the initial code. 11 files have been updated: Python/exceptions.c Python/import.c Modules/getbuildinfo.c Modules/getpatch.c Modules/main.c Modules/posixmodule.c Modules/pwdmodule.c Modules/socketmodule.c Modules/stringobject.c Modules/_hotshot.c include/pyerrors.h Jean-François ---------------------------------------------------------------------- >Comment By: Piéronne Jean-François (pieronne) Date: 2002-09-25 22:03 Message: Logged In: YES user_id=414701 Comment seem to be missing. VMSerror is used by many specifics module which I have not currently provide. I have correct the typo VMSerror --> VMSError formatting problem: Well, this is the formatting used by Uwe Zessin (and mostly generate by the editor LSE) who has done the initial port. I have not check/update his code because I did'nt know it is required, I have just found the "Style Guide for C Code". I have now update the code, only the VMS part ;-) Compute of the link time: Really necessary, sure it is not. But, IMHO, it is more useful to have the link time than the compile time of one source file. What is the problem? psxmod_gat_psxpath, psxmod_to_vms_action: You are right. During the cleaning process of the code of Uwe (I have remove some part), I have missed this optimisation and to remove the, then, unused routine psxmod_to_vms. Done, thanks. I have attach a new version: vms01.diff Tell me if you find other problem into this version. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 15:02 Message: Logged In: YES user_id=21627 I have a number of comments and questions: - What is the purpose of VMSerror? It appears to be unused. Can you use just OSError instead? If not, it should be VMSError. - There are various formatting problems (indentation, spaces after function names). - Is it really necessary to compute the link time? - Why do you need psxmod_gat_psxpath? Copying into psxmod_gt_psxpath appears to do the same thing? - what is the purpose of psxmod_to_vms_action? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614055&group_id=5470 From noreply@sourceforge.net Wed Sep 25 21:04:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 13:04:20 -0700 Subject: [Patches] [ python-Patches-614587 ] configure.in patch Message-ID: Patches item #614587, was opened at 2002-09-25 15:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: configure.in patch Initial Comment: Configure fails if you are not using gcc. $GCC needs to be quoted in a couple of places. patch attached ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 16:04 Message: Logged In: YES user_id=33168 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. :-( ) ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-25 15:41 Message: Logged In: YES user_id=618097 Sorry, forgot to mention this patch is against the release22-maint branch pulled 25 Sep 2002 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 From noreply@sourceforge.net Wed Sep 25 21:12:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 13:12:12 -0700 Subject: [Patches] [ python-Patches-614587 ] configure.in patch Message-ID: Patches item #614587, was opened at 2002-09-25 12:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: configure.in patch Initial Comment: Configure fails if you are not using gcc. $GCC needs to be quoted in a couple of places. patch attached ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2002-09-25 13:12 Message: Logged In: YES user_id=618097 Rats missed that checkbox ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 13:04 Message: Logged In: YES user_id=33168 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. :-( ) ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-25 12:41 Message: Logged In: YES user_id=618097 Sorry, forgot to mention this patch is against the release22-maint branch pulled 25 Sep 2002 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 From noreply@sourceforge.net Wed Sep 25 21:38:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 13:38:59 -0700 Subject: [Patches] [ python-Patches-614587 ] configure.in patch Message-ID: Patches item #614587, was opened at 2002-09-25 15:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tim Rice (tim1470) >Assigned to: Neal Norwitz (nnorwitz) Summary: configure.in patch Initial Comment: Configure fails if you are not using gcc. $GCC needs to be quoted in a couple of places. patch attached ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 16:38 Message: Logged In: YES user_id=33168 Actually, there's one missing on line 376 (v2.2) in the case statement. Also the case statement in CVS HEAD on line 462 has an unprotected $GCC. Checked in as: * configure.in 1.346 and 1.288.6.9 * configure 1.335 and 1.288.6.9 Thanks! ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-25 16:12 Message: Logged In: YES user_id=618097 Rats missed that checkbox ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 16:04 Message: Logged In: YES user_id=33168 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. :-( ) ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-25 15:41 Message: Logged In: YES user_id=618097 Sorry, forgot to mention this patch is against the release22-maint branch pulled 25 Sep 2002 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614587&group_id=5470 From noreply@sourceforge.net Wed Sep 25 22:22:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 14:22:28 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 09:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 17:22 Message: Logged In: YES user_id=33168 I think locateexe() will not work on MacOS 9, where os.sep == ':'. But I don't know how the path works on MacOS 9 or X. locateexe() can't work on Windows if a path component has C:\XXX. Also, the path separator on Windows is ';'. You should probably doc that locateexe doesn't work on Windows, or get it to work on Windows. Right now, there's no problem since locateexe() can't be called on windows or os2 now. I would replace if os.path.isfile() with a try/except OSError: because the file could exist, but could be a broken symlink. I think that may raise an exception now. To answer Thomas, I think people might use less under cygwin. But I'm not sure what os.platform is when python is built using cygwin. All that said, I actually like the patch. :-) So to try to make those ramblings understandable, check/change os.path.isfile(), doc/fix locateexe for windows, and check with Jack, Just, or some other mac person how this would work on a Mac. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-24 17:03 Message: Logged In: YES user_id=44345 skip> The attached patch gets it to quietly look for 'less' ping> It also already does this. Not quite. In situations where no PAGER was set and less was not found, as I indicated it emitted "sh: less: not found". That was the entire reason for submitting the patch. I'm more than willing to accept that my patch was incomplete or incorrect in some way, but I was trying to address the issue of pydoc noisily informing me that 'less' was not available. S ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 16:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 14:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 14:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 09:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Thu Sep 26 04:09:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 20:09:16 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-25 20:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Thu Sep 26 05:30:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 21:30:39 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-26 05:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 06:30 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Thu Sep 26 07:24:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 25 Sep 2002 23:24:42 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 13:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 08:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-25 21:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 17:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 14:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 15:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Thu Sep 26 08:24:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 00:24:59 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 06:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 00:24 Message: Logged In: YES user_id=45338 > I was trying to > address the issue of pydoc noisily informing me that 'less' was > not available. Right, yeah -- but the point i was trying to make is that it's not just a simple matter of "this feature is missing because the author never thought of it, so we'll just add it". There's something more subtle going on here. I tested it when i originally wrote it and i tested it again now, and it works fine if my system doesn't have 'less' (it tries 'more', and failing that it just dumps the text out straight). Looking at the code, i can't explain the behaviour you're getting. Have you figured out why you're getting an error message? About the patch, specifically: i'm generally skeptical of doing this kind of LBYL test where the test is different from the actual action needed. What we need to know is whether os.system('less') will succeed, not whether you can find a file named 'less' on the path with a particular mode. Finding the executable is the operating system's business. I'd prefer to do a test run of os.system('less') and notice whether that succeeds or fails (which is what it currently does -- but for some reason it doesn't work correctly in your setup, and should be made more robust). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 14:22 Message: Logged In: YES user_id=33168 I think locateexe() will not work on MacOS 9, where os.sep == ':'. But I don't know how the path works on MacOS 9 or X. locateexe() can't work on Windows if a path component has C:\XXX. Also, the path separator on Windows is ';'. You should probably doc that locateexe doesn't work on Windows, or get it to work on Windows. Right now, there's no problem since locateexe() can't be called on windows or os2 now. I would replace if os.path.isfile() with a try/except OSError: because the file could exist, but could be a broken symlink. I think that may raise an exception now. To answer Thomas, I think people might use less under cygwin. But I'm not sure what os.platform is when python is built using cygwin. All that said, I actually like the patch. :-) So to try to make those ramblings understandable, check/change os.path.isfile(), doc/fix locateexe for windows, and check with Jack, Just, or some other mac person how this would work on a Mac. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-24 14:03 Message: Logged In: YES user_id=44345 skip> The attached patch gets it to quietly look for 'less' ping> It also already does this. Not quite. In situations where no PAGER was set and less was not found, as I indicated it emitted "sh: less: not found". That was the entire reason for submitting the patch. I'm more than willing to accept that my patch was incomplete or incorrect in some way, but I was trying to address the issue of pydoc noisily informing me that 'less' was not available. S ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 13:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 11:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 11:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 06:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Thu Sep 26 12:54:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 04:54:15 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 08:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 06:54 Message: Logged In: YES user_id=44345 > Have you figured out why you're getting an error message? The underlying shell spits a message out somewhere other than stdout or stderr? Here's a cut-n-paste from the Solaris system in question: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('less') sh: less: not found 256 >>> os.system('less 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>&1') sh: less: not found My guess is that on Solaris 8 /bin/sh (which is a real old-fashioned Bourne shell, not bash trying to pretend it's the Bourne shell) actually spits that message out to /dev/tty instead of stderr. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 02:24 Message: Logged In: YES user_id=45338 > I was trying to > address the issue of pydoc noisily informing me that 'less' was > not available. Right, yeah -- but the point i was trying to make is that it's not just a simple matter of "this feature is missing because the author never thought of it, so we'll just add it". There's something more subtle going on here. I tested it when i originally wrote it and i tested it again now, and it works fine if my system doesn't have 'less' (it tries 'more', and failing that it just dumps the text out straight). Looking at the code, i can't explain the behaviour you're getting. Have you figured out why you're getting an error message? About the patch, specifically: i'm generally skeptical of doing this kind of LBYL test where the test is different from the actual action needed. What we need to know is whether os.system('less') will succeed, not whether you can find a file named 'less' on the path with a particular mode. Finding the executable is the operating system's business. I'd prefer to do a test run of os.system('less') and notice whether that succeeds or fails (which is what it currently does -- but for some reason it doesn't work correctly in your setup, and should be made more robust). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 16:22 Message: Logged In: YES user_id=33168 I think locateexe() will not work on MacOS 9, where os.sep == ':'. But I don't know how the path works on MacOS 9 or X. locateexe() can't work on Windows if a path component has C:\XXX. Also, the path separator on Windows is ';'. You should probably doc that locateexe doesn't work on Windows, or get it to work on Windows. Right now, there's no problem since locateexe() can't be called on windows or os2 now. I would replace if os.path.isfile() with a try/except OSError: because the file could exist, but could be a broken symlink. I think that may raise an exception now. To answer Thomas, I think people might use less under cygwin. But I'm not sure what os.platform is when python is built using cygwin. All that said, I actually like the patch. :-) So to try to make those ramblings understandable, check/change os.path.isfile(), doc/fix locateexe for windows, and check with Jack, Just, or some other mac person how this would work on a Mac. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-24 16:03 Message: Logged In: YES user_id=44345 skip> The attached patch gets it to quietly look for 'less' ping> It also already does this. Not quite. In situations where no PAGER was set and less was not found, as I indicated it emitted "sh: less: not found". That was the entire reason for submitting the patch. I'm more than willing to accept that my patch was incomplete or incorrect in some way, but I was trying to address the issue of pydoc noisily informing me that 'less' was not available. S ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 15:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 13:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 13:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 08:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Thu Sep 26 12:59:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 04:59:24 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 09:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-26 07:59 Message: Logged In: YES user_id=33168 I get the problem on linux too (chmod -x /usr/bin/less). Using parens around the string passed to system() fixes the problem for me: os.system('(less 2>/dev/null)') I don't know if this has any other subtle effects. Skip, can you test that on your system? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 07:54 Message: Logged In: YES user_id=44345 > Have you figured out why you're getting an error message? The underlying shell spits a message out somewhere other than stdout or stderr? Here's a cut-n-paste from the Solaris system in question: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('less') sh: less: not found 256 >>> os.system('less 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>&1') sh: less: not found My guess is that on Solaris 8 /bin/sh (which is a real old-fashioned Bourne shell, not bash trying to pretend it's the Bourne shell) actually spits that message out to /dev/tty instead of stderr. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 03:24 Message: Logged In: YES user_id=45338 > I was trying to > address the issue of pydoc noisily informing me that 'less' was > not available. Right, yeah -- but the point i was trying to make is that it's not just a simple matter of "this feature is missing because the author never thought of it, so we'll just add it". There's something more subtle going on here. I tested it when i originally wrote it and i tested it again now, and it works fine if my system doesn't have 'less' (it tries 'more', and failing that it just dumps the text out straight). Looking at the code, i can't explain the behaviour you're getting. Have you figured out why you're getting an error message? About the patch, specifically: i'm generally skeptical of doing this kind of LBYL test where the test is different from the actual action needed. What we need to know is whether os.system('less') will succeed, not whether you can find a file named 'less' on the path with a particular mode. Finding the executable is the operating system's business. I'd prefer to do a test run of os.system('less') and notice whether that succeeds or fails (which is what it currently does -- but for some reason it doesn't work correctly in your setup, and should be made more robust). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 17:22 Message: Logged In: YES user_id=33168 I think locateexe() will not work on MacOS 9, where os.sep == ':'. But I don't know how the path works on MacOS 9 or X. locateexe() can't work on Windows if a path component has C:\XXX. Also, the path separator on Windows is ';'. You should probably doc that locateexe doesn't work on Windows, or get it to work on Windows. Right now, there's no problem since locateexe() can't be called on windows or os2 now. I would replace if os.path.isfile() with a try/except OSError: because the file could exist, but could be a broken symlink. I think that may raise an exception now. To answer Thomas, I think people might use less under cygwin. But I'm not sure what os.platform is when python is built using cygwin. All that said, I actually like the patch. :-) So to try to make those ramblings understandable, check/change os.path.isfile(), doc/fix locateexe for windows, and check with Jack, Just, or some other mac person how this would work on a Mac. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-24 17:03 Message: Logged In: YES user_id=44345 skip> The attached patch gets it to quietly look for 'less' ping> It also already does this. Not quite. In situations where no PAGER was set and less was not found, as I indicated it emitted "sh: less: not found". That was the entire reason for submitting the patch. I'm more than willing to accept that my patch was incomplete or incorrect in some way, but I was trying to address the issue of pydoc noisily informing me that 'less' was not available. S ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 16:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 14:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 14:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 09:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Thu Sep 26 17:03:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 09:03:02 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 08:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 11:03 Message: Logged In: YES user_id=44345 No go: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system("(less 2>/dev/null)") sh: less: not found 256 >>> os.system("(less >/dev/null 2>&1)") sh: less: not found 256 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-26 06:59 Message: Logged In: YES user_id=33168 I get the problem on linux too (chmod -x /usr/bin/less). Using parens around the string passed to system() fixes the problem for me: os.system('(less 2>/dev/null)') I don't know if this has any other subtle effects. Skip, can you test that on your system? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 06:54 Message: Logged In: YES user_id=44345 > Have you figured out why you're getting an error message? The underlying shell spits a message out somewhere other than stdout or stderr? Here's a cut-n-paste from the Solaris system in question: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('less') sh: less: not found 256 >>> os.system('less 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>&1') sh: less: not found My guess is that on Solaris 8 /bin/sh (which is a real old-fashioned Bourne shell, not bash trying to pretend it's the Bourne shell) actually spits that message out to /dev/tty instead of stderr. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 02:24 Message: Logged In: YES user_id=45338 > I was trying to > address the issue of pydoc noisily informing me that 'less' was > not available. Right, yeah -- but the point i was trying to make is that it's not just a simple matter of "this feature is missing because the author never thought of it, so we'll just add it". There's something more subtle going on here. I tested it when i originally wrote it and i tested it again now, and it works fine if my system doesn't have 'less' (it tries 'more', and failing that it just dumps the text out straight). Looking at the code, i can't explain the behaviour you're getting. Have you figured out why you're getting an error message? About the patch, specifically: i'm generally skeptical of doing this kind of LBYL test where the test is different from the actual action needed. What we need to know is whether os.system('less') will succeed, not whether you can find a file named 'less' on the path with a particular mode. Finding the executable is the operating system's business. I'd prefer to do a test run of os.system('less') and notice whether that succeeds or fails (which is what it currently does -- but for some reason it doesn't work correctly in your setup, and should be made more robust). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 16:22 Message: Logged In: YES user_id=33168 I think locateexe() will not work on MacOS 9, where os.sep == ':'. But I don't know how the path works on MacOS 9 or X. locateexe() can't work on Windows if a path component has C:\XXX. Also, the path separator on Windows is ';'. You should probably doc that locateexe doesn't work on Windows, or get it to work on Windows. Right now, there's no problem since locateexe() can't be called on windows or os2 now. I would replace if os.path.isfile() with a try/except OSError: because the file could exist, but could be a broken symlink. I think that may raise an exception now. To answer Thomas, I think people might use less under cygwin. But I'm not sure what os.platform is when python is built using cygwin. All that said, I actually like the patch. :-) So to try to make those ramblings understandable, check/change os.path.isfile(), doc/fix locateexe for windows, and check with Jack, Just, or some other mac person how this would work on a Mac. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-24 16:03 Message: Logged In: YES user_id=44345 skip> The attached patch gets it to quietly look for 'less' ping> It also already does this. Not quite. In situations where no PAGER was set and less was not found, as I indicated it emitted "sh: less: not found". That was the entire reason for submitting the patch. I'm more than willing to accept that my patch was incomplete or incorrect in some way, but I was trying to address the issue of pydoc noisily informing me that 'less' was not available. S ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 15:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 13:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 13:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 08:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Thu Sep 26 18:19:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 10:19:00 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 10:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Thu Sep 26 19:26:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 11:26:20 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 19:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 20:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Thu Sep 26 20:06:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 12:06:30 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 10:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2002-09-26 12:06 Message: Logged In: YES user_id=618097 Actually it was HAVE_GETADDRINFO and HAVE_DLOPEN. To keep autoheader from complaing. You could leave that part out, but if you added another function to AC_CHECK_FUNCTS and ran autoreconf, pyconfig.h would not be updated. Why does dlopen fail? SCO is strange. I noticed if the test program was compiled without -belf it worked. That's the part of the patch I like least but iit makes python run on SCO Why -Kpic? That's what the man page says. why do the modules pwd,grp,... For some bizare reason it can't find some functions that are in libc.so Please don't modify Setup.local: this is a hand-edited file. configure creates this file if it does not exist. I chose to populate it on SCO with the entries to get a working python on SCO. If Setup.local exists, it will not be modified as was the case before the patch. Why do you remove 'unixware5' from regrtest.py? The configue.in changes make it unixware7 (which matches Lib/plat-unixware7) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 11:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Thu Sep 26 21:02:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 13:02:54 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 06:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 13:02 Message: Logged In: YES user_id=45338 I think the trick is to put parens around just 'less'. That way, 'less' is executed in a subshell, and the first shell directs the stderr of the subshell to /dev/null. Works for me on sunos5 and linux. This behaviour all makes logical sense to me now -- it can all be explained by supposing that bash directs any error messages to the stderr of the command, whereas other kinds of sh direct error messages to their own stderr. Using a subshell should make it quiet for everybody. But then didn't have to use parens to get it to be quiet in Linux (like Neal) -- so i don't know what's different about our setups. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 09:03 Message: Logged In: YES user_id=44345 No go: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system("(less 2>/dev/null)") sh: less: not found 256 >>> os.system("(less >/dev/null 2>&1)") sh: less: not found 256 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-26 04:59 Message: Logged In: YES user_id=33168 I get the problem on linux too (chmod -x /usr/bin/less). Using parens around the string passed to system() fixes the problem for me: os.system('(less 2>/dev/null)') I don't know if this has any other subtle effects. Skip, can you test that on your system? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 04:54 Message: Logged In: YES user_id=44345 > Have you figured out why you're getting an error message? The underlying shell spits a message out somewhere other than stdout or stderr? Here's a cut-n-paste from the Solaris system in question: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('less') sh: less: not found 256 >>> os.system('less 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>&1') sh: less: not found My guess is that on Solaris 8 /bin/sh (which is a real old-fashioned Bourne shell, not bash trying to pretend it's the Bourne shell) actually spits that message out to /dev/tty instead of stderr. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 00:24 Message: Logged In: YES user_id=45338 > I was trying to > address the issue of pydoc noisily informing me that 'less' was > not available. Right, yeah -- but the point i was trying to make is that it's not just a simple matter of "this feature is missing because the author never thought of it, so we'll just add it". There's something more subtle going on here. I tested it when i originally wrote it and i tested it again now, and it works fine if my system doesn't have 'less' (it tries 'more', and failing that it just dumps the text out straight). Looking at the code, i can't explain the behaviour you're getting. Have you figured out why you're getting an error message? About the patch, specifically: i'm generally skeptical of doing this kind of LBYL test where the test is different from the actual action needed. What we need to know is whether os.system('less') will succeed, not whether you can find a file named 'less' on the path with a particular mode. Finding the executable is the operating system's business. I'd prefer to do a test run of os.system('less') and notice whether that succeeds or fails (which is what it currently does -- but for some reason it doesn't work correctly in your setup, and should be made more robust). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 14:22 Message: Logged In: YES user_id=33168 I think locateexe() will not work on MacOS 9, where os.sep == ':'. But I don't know how the path works on MacOS 9 or X. locateexe() can't work on Windows if a path component has C:\XXX. Also, the path separator on Windows is ';'. You should probably doc that locateexe doesn't work on Windows, or get it to work on Windows. Right now, there's no problem since locateexe() can't be called on windows or os2 now. I would replace if os.path.isfile() with a try/except OSError: because the file could exist, but could be a broken symlink. I think that may raise an exception now. To answer Thomas, I think people might use less under cygwin. But I'm not sure what os.platform is when python is built using cygwin. All that said, I actually like the patch. :-) So to try to make those ramblings understandable, check/change os.path.isfile(), doc/fix locateexe for windows, and check with Jack, Just, or some other mac person how this would work on a Mac. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-24 14:03 Message: Logged In: YES user_id=44345 skip> The attached patch gets it to quietly look for 'less' ping> It also already does this. Not quite. In situations where no PAGER was set and less was not found, as I indicated it emitted "sh: less: not found". That was the entire reason for submitting the patch. I'm more than willing to accept that my patch was incomplete or incorrect in some way, but I was trying to address the issue of pydoc noisily informing me that 'less' was not available. S ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 13:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 11:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 11:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 06:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Thu Sep 26 21:11:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 13:11:35 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 10:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2002-09-26 13:11 Message: Logged In: YES user_id=618097 Correction on the dlopen answer. The problem is that Open Server's cc builds COFF binaries by default. dlopen only works in an ELF environment. I think I can do better on the dlopen stuff in configure.in I'm removing the patch for now. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 12:06 Message: Logged In: YES user_id=618097 Actually it was HAVE_GETADDRINFO and HAVE_DLOPEN. To keep autoheader from complaing. You could leave that part out, but if you added another function to AC_CHECK_FUNCTS and ran autoreconf, pyconfig.h would not be updated. Why does dlopen fail? SCO is strange. I noticed if the test program was compiled without -belf it worked. That's the part of the patch I like least but iit makes python run on SCO Why -Kpic? That's what the man page says. why do the modules pwd,grp,... For some bizare reason it can't find some functions that are in libc.so Please don't modify Setup.local: this is a hand-edited file. configure creates this file if it does not exist. I chose to populate it on SCO with the entries to get a working python on SCO. If Setup.local exists, it will not be modified as was the case before the patch. Why do you remove 'unixware5' from regrtest.py? The configue.in changes make it unixware7 (which matches Lib/plat-unixware7) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 11:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Thu Sep 26 22:38:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 14:38:23 -0700 Subject: [Patches] [ python-Patches-614770 ] MSVC 7.0 compiler support Message-ID: Patches item #614770, was opened at 2002-09-25 20:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 Category: Distutils and setup.py Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: John Anderson (djohnanderson) Assigned to: Nobody/Anonymous (nobody) Summary: MSVC 7.0 compiler support Initial Comment: Distutils doesn't work with the current shipping version of the Microsoft compiler (7.0). I've got a patch that fixes it (context diffs of msvccompiler.py against the latest code in CVS). ---------------------------------------------------------------------- >Comment By: John Anderson (djohnanderson) Date: 2002-09-26 14:38 Message: Logged In: YES user_id=618290 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. :-( ) ---------------------------------------------------------------------- Comment By: John Anderson (djohnanderson) Date: 2002-09-26 14:38 Message: Logged In: YES user_id=618290 Opps, I guess I forgot to check that little box. Sorry about that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-25 21:30 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: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=614770&group_id=5470 From noreply@sourceforge.net Thu Sep 26 22:47:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 14:47:34 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 08:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 16:47 Message: Logged In: YES user_id=44345 Yes, this works for me as well: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('(less) 2>/dev/null') 256 I checked in that change as pydoc.py 1.70 and am closing this item. One last question, however... Is there some reason the 'more' test just below: if hasattr(os, 'system') and os.system('more %s' % filename) == 0: has a slightly different structure? Why not 'more 2>/dev/null' or now '(more) 2>/dev/null'? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 15:02 Message: Logged In: YES user_id=45338 I think the trick is to put parens around just 'less'. That way, 'less' is executed in a subshell, and the first shell directs the stderr of the subshell to /dev/null. Works for me on sunos5 and linux. This behaviour all makes logical sense to me now -- it can all be explained by supposing that bash directs any error messages to the stderr of the command, whereas other kinds of sh direct error messages to their own stderr. Using a subshell should make it quiet for everybody. But then didn't have to use parens to get it to be quiet in Linux (like Neal) -- so i don't know what's different about our setups. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 11:03 Message: Logged In: YES user_id=44345 No go: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system("(less 2>/dev/null)") sh: less: not found 256 >>> os.system("(less >/dev/null 2>&1)") sh: less: not found 256 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-26 06:59 Message: Logged In: YES user_id=33168 I get the problem on linux too (chmod -x /usr/bin/less). Using parens around the string passed to system() fixes the problem for me: os.system('(less 2>/dev/null)') I don't know if this has any other subtle effects. Skip, can you test that on your system? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 06:54 Message: Logged In: YES user_id=44345 > Have you figured out why you're getting an error message? The underlying shell spits a message out somewhere other than stdout or stderr? Here's a cut-n-paste from the Solaris system in question: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('less') sh: less: not found 256 >>> os.system('less 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>&1') sh: less: not found My guess is that on Solaris 8 /bin/sh (which is a real old-fashioned Bourne shell, not bash trying to pretend it's the Bourne shell) actually spits that message out to /dev/tty instead of stderr. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 02:24 Message: Logged In: YES user_id=45338 > I was trying to > address the issue of pydoc noisily informing me that 'less' was > not available. Right, yeah -- but the point i was trying to make is that it's not just a simple matter of "this feature is missing because the author never thought of it, so we'll just add it". There's something more subtle going on here. I tested it when i originally wrote it and i tested it again now, and it works fine if my system doesn't have 'less' (it tries 'more', and failing that it just dumps the text out straight). Looking at the code, i can't explain the behaviour you're getting. Have you figured out why you're getting an error message? About the patch, specifically: i'm generally skeptical of doing this kind of LBYL test where the test is different from the actual action needed. What we need to know is whether os.system('less') will succeed, not whether you can find a file named 'less' on the path with a particular mode. Finding the executable is the operating system's business. I'd prefer to do a test run of os.system('less') and notice whether that succeeds or fails (which is what it currently does -- but for some reason it doesn't work correctly in your setup, and should be made more robust). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 16:22 Message: Logged In: YES user_id=33168 I think locateexe() will not work on MacOS 9, where os.sep == ':'. But I don't know how the path works on MacOS 9 or X. locateexe() can't work on Windows if a path component has C:\XXX. Also, the path separator on Windows is ';'. You should probably doc that locateexe doesn't work on Windows, or get it to work on Windows. Right now, there's no problem since locateexe() can't be called on windows or os2 now. I would replace if os.path.isfile() with a try/except OSError: because the file could exist, but could be a broken symlink. I think that may raise an exception now. To answer Thomas, I think people might use less under cygwin. But I'm not sure what os.platform is when python is built using cygwin. All that said, I actually like the patch. :-) So to try to make those ramblings understandable, check/change os.path.isfile(), doc/fix locateexe for windows, and check with Jack, Just, or some other mac person how this would work on a Mac. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-24 16:03 Message: Logged In: YES user_id=44345 skip> The attached patch gets it to quietly look for 'less' ping> It also already does this. Not quite. In situations where no PAGER was set and less was not found, as I indicated it emitted "sh: less: not found". That was the entire reason for submitting the patch. I'm more than willing to accept that my patch was incomplete or incorrect in some way, but I was trying to address the issue of pydoc noisily informing me that 'less' was not available. S ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 15:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 13:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 13:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 08:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Thu Sep 26 22:53:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 14:53:20 -0700 Subject: [Patches] [ python-Patches-612111 ] quietly select between 'less' and 'more' Message-ID: Patches item #612111, was opened at 2002-09-20 09:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: quietly select between 'less' and 'more' Initial Comment: On Unixoid systems without the 'less' command, executing 'pydoc.help(mod)' emits: sh: less: not found which is annoying. The attached patch gets it to quietly look for 'less' and 'more'. I don't know if the locateexe() function is entirely correct (especially considering Windows) or if there are other pagers available. backport candidate? I know this behavior exists in 2.1.3 and 2.2.1. Dunno if it's more than a wart though. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-26 17:53 Message: Logged In: YES user_id=33168 I tested more carefully on Linux and using parens works either around just less or everything. The problem was I didn't restart python between runs, I used reload(). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 17:47 Message: Logged In: YES user_id=44345 Yes, this works for me as well: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('(less) 2>/dev/null') 256 I checked in that change as pydoc.py 1.70 and am closing this item. One last question, however... Is there some reason the 'more' test just below: if hasattr(os, 'system') and os.system('more %s' % filename) == 0: has a slightly different structure? Why not 'more 2>/dev/null' or now '(more) 2>/dev/null'? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 16:02 Message: Logged In: YES user_id=45338 I think the trick is to put parens around just 'less'. That way, 'less' is executed in a subshell, and the first shell directs the stderr of the subshell to /dev/null. Works for me on sunos5 and linux. This behaviour all makes logical sense to me now -- it can all be explained by supposing that bash directs any error messages to the stderr of the command, whereas other kinds of sh direct error messages to their own stderr. Using a subshell should make it quiet for everybody. But then didn't have to use parens to get it to be quiet in Linux (like Neal) -- so i don't know what's different about our setups. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 12:03 Message: Logged In: YES user_id=44345 No go: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system("(less 2>/dev/null)") sh: less: not found 256 >>> os.system("(less >/dev/null 2>&1)") sh: less: not found 256 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-26 07:59 Message: Logged In: YES user_id=33168 I get the problem on linux too (chmod -x /usr/bin/less). Using parens around the string passed to system() fixes the problem for me: os.system('(less 2>/dev/null)') I don't know if this has any other subtle effects. Skip, can you test that on your system? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-26 07:54 Message: Logged In: YES user_id=44345 > Have you figured out why you're getting an error message? The underlying shell spits a message out somewhere other than stdout or stderr? Here's a cut-n-paste from the Solaris system in question: $ python Python 2.2.1 (#2, Sep 9 2002, 17:22:35) [C] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system('less') sh: less: not found 256 >>> os.system('less 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>/dev/null') sh: less: not found 256 >>> os.system('less >/dev/null 2>&1') sh: less: not found My guess is that on Solaris 8 /bin/sh (which is a real old-fashioned Bourne shell, not bash trying to pretend it's the Bourne shell) actually spits that message out to /dev/tty instead of stderr. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-26 03:24 Message: Logged In: YES user_id=45338 > I was trying to > address the issue of pydoc noisily informing me that 'less' was > not available. Right, yeah -- but the point i was trying to make is that it's not just a simple matter of "this feature is missing because the author never thought of it, so we'll just add it". There's something more subtle going on here. I tested it when i originally wrote it and i tested it again now, and it works fine if my system doesn't have 'less' (it tries 'more', and failing that it just dumps the text out straight). Looking at the code, i can't explain the behaviour you're getting. Have you figured out why you're getting an error message? About the patch, specifically: i'm generally skeptical of doing this kind of LBYL test where the test is different from the actual action needed. What we need to know is whether os.system('less') will succeed, not whether you can find a file named 'less' on the path with a particular mode. Finding the executable is the operating system's business. I'd prefer to do a test run of os.system('less') and notice whether that succeeds or fails (which is what it currently does -- but for some reason it doesn't work correctly in your setup, and should be made more robust). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-25 17:22 Message: Logged In: YES user_id=33168 I think locateexe() will not work on MacOS 9, where os.sep == ':'. But I don't know how the path works on MacOS 9 or X. locateexe() can't work on Windows if a path component has C:\XXX. Also, the path separator on Windows is ';'. You should probably doc that locateexe doesn't work on Windows, or get it to work on Windows. Right now, there's no problem since locateexe() can't be called on windows or os2 now. I would replace if os.path.isfile() with a try/except OSError: because the file could exist, but could be a broken symlink. I think that may raise an exception now. To answer Thomas, I think people might use less under cygwin. But I'm not sure what os.platform is when python is built using cygwin. All that said, I actually like the patch. :-) So to try to make those ramblings understandable, check/change os.path.isfile(), doc/fix locateexe for windows, and check with Jack, Just, or some other mac person how this would work on a Mac. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-09-24 17:03 Message: Logged In: YES user_id=44345 skip> The attached patch gets it to quietly look for 'less' ping> It also already does this. Not quite. In situations where no PAGER was set and less was not found, as I indicated it emitted "sh: less: not found". That was the entire reason for submitting the patch. I'm more than willing to accept that my patch was incomplete or incorrect in some way, but I was trying to address the issue of pydoc noisily informing me that 'less' was not available. S ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2002-09-24 16:54 Message: Logged In: YES user_id=45338 > It should also honour the PAGER environment variable It already does this. Read the code. > I would suggest simply call more on Windows. It already does this. Read the code. > The attached patch gets it to quietly look for 'less' It also already does this. If it's not working for you, there must be a bug. Look at the code -- all of this behaviour is right there in getpager() and has been there ever since pydoc was first written. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 14:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-09-24 14:36 Message: Logged In: YES user_id=163326 It should also honour the PAGER environment variable, and use it if available. I'm trying to be puristic for a minute: we probably shouldn't support any nonstandard pagers like less, view, most, etc. at all. That's what Unix has the PAGER environment variable for, just like the EDITOR and VISUAL ones. I'm certainly no puristic Unix user, but we already have zillions of patches for the webbrowser module to support the various Unix Web Browsers out there. We should avoid to get into the same situation with pydoc. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2002-09-20 09:54 Message: Logged In: YES user_id=11105 locateexe does not work on Windows (for several reasons). Dunno if people install other pagers - I certainly don't. And when they do, are they really named 'less'? OTOH, more is in the PATH on every windows system, so I would suggest simply call more on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=612111&group_id=5470 From noreply@sourceforge.net Fri Sep 27 04:29:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 20:29:51 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 10:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2002-09-26 20:29 Message: Logged In: YES user_id=618097 Here is a new patch that does a more correct job of working around SCO's wierdness. I've also added support for gcc on Open Server 5 If you have questions, fee free to email tim@multitalents.net ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 13:11 Message: Logged In: YES user_id=618097 Correction on the dlopen answer. The problem is that Open Server's cc builds COFF binaries by default. dlopen only works in an ELF environment. I think I can do better on the dlopen stuff in configure.in I'm removing the patch for now. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 12:06 Message: Logged In: YES user_id=618097 Actually it was HAVE_GETADDRINFO and HAVE_DLOPEN. To keep autoheader from complaing. You could leave that part out, but if you added another function to AC_CHECK_FUNCTS and ran autoreconf, pyconfig.h would not be updated. Why does dlopen fail? SCO is strange. I noticed if the test program was compiled without -belf it worked. That's the part of the patch I like least but iit makes python run on SCO Why -Kpic? That's what the man page says. why do the modules pwd,grp,... For some bizare reason it can't find some functions that are in libc.so Please don't modify Setup.local: this is a hand-edited file. configure creates this file if it does not exist. I chose to populate it on SCO with the entries to get a working python on SCO. If Setup.local exists, it will not be modified as was the case before the patch. Why do you remove 'unixware5' from regrtest.py? The configue.in changes make it unixware7 (which matches Lib/plat-unixware7) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 11:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Fri Sep 27 04:37:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 20:37:47 -0700 Subject: [Patches] [ python-Patches-615343 ] acconfig.h out of date Message-ID: Patches item #615343, was opened at 2002-09-26 20:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615343&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: acconfig.h out of date Initial Comment: acconfig.h is out of date. It looks like someone added AC_DEFINE(HAVE_GETADDRINFO) to configure.in without updating acconfig.h autoheader coomplains and then will not update pyconfig.h.in /usr/bin/autoheader: Symbol `HAVE_GETADDRINFO' is not covered by /usr/share/autoconf/acconfig.h ./acconfig.h patch attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615343&group_id=5470 From noreply@sourceforge.net Fri Sep 27 05:21:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 21:21:16 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 10:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2002-09-26 21:21 Message: Logged In: YES user_id=618097 Here is a patch for HEAD that will get things closer to working on SCO ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 20:29 Message: Logged In: YES user_id=618097 Here is a new patch that does a more correct job of working around SCO's wierdness. I've also added support for gcc on Open Server 5 If you have questions, fee free to email tim@multitalents.net ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 13:11 Message: Logged In: YES user_id=618097 Correction on the dlopen answer. The problem is that Open Server's cc builds COFF binaries by default. dlopen only works in an ELF environment. I think I can do better on the dlopen stuff in configure.in I'm removing the patch for now. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 12:06 Message: Logged In: YES user_id=618097 Actually it was HAVE_GETADDRINFO and HAVE_DLOPEN. To keep autoheader from complaing. You could leave that part out, but if you added another function to AC_CHECK_FUNCTS and ran autoreconf, pyconfig.h would not be updated. Why does dlopen fail? SCO is strange. I noticed if the test program was compiled without -belf it worked. That's the part of the patch I like least but iit makes python run on SCO Why -Kpic? That's what the man page says. why do the modules pwd,grp,... For some bizare reason it can't find some functions that are in libc.so Please don't modify Setup.local: this is a hand-edited file. configure creates this file if it does not exist. I chose to populate it on SCO with the entries to get a working python on SCO. If Setup.local exists, it will not be modified as was the case before the patch. Why do you remove 'unixware5' from regrtest.py? The configue.in changes make it unixware7 (which matches Lib/plat-unixware7) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 11:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Fri Sep 27 05:24:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 21:24:33 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 10:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build >Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2002-09-26 21:24 Message: Logged In: YES user_id=618097 Maybe I should have done a seperate one for HEAD I don't know. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 21:21 Message: Logged In: YES user_id=618097 Here is a patch for HEAD that will get things closer to working on SCO ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 20:29 Message: Logged In: YES user_id=618097 Here is a new patch that does a more correct job of working around SCO's wierdness. I've also added support for gcc on Open Server 5 If you have questions, fee free to email tim@multitalents.net ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 13:11 Message: Logged In: YES user_id=618097 Correction on the dlopen answer. The problem is that Open Server's cc builds COFF binaries by default. dlopen only works in an ELF environment. I think I can do better on the dlopen stuff in configure.in I'm removing the patch for now. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 12:06 Message: Logged In: YES user_id=618097 Actually it was HAVE_GETADDRINFO and HAVE_DLOPEN. To keep autoheader from complaing. You could leave that part out, but if you added another function to AC_CHECK_FUNCTS and ran autoreconf, pyconfig.h would not be updated. Why does dlopen fail? SCO is strange. I noticed if the test program was compiled without -belf it worked. That's the part of the patch I like least but iit makes python run on SCO Why -Kpic? That's what the man page says. why do the modules pwd,grp,... For some bizare reason it can't find some functions that are in libc.so Please don't modify Setup.local: this is a hand-edited file. configure creates this file if it does not exist. I chose to populate it on SCO with the entries to get a working python on SCO. If Setup.local exists, it will not be modified as was the case before the patch. Why do you remove 'unixware5' from regrtest.py? The configue.in changes make it unixware7 (which matches Lib/plat-unixware7) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 11:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Fri Sep 27 15:26:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Sep 2002 07:26:05 -0700 Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter Message-ID: Patches item #505846, was opened at 2002-01-19 20:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: pyport.h, Wince and errno getter/setter Initial Comment: Most of the remaining Windows CE diffs are due to the lack of errno on Windows CE. There are other OS's that do not have errno (but they have a workalike method). At first I had simply commented out all references in the code to errno, but that quickly became unworkable. Wince and NetWare use a function to set the per- thread "errno" value. Although errno #defines (like ERANGE) are not defined for Wince, they are defined for NetWare. Removing references to errno would artificially hobble the NetWare port. These platforms also use a function to retrieve the current errno value. The attached diff for pyport.h attempts to standardize the access method for errno (or it's work-alike) by providing SetErrno(), ClearErrno() and GetErrno() macros. ClearErrno() is SetErrno(0) I've found and changed all direct references to errno to use these macros. This patch must be submitted before the patches for other modules. -- I see two negatives with this approach: 1. It will be a pain to think GetErrno() instead of "errno" when modifying/writing new code. 2. Extension modules will need access to pyport.h for the target platform. In the worst case, directly referencing errno instead of using the macros will break only those platforms for which the macros do something different. That is, Wince and NetWare. -- An alternative spelling/capitalization of these macros might make them more appealing. Feel free to make a suggestion. -- It's probably incorrect for me to use SetErrno() as a function, such as SetErrno(1); I think the semi-colon is not needed, but wasn't entirely certain. On better advice, I will fix these statements in the remaining source files if this patch is accepted. ---------------------------------------------------------------------- >Comment By: Brad Clements (bkc) Date: 2002-09-27 14:26 Message: Logged In: YES user_id=4631 Based on recent python-dev discussion, I wish to retract this patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-12 15:15 Message: Logged In: YES user_id=45365 Brad, if there's no other way to do your errno magic than by replacing all errno accesses with macros then so be it. *I* definitely don't want to hold off your patch because of that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-12 14:25 Message: Logged In: YES user_id=33168 You should work off CVS head. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-08-12 14:21 Message: Logged In: YES user_id=4631 I would very much like to move this forward. Is all you need is a refreshed diff without pyconfig.h diffs? I'll have to check why DONT_HAVE_TIME_H is in there. I think perhaps because the CE portion is using the Win32 hand-made config, and only differs by a little bit. What about jackjansen's post from 4-19? I cannot use the macro trick he suggests because there are two different functions for accessing errno, one for get and one for set. Regarding his comment about changing all errno accesses: I'm still committed to submitting appropriate diffs for the core and any other module ported to CE or NetWare. In fact, it's time to refresh my CVS copy. What do you suggest I check out? Head, or a specific revision? Thanks ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-12 09:10 Message: Logged In: YES user_id=21627 Any chances that updates to this patch are forthcoming? If not, it will be rejected by October 1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-04 17:33 Message: Logged In: YES user_id=21627 The patch requires further surgery: What is DONT_HAVE_TIME_H? If you want to test for presence of , you need to add HAVE_TIME_H to the autoconf machinery, and all manually-maintained copies of pyconfig.h. Including just the configure.in changes is fine; no need to include changes to generated files. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-19 14:47 Message: Logged In: YES user_id=45365 Brad, I think this patch might be asking for too much. You're asking that all accesses to errno be replaced by GetErrno() or SetErrno() calls, really... And for many cases there is a workaround, where you don't have to change user code (i.e. the normal C code still uses what it thinks is an errno variable). On my system errno is #define errno (*__error()) and the __error() routine returns a pointer to the errno-variable for the current thread. For the GetErrno function this would be good enough, and with a bit of effort you could probably get it to work for the Set function too (possibly by doing the actual Set work in the next Get call). ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-02-11 23:17 Message: Logged In: YES user_id=4631 Hi folks, I need to proceed with the port to NetWare so I have something to demo at Brainshare in March. Unfortunately future patches from me will include both WINCE and NetWare specific patches, though hopefully there won't be much other than config.h and this patch (which is required for NetWare). Is there anything I can do to make this patch more acceptable? Send a bottle of wine, perhaps? ;-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-28 23:39 Message: Logged In: YES user_id=33168 Tim, I can check in or do whatever else needs to be done to check this in and move this forward. How do you want to procede? Brad, I think most people are pretty busy right now. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-28 23:19 Message: Logged In: YES user_id=4631 Hi folks, just wondering if this patch is going to be rejected, or if you're all too busy and I have to be more patient ;-) I have a passle of Python-CE folks waiting on me to finish checking in patches. This is the worst one, I promise! Let me know what you want me to do, when you get a chance. Thanks ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-20 20:17 Message: Logged In: YES user_id=4631 I've eliminated Py_ClearErrno() and updated all the source to use Py_SetErrno(0). Attached is an updated diff for pyport.h ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 19:21 Message: Logged In: YES user_id=31435 Brad, errno is required by ANSI C, which also defines the semantics of a 0 value. Setting errno to 0, and taking errno==0 as meaning "no error", are 100% portable across platforms with a standard-conforming C implementation. If this platform doesn't support standard C, I have to question whether the core should even try to cater to it: the changes needed make no sense to C programmers, so may become a maintenance nightmare. I don't think putting a layer around errno is going to be hard to live with, provided that it merely tries to emulate standard behavior. For that reason, setting errno to 0 is correct, but inventing a new ClearErrno concept is wrong (the latter makes no sense to anyone except its inventor ). ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-20 15:54 Message: Logged In: YES user_id=4631 I can post a new diff for the // or would you be willing to just change the patch you have? I cannot use the same macros for Py_SET_ERANGE_IF_OVERFLOW (X) because Wince doesn't have ERANGE. You'll note the use of Py_SetErrno(1) which is frankly bogus. This is related to your comment on Py_ClearErrno() Using (errno == 0) as meaning "no error" seems to me to be a python source "convention" forced on it by (mostly) floating point side effects. Because the math routines are indicating overflow errors through the side effect of setting errno (rather than returning an explicit NaN that works on all platforms), we must set errno = 0 before calling these math functions. I suppose it's possible that on some platform "clearing the last error value" wouldn't be done this way, but rather might be an explicit function call. Since I was going through the source looking for all errno's, I felt it was clearer to say Py_ClearErrno() rather than Py_SetErrno(0), even though in the end they do the same thing on currently supported platforms. I'm easy, if you want to replace Py_ClearErrno() with Py_SetErrno(0) I can do that too. -- Regarding goto targets.. is it likely that "cleanup" might also collide with local variables? would _cleanup or __cleanup work for you? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-19 22:57 Message: Logged In: YES user_id=33168 Need to change the // comment to /* */. gcc accepts this for C, but it's non-standard (at least it was, it may have changed in C99). You can have 1 Py_SET_ERANGE_IF_OVERFLOW for both platforms if you do this: #ifndef ERANGE #define ERANGE 1 #endif #define Py_SET_ERANGE_IF_OVERFLOW(X) \ do { \ if (Py_GetErrno() == 0 && ((X) == Py_HUGE_VAL || \ (X) == -Py_HUGE_VAL)) \ Py_SetErrno(ERANGE); \ } while(0) I'm not sure of the usefulness of Py_ClearErrno(), since it's the same on all platforms. If errno might be set to something other than 0 in the future, it would be good to make the change now. I would suggest changing finally to cleanup. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-19 21:47 Message: Logged In: YES user_id=4631 Here is an amended diff with the suggested changes. I've tested the semi-colon handling on EVT, it works as suggested. -- Question: What is the prefered style, #ifdef xyz or #if defined(xyz) ? I try to use #ifdef xyz, but sometimes there's multiple possibilities and #if defined(x) || defined(y) is needed. Is that okay? -- Upcoming issue (hoping you address in your reply). There are many "goto finally" statements in various modules. Unfortunately EVT treats "finally" as a reserved word, even when compiling in non C++ mode. Also, Metrowerks does the same. I've changed all of these to "goto my_finally" as a quick work-around. I know "my_finally" sounds yucky, what's your recommendation for this? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-19 20:52 Message: Logged In: YES user_id=31435 All identifiers defined in pyport.h must begin with "Py_". pyport.h is (and must be) #include'd by extension modules, and we need the prefix to avoid stomping on their namespace, and to make clear (to them and to us) that the gimmicks are part of Python's portability layer. A name like "SetErrno" is certain to conflict with some other package's attempt to worm around errno problems; Py_SetErrno () is not. Agree with Neal's final suggestion about dealing with semicolons. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-19 20:28 Message: Logged In: YES user_id=33168 Typically, the semi-colon problem is dealt with as in Py_SET_ERANGE_IF_OVERFLOW. So, #define SetErrno(X) do { SetLastError(X); } while (0) I don't think (but can't remember if) there is any problem for single statements like you have. You could probably do: #ifndef MS_WINCE #define SetErrno(X) errno = (X) /* note no ; */ #else #define SetErrno(X) SetLastError(X) /* note no ; */ #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470 From noreply@sourceforge.net Fri Sep 27 18:29:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Sep 2002 10:29:54 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 10:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2002-09-27 10:29 Message: Logged In: YES user_id=618097 Here is a better patch for the configre.in bits. iIt should be applied to the release22-maint branch and HEAD instead of ethier of the 2 previous patches The bits from Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c are the same as the previous patch. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 21:24 Message: Logged In: YES user_id=618097 Maybe I should have done a seperate one for HEAD I don't know. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 21:21 Message: Logged In: YES user_id=618097 Here is a patch for HEAD that will get things closer to working on SCO ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 20:29 Message: Logged In: YES user_id=618097 Here is a new patch that does a more correct job of working around SCO's wierdness. I've also added support for gcc on Open Server 5 If you have questions, fee free to email tim@multitalents.net ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 13:11 Message: Logged In: YES user_id=618097 Correction on the dlopen answer. The problem is that Open Server's cc builds COFF binaries by default. dlopen only works in an ELF environment. I think I can do better on the dlopen stuff in configure.in I'm removing the patch for now. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 12:06 Message: Logged In: YES user_id=618097 Actually it was HAVE_GETADDRINFO and HAVE_DLOPEN. To keep autoheader from complaing. You could leave that part out, but if you added another function to AC_CHECK_FUNCTS and ran autoreconf, pyconfig.h would not be updated. Why does dlopen fail? SCO is strange. I noticed if the test program was compiled without -belf it worked. That's the part of the patch I like least but iit makes python run on SCO Why -Kpic? That's what the man page says. why do the modules pwd,grp,... For some bizare reason it can't find some functions that are in libc.so Please don't modify Setup.local: this is a hand-edited file. configure creates this file if it does not exist. I chose to populate it on SCO with the entries to get a working python on SCO. If Setup.local exists, it will not be modified as was the case before the patch. Why do you remove 'unixware5' from regrtest.py? The configue.in changes make it unixware7 (which matches Lib/plat-unixware7) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 11:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Fri Sep 27 21:01:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Sep 2002 13:01:04 -0700 Subject: [Patches] [ python-Patches-544740 ] test_commands test fails under Cygwin Message-ID: Patches item #544740, was opened at 2002-04-16 08:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Martin v. Löwis (loewis) Summary: test_commands test fails under Cygwin Initial Comment: The Python 2.2.1 test_commands regression test fails under Cygwin 1.3.10 because the regular expression is pickier now and because Cygwin can have spaces in user and/or group names. See the following for some more details: http://cygwin.com/ml/cygwin/2002-04/msg00774.html and a workaround. I'm submitting this as a bug report instead of a patch because I don't know the best way to fix this issue. Can test_commands use numeric IDs instead of names? Should I discuss this issue on python-dev instead of here? BTW, please add a "Test" category to the available choices for Bugs. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-09-27 12:01 Message: Logged In: YES user_id=86216 I followed your advise. Is the latest patch OK? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 00:33 Message: Logged In: YES user_id=21627 How about the regexp pat = r'''d......... # It is a directory. \s+\d+ # It has some number of links. [^/]* # Skip user, group, size, and date. /\. # and end with the name of the file. ''' If that works, please formulate it as a patch that lists (in a comment) a few possible outputs, so that anybody who wants to tighten the regexp has test cases. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 05:41 Message: Logged In: YES user_id=86216 > I'm not sure what the purpose of getstatus is - > adding -n is a behaviour change, which should be > avoided. Agreed. AFAICT, nothing in the Python source except for test_commands.py itself is using commands.getstatus(). I verified this via: find Lib -name '*.py' | xargs fgrep getstatus Obviously, Python applications could be using commands.py. > I'm still not sure what the issue with spaces in > group names is. Can you report the output of the > ls for your system? $ ls -ld / drwxr-xr-x 15 Administ Domain U 4096 Aug 12 12:50 / $ fgrep 'Domain U' /etc/group Domain Users:S-1-5-21-136257377-364972176-1563891627-513:10513: Note that "Domain U" is the truncated version of "Domain Users". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 05:22 Message: Logged In: YES user_id=21627 I'm not sure what the purpose of getstatus is - adding -n is a behaviour change, which should be avoided. I'm still not sure what the issue with spaces in group names is. Can you report the output of the ls for your system? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 05:12 Message: Logged In: YES user_id=86216 > This patch won't work in other locales. I was afraid of this. > Why do you have to put an explicit format string > for the date in there? Because without the explicit date regular expression, I could not figure out how to match the user and group names with an arbitrary number of embedded spaces. > What specific change made the expression > "pickier"? I guess that "pickier" was a bad choice of words -- I should have used "changed" instead. The original test used "ls -ld /bin/ls" which didn't seem to (but could) trigger the failure. JT> Can test_commands use numeric IDs instead of JT> names? What about changing commands.getstatus() to use numeric IDs? Is the attached (new) patch more acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 06:14 Message: Logged In: YES user_id=21627 This patch won't work in other locales. E.g. in de_DE, a date might read Mär 21 01:14 which won't match your regexp. Furthermore, recent GNU fileutils format it as 2002-09-02 10:12 in non-C locales, which is even further away. In theory, putting LC_ALL=C into the environment should solve this, but it would be better to not rely on the date formatting. Why do you have to put an explicit format string for the date in there? What specific change made the expression "pickier"? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-08-27 10:12 Message: Logged In: YES user_id=86216 Attached is a patch to fix this problem. As suggested by Guido, I am proposing a "better" regular expression. Unfortunately, I had to make an assumption on the date format in order to match the user and group names regardless of the number of embedded spaces. Is my date regular expression acceptable? Will it work in non US locales? FWIW, I tested under Cygwin and Red Hat Linux 7.1 without any ill effects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 07:48 Message: Logged In: YES user_id=33168 Jason, I presume this is still a problem. It probably would be a good idea to discuss on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 From noreply@sourceforge.net Fri Sep 27 22:52:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Sep 2002 14:52:55 -0700 Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter Message-ID: Patches item #505846, was opened at 2002-01-19 15:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470 Category: Core (C code) >Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Brad Clements (bkc) >Assigned to: Neal Norwitz (nnorwitz) Summary: pyport.h, Wince and errno getter/setter Initial Comment: Most of the remaining Windows CE diffs are due to the lack of errno on Windows CE. There are other OS's that do not have errno (but they have a workalike method). At first I had simply commented out all references in the code to errno, but that quickly became unworkable. Wince and NetWare use a function to set the per- thread "errno" value. Although errno #defines (like ERANGE) are not defined for Wince, they are defined for NetWare. Removing references to errno would artificially hobble the NetWare port. These platforms also use a function to retrieve the current errno value. The attached diff for pyport.h attempts to standardize the access method for errno (or it's work-alike) by providing SetErrno(), ClearErrno() and GetErrno() macros. ClearErrno() is SetErrno(0) I've found and changed all direct references to errno to use these macros. This patch must be submitted before the patches for other modules. -- I see two negatives with this approach: 1. It will be a pain to think GetErrno() instead of "errno" when modifying/writing new code. 2. Extension modules will need access to pyport.h for the target platform. In the worst case, directly referencing errno instead of using the macros will break only those platforms for which the macros do something different. That is, Wince and NetWare. -- An alternative spelling/capitalization of these macros might make them more appealing. Feel free to make a suggestion. -- It's probably incorrect for me to use SetErrno() as a function, such as SetErrno(1); I think the semi-colon is not needed, but wasn't entirely certain. On better advice, I will fix these statements in the remaining source files if this patch is accepted. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-27 17:52 Message: Logged In: YES user_id=33168 Closing, since Brad retracted. Brad, I hope you continue your work. It seems the last part of the discussion was that Py_SerErrno() would be acceptable for the few places it is necessary. But continue to use errno in the code and for Win CE, #define errno GetErrno(). ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-09-27 10:26 Message: Logged In: YES user_id=4631 Based on recent python-dev discussion, I wish to retract this patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-12 11:15 Message: Logged In: YES user_id=45365 Brad, if there's no other way to do your errno magic than by replacing all errno accesses with macros then so be it. *I* definitely don't want to hold off your patch because of that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-12 10:25 Message: Logged In: YES user_id=33168 You should work off CVS head. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-08-12 10:21 Message: Logged In: YES user_id=4631 I would very much like to move this forward. Is all you need is a refreshed diff without pyconfig.h diffs? I'll have to check why DONT_HAVE_TIME_H is in there. I think perhaps because the CE portion is using the Win32 hand-made config, and only differs by a little bit. What about jackjansen's post from 4-19? I cannot use the macro trick he suggests because there are two different functions for accessing errno, one for get and one for set. Regarding his comment about changing all errno accesses: I'm still committed to submitting appropriate diffs for the core and any other module ported to CE or NetWare. In fact, it's time to refresh my CVS copy. What do you suggest I check out? Head, or a specific revision? Thanks ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-12 05:10 Message: Logged In: YES user_id=21627 Any chances that updates to this patch are forthcoming? If not, it will be rejected by October 1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-04 13:33 Message: Logged In: YES user_id=21627 The patch requires further surgery: What is DONT_HAVE_TIME_H? If you want to test for presence of , you need to add HAVE_TIME_H to the autoconf machinery, and all manually-maintained copies of pyconfig.h. Including just the configure.in changes is fine; no need to include changes to generated files. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-04-19 10:47 Message: Logged In: YES user_id=45365 Brad, I think this patch might be asking for too much. You're asking that all accesses to errno be replaced by GetErrno() or SetErrno() calls, really... And for many cases there is a workaround, where you don't have to change user code (i.e. the normal C code still uses what it thinks is an errno variable). On my system errno is #define errno (*__error()) and the __error() routine returns a pointer to the errno-variable for the current thread. For the GetErrno function this would be good enough, and with a bit of effort you could probably get it to work for the Set function too (possibly by doing the actual Set work in the next Get call). ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-02-11 18:17 Message: Logged In: YES user_id=4631 Hi folks, I need to proceed with the port to NetWare so I have something to demo at Brainshare in March. Unfortunately future patches from me will include both WINCE and NetWare specific patches, though hopefully there won't be much other than config.h and this patch (which is required for NetWare). Is there anything I can do to make this patch more acceptable? Send a bottle of wine, perhaps? ;-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-28 18:39 Message: Logged In: YES user_id=33168 Tim, I can check in or do whatever else needs to be done to check this in and move this forward. How do you want to procede? Brad, I think most people are pretty busy right now. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-28 18:19 Message: Logged In: YES user_id=4631 Hi folks, just wondering if this patch is going to be rejected, or if you're all too busy and I have to be more patient ;-) I have a passle of Python-CE folks waiting on me to finish checking in patches. This is the worst one, I promise! Let me know what you want me to do, when you get a chance. Thanks ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-20 15:17 Message: Logged In: YES user_id=4631 I've eliminated Py_ClearErrno() and updated all the source to use Py_SetErrno(0). Attached is an updated diff for pyport.h ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 14:21 Message: Logged In: YES user_id=31435 Brad, errno is required by ANSI C, which also defines the semantics of a 0 value. Setting errno to 0, and taking errno==0 as meaning "no error", are 100% portable across platforms with a standard-conforming C implementation. If this platform doesn't support standard C, I have to question whether the core should even try to cater to it: the changes needed make no sense to C programmers, so may become a maintenance nightmare. I don't think putting a layer around errno is going to be hard to live with, provided that it merely tries to emulate standard behavior. For that reason, setting errno to 0 is correct, but inventing a new ClearErrno concept is wrong (the latter makes no sense to anyone except its inventor ). ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-20 10:54 Message: Logged In: YES user_id=4631 I can post a new diff for the // or would you be willing to just change the patch you have? I cannot use the same macros for Py_SET_ERANGE_IF_OVERFLOW (X) because Wince doesn't have ERANGE. You'll note the use of Py_SetErrno(1) which is frankly bogus. This is related to your comment on Py_ClearErrno() Using (errno == 0) as meaning "no error" seems to me to be a python source "convention" forced on it by (mostly) floating point side effects. Because the math routines are indicating overflow errors through the side effect of setting errno (rather than returning an explicit NaN that works on all platforms), we must set errno = 0 before calling these math functions. I suppose it's possible that on some platform "clearing the last error value" wouldn't be done this way, but rather might be an explicit function call. Since I was going through the source looking for all errno's, I felt it was clearer to say Py_ClearErrno() rather than Py_SetErrno(0), even though in the end they do the same thing on currently supported platforms. I'm easy, if you want to replace Py_ClearErrno() with Py_SetErrno(0) I can do that too. -- Regarding goto targets.. is it likely that "cleanup" might also collide with local variables? would _cleanup or __cleanup work for you? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-19 17:57 Message: Logged In: YES user_id=33168 Need to change the // comment to /* */. gcc accepts this for C, but it's non-standard (at least it was, it may have changed in C99). You can have 1 Py_SET_ERANGE_IF_OVERFLOW for both platforms if you do this: #ifndef ERANGE #define ERANGE 1 #endif #define Py_SET_ERANGE_IF_OVERFLOW(X) \ do { \ if (Py_GetErrno() == 0 && ((X) == Py_HUGE_VAL || \ (X) == -Py_HUGE_VAL)) \ Py_SetErrno(ERANGE); \ } while(0) I'm not sure of the usefulness of Py_ClearErrno(), since it's the same on all platforms. If errno might be set to something other than 0 in the future, it would be good to make the change now. I would suggest changing finally to cleanup. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-19 16:47 Message: Logged In: YES user_id=4631 Here is an amended diff with the suggested changes. I've tested the semi-colon handling on EVT, it works as suggested. -- Question: What is the prefered style, #ifdef xyz or #if defined(xyz) ? I try to use #ifdef xyz, but sometimes there's multiple possibilities and #if defined(x) || defined(y) is needed. Is that okay? -- Upcoming issue (hoping you address in your reply). There are many "goto finally" statements in various modules. Unfortunately EVT treats "finally" as a reserved word, even when compiling in non C++ mode. Also, Metrowerks does the same. I've changed all of these to "goto my_finally" as a quick work-around. I know "my_finally" sounds yucky, what's your recommendation for this? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-19 15:52 Message: Logged In: YES user_id=31435 All identifiers defined in pyport.h must begin with "Py_". pyport.h is (and must be) #include'd by extension modules, and we need the prefix to avoid stomping on their namespace, and to make clear (to them and to us) that the gimmicks are part of Python's portability layer. A name like "SetErrno" is certain to conflict with some other package's attempt to worm around errno problems; Py_SetErrno () is not. Agree with Neal's final suggestion about dealing with semicolons. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-19 15:28 Message: Logged In: YES user_id=33168 Typically, the semi-colon problem is dealt with as in Py_SET_ERANGE_IF_OVERFLOW. So, #define SetErrno(X) do { SetLastError(X); } while (0) I don't think (but can't remember if) there is any problem for single statements like you have. You could probably do: #ifndef MS_WINCE #define SetErrno(X) errno = (X) /* note no ; */ #else #define SetErrno(X) SetLastError(X) /* note no ; */ #endif ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470 From noreply@sourceforge.net Mon Sep 30 02:03:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Sep 2002 18:03:52 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 30 07:33:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Sep 2002 23:33:51 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 30 07:35:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Sep 2002 23:35:47 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 30 07:34:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 29 Sep 2002 23:34:56 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 30 11:11:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 03:11:00 -0700 Subject: [Patches] [ python-Patches-615343 ] acconfig.h out of date Message-ID: Patches item #615343, was opened at 2002-09-27 05:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615343&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: acconfig.h out of date Initial Comment: acconfig.h is out of date. It looks like someone added AC_DEFINE(HAVE_GETADDRINFO) to configure.in without updating acconfig.h autoheader coomplains and then will not update pyconfig.h.in /usr/bin/autoheader: Symbol `HAVE_GETADDRINFO' is not covered by /usr/share/autoconf/acconfig.h ./acconfig.h patch attached ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:11 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as pyconfig.h.in 1.20.8.1; acconfig.h 1.58.8.1; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615343&group_id=5470 From noreply@sourceforge.net Mon Sep 30 11:25:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 03:25:33 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 19:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:25 Message: Logged In: YES user_id=21627 In the CVS head, we currently have OpenUNIX*|UnixWare*) OPT="-O -K pentium,host,inline,loop_unroll,alloca ";; I understand that your patch is also for systems identifying themselves as UnixWare. Won't the change + case $ac_sys_system in + SCO_SV*) OPT="$OPT -m486 -DSCO5";; + esac interfere with that? Could you kindly produce a table that maps product names to ac_sys_system values? Also, in the head version, we have #if defined(__USLC__) && defined(__SCO_VERSION__) #define STRICT_SYSV_CURSES /* Don't use ncurses extensions */ #endif in configure.in. Can you please determine whether this is still needed, or can be achieved by some other way? As for -Kpic: The UnixWare 7 man page on http://docsrv.caldera.com/cgi-bin/man/man/html.1/cc.1.html says there is a -KPIC option, but no -Kpic option. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-27 19:29 Message: Logged In: YES user_id=618097 Here is a better patch for the configre.in bits. iIt should be applied to the release22-maint branch and HEAD instead of ethier of the 2 previous patches The bits from Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c are the same as the previous patch. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-27 06:24 Message: Logged In: YES user_id=618097 Maybe I should have done a seperate one for HEAD I don't know. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-27 06:21 Message: Logged In: YES user_id=618097 Here is a patch for HEAD that will get things closer to working on SCO ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-27 05:29 Message: Logged In: YES user_id=618097 Here is a new patch that does a more correct job of working around SCO's wierdness. I've also added support for gcc on Open Server 5 If you have questions, fee free to email tim@multitalents.net ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 22:11 Message: Logged In: YES user_id=618097 Correction on the dlopen answer. The problem is that Open Server's cc builds COFF binaries by default. dlopen only works in an ELF environment. I think I can do better on the dlopen stuff in configure.in I'm removing the patch for now. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 21:06 Message: Logged In: YES user_id=618097 Actually it was HAVE_GETADDRINFO and HAVE_DLOPEN. To keep autoheader from complaing. You could leave that part out, but if you added another function to AC_CHECK_FUNCTS and ran autoreconf, pyconfig.h would not be updated. Why does dlopen fail? SCO is strange. I noticed if the test program was compiled without -belf it worked. That's the part of the patch I like least but iit makes python run on SCO Why -Kpic? That's what the man page says. why do the modules pwd,grp,... For some bizare reason it can't find some functions that are in libc.so Please don't modify Setup.local: this is a hand-edited file. configure creates this file if it does not exist. I chose to populate it on SCO with the entries to get a working python on SCO. If Setup.local exists, it will not be modified as was the case before the patch. Why do you remove 'unixware5' from regrtest.py? The configue.in changes make it unixware7 (which matches Lib/plat-unixware7) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 20:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Mon Sep 30 11:27:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 03:27:18 -0700 Subject: [Patches] [ python-Patches-544740 ] test_commands test fails under Cygwin Message-ID: Patches item #544740, was opened at 2002-04-16 18:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 Category: Tests Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: test_commands test fails under Cygwin Initial Comment: The Python 2.2.1 test_commands regression test fails under Cygwin 1.3.10 because the regular expression is pickier now and because Cygwin can have spaces in user and/or group names. See the following for some more details: http://cygwin.com/ml/cygwin/2002-04/msg00774.html and a workaround. I'm submitting this as a bug report instead of a patch because I don't know the best way to fix this issue. Can test_commands use numeric IDs instead of names? Should I discuss this issue on python-dev instead of here? BTW, please add a "Test" category to the available choices for Bugs. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:27 Message: Logged In: YES user_id=21627 That looks fine, please apply it. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-27 22:01 Message: Logged In: YES user_id=86216 I followed your advise. Is the latest patch OK? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 10:33 Message: Logged In: YES user_id=21627 How about the regexp pat = r'''d......... # It is a directory. \s+\d+ # It has some number of links. [^/]* # Skip user, group, size, and date. /\. # and end with the name of the file. ''' If that works, please formulate it as a patch that lists (in a comment) a few possible outputs, so that anybody who wants to tighten the regexp has test cases. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 15:41 Message: Logged In: YES user_id=86216 > I'm not sure what the purpose of getstatus is - > adding -n is a behaviour change, which should be > avoided. Agreed. AFAICT, nothing in the Python source except for test_commands.py itself is using commands.getstatus(). I verified this via: find Lib -name '*.py' | xargs fgrep getstatus Obviously, Python applications could be using commands.py. > I'm still not sure what the issue with spaces in > group names is. Can you report the output of the > ls for your system? $ ls -ld / drwxr-xr-x 15 Administ Domain U 4096 Aug 12 12:50 / $ fgrep 'Domain U' /etc/group Domain Users:S-1-5-21-136257377-364972176-1563891627-513:10513: Note that "Domain U" is the truncated version of "Domain Users". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 15:22 Message: Logged In: YES user_id=21627 I'm not sure what the purpose of getstatus is - adding -n is a behaviour change, which should be avoided. I'm still not sure what the issue with spaces in group names is. Can you report the output of the ls for your system? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 15:12 Message: Logged In: YES user_id=86216 > This patch won't work in other locales. I was afraid of this. > Why do you have to put an explicit format string > for the date in there? Because without the explicit date regular expression, I could not figure out how to match the user and group names with an arbitrary number of embedded spaces. > What specific change made the expression > "pickier"? I guess that "pickier" was a bad choice of words -- I should have used "changed" instead. The original test used "ls -ld /bin/ls" which didn't seem to (but could) trigger the failure. JT> Can test_commands use numeric IDs instead of JT> names? What about changing commands.getstatus() to use numeric IDs? Is the attached (new) patch more acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 16:14 Message: Logged In: YES user_id=21627 This patch won't work in other locales. E.g. in de_DE, a date might read Mär 21 01:14 which won't match your regexp. Furthermore, recent GNU fileutils format it as 2002-09-02 10:12 in non-C locales, which is even further away. In theory, putting LC_ALL=C into the environment should solve this, but it would be better to not rely on the date formatting. Why do you have to put an explicit format string for the date in there? What specific change made the expression "pickier"? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-08-27 20:12 Message: Logged In: YES user_id=86216 Attached is a patch to fix this problem. As suggested by Guido, I am proposing a "better" regular expression. Unfortunately, I had to make an assumption on the date format in order to match the user and group names regardless of the number of embedded spaces. Is my date regular expression acceptable? Will it work in non US locales? FWIW, I tested under Cygwin and Red Hat Linux 7.1 without any ill effects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 17:48 Message: Logged In: YES user_id=33168 Jason, I presume this is still a problem. It probably would be a good idea to discuss on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 From noreply@sourceforge.net Mon Sep 30 11:43:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 03:43:00 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 13:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 08:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 03:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 08:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-25 21:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 17:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 14:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 15:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 30 12:48:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 04:48:56 -0700 Subject: [Patches] [ python-Patches-616496 ] textwrap: prefix short lines Message-ID: Patches item #616496, was opened at 2002-09-30 07:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=616496&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Greg Ward (gward) Summary: textwrap: prefix short lines Initial Comment: If the text to be filled is shorter than one line, initial_indent is not prefixed to the resulting text. For example: >>> textwrap.fill('abc '*18, initial_indent=6*' ') ' abc abc abc abc ... abc\nabc abc' >>> textwrap.fill('abc '*10, initial_indent=6*' ') 'abc abc abc abc abc abc abc abc abc abc ' >>> I believe the attached patch fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=616496&group_id=5470 From noreply@sourceforge.net Mon Sep 30 13:20:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 05:20:26 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 30 13:21:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 05:21:56 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 30 13:52:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 05:52:02 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 30 13:54:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 05:54:44 -0700 Subject: [Patches] [ python-Patches-594001 ] PEP 277: Unicode file name support Message-ID: Patches item #594001, was opened at 2002-08-12 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Mark Hammond (mhammond) Summary: PEP 277: Unicode file name support Initial Comment: This patch is in an updated version of the patch [1] mentioned in the PEP. In addition to merging it with the CVS, it fixes a few formatting problems. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:54 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch - fixes the problem I mentioned with test_unicode_files.py, fixes an error I introduced where the "WithFilename" error functions could be passed a NULL filename, and adding an assert to match the one I added previously. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:52 Message: Logged In: YES user_id=14198 Sorry - not sure what I was thinking - obviously can't check in a patch known to crash the test suite! Attaching a new patch. This fixes the crash in test_unicode_file I mentioned. It also fixes another error I introduced where PyErr_SetWithFilename functions can have NULL filenames. Also added an assert for symmetry with one I added before. Martin - back to me if you want me to check it in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:21 Message: Logged In: YES user_id=14198 I missed the fact this was re-assigned to me - should I check my new patch in? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 22:20 Message: Logged In: YES user_id=14198 I get an exception running test_unicode_file.py - we end up with a MBCS encoded string passed to PyUnicode_FromEncodedObject(), that attempts to decode using the system default encoding rather than the file-system default. The error is a NULL pointer deref so should be obvious - unfortunately the fix requires a local reimplementation of PyUnicode_FromEncodedObject(), passing an explicit encoding for string objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 20:43 Message: Logged In: YES user_id=21627 Thanks for your comments, just shouting at me to correct all these problems would have been fine :-) In what case do you still get an exception? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:35 Message: Logged In: YES user_id=14198 Back to martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:34 Message: Logged In: YES user_id=14198 Back to Martin for comments on my comments ;) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 16:33 Message: Logged In: YES user_id=14198 Uploading text file with my comments on the patch. Also uploading a new patch with these corrections and even better (?) error handling. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-09-30 11:03 Message: Logged In: YES user_id=14198 Will review this instant - sorry for the delay. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 16:24 Message: Logged In: YES user_id=21627 Mark, can you please indicate whether you will review this patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-09-26 05:43 Message: Logged In: YES user_id=31435 Sorry, Martin, bouncing back to Mark -- I really don't know anything about the Windows filename APIs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-23 01:31 Message: Logged In: YES user_id=21627 Tim, can you review this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-04 22:06 Message: Logged In: YES user_id=21627 This is a new version: - wrapped all Windows wide API code with #ifdef Py_WIN_WIDE_FILENAMES - added test case Mark, can you please take a look at this? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-12 23:38 Message: Logged In: YES user_id=6380 I'd make unicode_filenames() a macro that expands to 0 on platforms without this wart. I'd also test for wfunc!=NULL before calling unicode_filenames(). There's a lot of hairy code here. Are you sure that there are test cases in the test suite that exercise all of it? Aren't there some #ifdefs missing? posix_[12]str have code that's only relevant for Windows but isn't #ifdef'ed out like it is elsewhere. There should probably be a separate #define in pyport.h to test for this that's equivalent to defined(MS_WINDOWS) && !defined(Py_UNICODE_WIDE), so this can be uniformly tested to see whether this code is necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=594001&group_id=5470 From noreply@sourceforge.net Mon Sep 30 16:46:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 08:46:12 -0700 Subject: [Patches] [ python-Patches-544740 ] test_commands test fails under Cygwin Message-ID: Patches item #544740, was opened at 2002-04-16 08:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 Category: Tests Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Jason Tishler (jlt63) Summary: test_commands test fails under Cygwin Initial Comment: The Python 2.2.1 test_commands regression test fails under Cygwin 1.3.10 because the regular expression is pickier now and because Cygwin can have spaces in user and/or group names. See the following for some more details: http://cygwin.com/ml/cygwin/2002-04/msg00774.html and a workaround. I'm submitting this as a bug report instead of a patch because I don't know the best way to fix this issue. Can test_commands use numeric IDs instead of names? Should I discuss this issue on python-dev instead of here? BTW, please add a "Test" category to the available choices for Bugs. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-09-30 07:46 Message: Logged In: YES user_id=86216 Committed as Lib/test/test_commands.py 1.8. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 02:27 Message: Logged In: YES user_id=21627 That looks fine, please apply it. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-27 12:01 Message: Logged In: YES user_id=86216 I followed your advise. Is the latest patch OK? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 00:33 Message: Logged In: YES user_id=21627 How about the regexp pat = r'''d......... # It is a directory. \s+\d+ # It has some number of links. [^/]* # Skip user, group, size, and date. /\. # and end with the name of the file. ''' If that works, please formulate it as a patch that lists (in a comment) a few possible outputs, so that anybody who wants to tighten the regexp has test cases. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 05:41 Message: Logged In: YES user_id=86216 > I'm not sure what the purpose of getstatus is - > adding -n is a behaviour change, which should be > avoided. Agreed. AFAICT, nothing in the Python source except for test_commands.py itself is using commands.getstatus(). I verified this via: find Lib -name '*.py' | xargs fgrep getstatus Obviously, Python applications could be using commands.py. > I'm still not sure what the issue with spaces in > group names is. Can you report the output of the > ls for your system? $ ls -ld / drwxr-xr-x 15 Administ Domain U 4096 Aug 12 12:50 / $ fgrep 'Domain U' /etc/group Domain Users:S-1-5-21-136257377-364972176-1563891627-513:10513: Note that "Domain U" is the truncated version of "Domain Users". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-06 05:22 Message: Logged In: YES user_id=21627 I'm not sure what the purpose of getstatus is - adding -n is a behaviour change, which should be avoided. I'm still not sure what the issue with spaces in group names is. Can you report the output of the ls for your system? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-09-06 05:12 Message: Logged In: YES user_id=86216 > This patch won't work in other locales. I was afraid of this. > Why do you have to put an explicit format string > for the date in there? Because without the explicit date regular expression, I could not figure out how to match the user and group names with an arbitrary number of embedded spaces. > What specific change made the expression > "pickier"? I guess that "pickier" was a bad choice of words -- I should have used "changed" instead. The original test used "ls -ld /bin/ls" which didn't seem to (but could) trigger the failure. JT> Can test_commands use numeric IDs instead of JT> names? What about changing commands.getstatus() to use numeric IDs? Is the attached (new) patch more acceptable? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-02 06:14 Message: Logged In: YES user_id=21627 This patch won't work in other locales. E.g. in de_DE, a date might read Mär 21 01:14 which won't match your regexp. Furthermore, recent GNU fileutils format it as 2002-09-02 10:12 in non-C locales, which is even further away. In theory, putting LC_ALL=C into the environment should solve this, but it would be better to not rely on the date formatting. Why do you have to put an explicit format string for the date in there? What specific change made the expression "pickier"? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-08-27 10:12 Message: Logged In: YES user_id=86216 Attached is a patch to fix this problem. As suggested by Guido, I am proposing a "better" regular expression. Unfortunately, I had to make an assumption on the date format in order to match the user and group names regardless of the number of embedded spaces. Is my date regular expression acceptable? Will it work in non US locales? FWIW, I tested under Cygwin and Red Hat Linux 7.1 without any ill effects. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 07:48 Message: Logged In: YES user_id=33168 Jason, I presume this is still a problem. It probably would be a good idea to discuss on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=544740&group_id=5470 From noreply@sourceforge.net Mon Sep 30 16:58:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 08:58:17 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 10:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Tim Rice (tim1470) Date: 2002-09-30 08:58 Message: Logged In: YES user_id=618097 SCO (formarly Caldera) has 3 OS product lines. UnixWare (which includes OpenUNIX) Open Server 5 and OpenLinux. The patch primarly address the Open Server 5 product. Here is a table of $ac_sys_system (uname -s) values. UnixWare 2.03 UNIX_SV UnixWare 2.1.3 UNIX_SV UnixWare 7.1.1 UnixWare OpenUnix 8.0.0 OpenUNIX Open Server 5 SCO_SV So no, + case $ac_sys_system in + SCO_SV*) OPT="$OPT -m486 -DSCO5";; + esac will not interfere with UnixWare. The -KPIC for UnixWare is correct but for Open Server, the option is -Kpic In HEAD, #if defined(__USLC__) && defined(__SCO_VERSION__ #define STRICT_SYSV_CURSES /* Don't use ncurses extensions */ #endif should really be replaced with a configure time test. HEAD still needs a lot of work for UnixWare and Open Server. Perhaps i'll have time in november. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 03:25 Message: Logged In: YES user_id=21627 In the CVS head, we currently have OpenUNIX*|UnixWare*) OPT="-O -K pentium,host,inline,loop_unroll,alloca ";; I understand that your patch is also for systems identifying themselves as UnixWare. Won't the change + case $ac_sys_system in + SCO_SV*) OPT="$OPT -m486 -DSCO5";; + esac interfere with that? Could you kindly produce a table that maps product names to ac_sys_system values? Also, in the head version, we have #if defined(__USLC__) && defined(__SCO_VERSION__) #define STRICT_SYSV_CURSES /* Don't use ncurses extensions */ #endif in configure.in. Can you please determine whether this is still needed, or can be achieved by some other way? As for -Kpic: The UnixWare 7 man page on http://docsrv.caldera.com/cgi-bin/man/man/html.1/cc.1.html says there is a -KPIC option, but no -Kpic option. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-27 10:29 Message: Logged In: YES user_id=618097 Here is a better patch for the configre.in bits. iIt should be applied to the release22-maint branch and HEAD instead of ethier of the 2 previous patches The bits from Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c are the same as the previous patch. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 21:24 Message: Logged In: YES user_id=618097 Maybe I should have done a seperate one for HEAD I don't know. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 21:21 Message: Logged In: YES user_id=618097 Here is a patch for HEAD that will get things closer to working on SCO ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 20:29 Message: Logged In: YES user_id=618097 Here is a new patch that does a more correct job of working around SCO's wierdness. I've also added support for gcc on Open Server 5 If you have questions, fee free to email tim@multitalents.net ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 13:11 Message: Logged In: YES user_id=618097 Correction on the dlopen answer. The problem is that Open Server's cc builds COFF binaries by default. dlopen only works in an ELF environment. I think I can do better on the dlopen stuff in configure.in I'm removing the patch for now. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 12:06 Message: Logged In: YES user_id=618097 Actually it was HAVE_GETADDRINFO and HAVE_DLOPEN. To keep autoheader from complaing. You could leave that part out, but if you added another function to AC_CHECK_FUNCTS and ran autoreconf, pyconfig.h would not be updated. Why does dlopen fail? SCO is strange. I noticed if the test program was compiled without -belf it worked. That's the part of the patch I like least but iit makes python run on SCO Why -Kpic? That's what the man page says. why do the modules pwd,grp,... For some bizare reason it can't find some functions that are in libc.so Please don't modify Setup.local: this is a hand-edited file. configure creates this file if it does not exist. I chose to populate it on SCO with the entries to get a working python on SCO. If Setup.local exists, it will not be modified as was the case before the patch. Why do you remove 'unixware5' from regrtest.py? The configue.in changes make it unixware7 (which matches Lib/plat-unixware7) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 11:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 From noreply@sourceforge.net Mon Sep 30 17:24:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Sep 2002 09:24:26 -0700 Subject: [Patches] [ python-Patches-615069 ] build fixes for SCO Message-ID: Patches item #615069, was opened at 2002-09-26 19:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tim Rice (tim1470) Assigned to: Nobody/Anonymous (nobody) Summary: build fixes for SCO Initial Comment: Here is a patch that fixes some build issues on SCO Open Server 5, UnixWare 7, and OpenUnix 8. The patch is based on the release22-maint branch (pulled 25 Sep) The configure.in, Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c patches should go iin HEAD too. Hunk #5 of configure.in will fail on HEAD. It'l have to me manuall added at about line 1611. There will be more work to get the HEAD branch working. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 18:24 Message: Logged In: YES user_id=21627 Thanks for these clarifications.Applied in 2.2 as configure.in 1.288.6.12; regrtest.py 1.70.4.2; _cursesmodule.c 2.61.6.3; _hotshot.c 1.11.6.4; _cursesmodule.c 2.61.6.3; configure 1.279.6.12; I have also applied the patch to HEAD, hoping that you'll supply the missing bits as a separate patch later: configure 1.338; configure.in 1.349; regrtest.py 1.98 _cursesmodule.c 2.67; _hotshot.c 1.30; ACKS 1.206; If you do provide more patches later, please split them individually by system. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-30 17:58 Message: Logged In: YES user_id=618097 SCO (formarly Caldera) has 3 OS product lines. UnixWare (which includes OpenUNIX) Open Server 5 and OpenLinux. The patch primarly address the Open Server 5 product. Here is a table of $ac_sys_system (uname -s) values. UnixWare 2.03 UNIX_SV UnixWare 2.1.3 UNIX_SV UnixWare 7.1.1 UnixWare OpenUnix 8.0.0 OpenUNIX Open Server 5 SCO_SV So no, + case $ac_sys_system in + SCO_SV*) OPT="$OPT -m486 -DSCO5";; + esac will not interfere with UnixWare. The -KPIC for UnixWare is correct but for Open Server, the option is -Kpic In HEAD, #if defined(__USLC__) && defined(__SCO_VERSION__ #define STRICT_SYSV_CURSES /* Don't use ncurses extensions */ #endif should really be replaced with a configure time test. HEAD still needs a lot of work for UnixWare and Open Server. Perhaps i'll have time in november. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 12:25 Message: Logged In: YES user_id=21627 In the CVS head, we currently have OpenUNIX*|UnixWare*) OPT="-O -K pentium,host,inline,loop_unroll,alloca ";; I understand that your patch is also for systems identifying themselves as UnixWare. Won't the change + case $ac_sys_system in + SCO_SV*) OPT="$OPT -m486 -DSCO5";; + esac interfere with that? Could you kindly produce a table that maps product names to ac_sys_system values? Also, in the head version, we have #if defined(__USLC__) && defined(__SCO_VERSION__) #define STRICT_SYSV_CURSES /* Don't use ncurses extensions */ #endif in configure.in. Can you please determine whether this is still needed, or can be achieved by some other way? As for -Kpic: The UnixWare 7 man page on http://docsrv.caldera.com/cgi-bin/man/man/html.1/cc.1.html says there is a -KPIC option, but no -Kpic option. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-27 19:29 Message: Logged In: YES user_id=618097 Here is a better patch for the configre.in bits. iIt should be applied to the release22-maint branch and HEAD instead of ethier of the 2 previous patches The bits from Lib/test/regrtest.py, Modules/_cursesmodule.c, and Modules/_hotshot.c are the same as the previous patch. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-27 06:24 Message: Logged In: YES user_id=618097 Maybe I should have done a seperate one for HEAD I don't know. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-27 06:21 Message: Logged In: YES user_id=618097 Here is a patch for HEAD that will get things closer to working on SCO ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-27 05:29 Message: Logged In: YES user_id=618097 Here is a new patch that does a more correct job of working around SCO's wierdness. I've also added support for gcc on Open Server 5 If you have questions, fee free to email tim@multitalents.net ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 22:11 Message: Logged In: YES user_id=618097 Correction on the dlopen answer. The problem is that Open Server's cc builds COFF binaries by default. dlopen only works in an ELF environment. I think I can do better on the dlopen stuff in configure.in I'm removing the patch for now. ---------------------------------------------------------------------- Comment By: Tim Rice (tim1470) Date: 2002-09-26 21:06 Message: Logged In: YES user_id=618097 Actually it was HAVE_GETADDRINFO and HAVE_DLOPEN. To keep autoheader from complaing. You could leave that part out, but if you added another function to AC_CHECK_FUNCTS and ran autoreconf, pyconfig.h would not be updated. Why does dlopen fail? SCO is strange. I noticed if the test program was compiled without -belf it worked. That's the part of the patch I like least but iit makes python run on SCO Why -Kpic? That's what the man page says. why do the modules pwd,grp,... For some bizare reason it can't find some functions that are in libc.so Please don't modify Setup.local: this is a hand-edited file. configure creates this file if it does not exist. I chose to populate it on SCO with the entries to get a working python on SCO. If Setup.local exists, it will not be modified as was the case before the patch. Why do you remove 'unixware5' from regrtest.py? The configue.in changes make it unixware7 (which matches Lib/plat-unixware7) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-26 20:26 Message: Logged In: YES user_id=21627 A number of questions and comments: - why do you add HAVE_GETADDRINFO and HAVE_GETNAMEINFO to acconfig.h? - Why does the dlopen test fail? Can you test whether it still fails in the HEAD branch? - Why do you use -Kpic? - why do the modules pwd,grp,... fail as shared modules? Please don't modify Setup.local: this is a hand-edited file. - Why do you remove 'unixware5' from regrtest.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=615069&group_id=5470