From noreply at sourceforge.net Sun Aug 1 02:10:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 1 02:10:17 2004 Subject: [ python-Bugs-1000439 ] optparse error method doesn't print option info Message-ID: Bugs item #1000439, was opened at 2004-07-30 11:05 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000439&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ivan Nestlerode (nestler) Assigned to: Greg Ward (gward) Summary: optparse error method doesn't print option info Initial Comment: When there is an error in optparse.OptionParser's parse_args() method, (like if the user types an argument to an option that doesn't take one), a terse one-line error message is printed and the program exits. I think it would be significantly more useful if the option documentation were printed out too, but I have no way to make this happen currently (since exit is called). Please expose a toggle to print out the option info (that stuff that is printed with -h) when there is a parsing error. It could probably be implemented as a Boolean argument to the OptionParser constructor. To illustrate what I'm talking about, consider a program called mktoc that uses the optparse module for its parsing. Here are two runs of it. # This prints out the one-liner usage string and the options details $ mktoc -h usage: mktoc [options] [showdirectoryname] options: --version show program's version number and exit -h, --help show this help message and exit -a, --auto run automatically -bBAND, --band=BAND specify the band manually -c, --cdrdao output cdrdao TOC format (the default) -d, --data make a data disc instead of an audio disc -k, --k3b output K3B project format # This only prints out the one-liner usage string which is basically # useless without the option details. This is what comes out of the # error() method of the parser object. $ mktoc --cdrdao=foo usage: mktoc [options] [showdirectoryname] mktoc: error: --cdrdao option does not take a value If it isn't clear, the reason I think the option info should be printed is for usability (if the user is confused enough to put arguments where they don't belong or some such thing, they probably need the more verbose message). Thanks, -Ivan ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-08-01 10:10 Message: Logged In: YES user_id=14198 It is not clear to me that the usability is better with your patch - experienced users who simply made a typo, or had a brain-fart will often *not* want the full usage. You could catch the SystemExit exception, and print your usage there. You may also be able to override your "usage" string so it includes "use --help for more details" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000439&group_id=5470 From noreply at sourceforge.net Sun Aug 1 14:50:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 1 14:50:55 2004 Subject: [ python-Bugs-896061 ] symtable.Symbol.is_global() is strange Message-ID: Bugs item #896061, was opened at 2004-02-12 22:08 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896061&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter ?strand (astrand) Assigned to: Jeremy Hylton (jhylton) Summary: symtable.Symbol.is_global() is strange Initial Comment: The symtable.Symbol.is_global() returns false for symbols in plain functions: If the source looks like this: foo = 1 def fie(): print foo Calling is_global() for the "foo" name returns False (using the fie functions SymbolTable). With a method, however, it works as expected: foo = 1 class C: def fie(self): print foo ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2004-08-01 14:50 Message: Logged In: YES user_id=344921 I would appreciate if someone could take a look at this. This problem makes the development of pyobfuscate harder: Basically, I'm guessing how things are supposed to work. Bug 896052 is, of course, also relevant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896061&group_id=5470 From noreply at sourceforge.net Sun Aug 1 18:01:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 1 18:01:48 2004 Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters Message-ID: Bugs item #989185, was opened at 2004-07-12 12:59 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode.width broken for combining characters Initial Comment: Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) [GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> u'\u3060'.width() 2 >>> u'\u305f\u3099'.width() 4 Width should be two in both cases. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-02 01:01 Message: Logged In: YES user_id=55188 Here's my revised patch for new API. :) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 21:31 Message: Logged In: YES user_id=38388 Great ! Thanks. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-23 21:29 Message: Logged In: YES user_id=55188 Yes. I am. I was little bit busy. I'll submit new patch after this weekend. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 19:12 Message: Logged In: YES user_id=38388 Hye-Shik, are you working on a patch to move the implementation as suggested ? Just asking, because I don't was the current layout to go into the Python 2.4 final... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-16 02:36 Message: Logged In: YES user_id=38388 Martin, you can code such a function in your application based on the information you'd get from unicodedata.east_asian_width(). As we've seen, there is no generally sound way to define such a function. As for the location of the data: the unicodedata module is the place where any extra information related to Unicode should go. unicodectype.c is reserved for data needed at C level by the Python Unicode C API. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-16 02:24 Message: Logged In: YES user_id=21627 I still think a function is useful which computes the number of Ems that a conventional application would expect. That function should raise an exception for a neutral character - the example of the combining characters shows that such characters should *not* be treated as narrow "for all practical purposes". Whether or not it is useful to include the entire UAX#11 classification in the database I don't know - it seems the only application of the data would be computation of the width, anyway. It would not be wise to move the data to the unicode database, as the extra data currently don't affect Python programs that don't use the function, anyway - the data does not consume any additional space. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-15 18:39 Message: Logged In: YES user_id=38388 Hye-Shik, the patch only includes the move to unicodedata, but not the full implementation of the EAW as per the TR. I would much prefer to have the east_asian_width() function return the strings defined in the TR because this allows users of the function to read the information and implement their own interpretation of "width". The new function should work very much like unicodedata.category(). It would also be wise to move the data itself over to the unicode database - that way the extra data does not affect Python programs that don't use the function. Thanks. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-15 00:15 Message: Logged In: YES user_id=55188 Marc-Andre, here's a patch written as you've suggested. Can you please give a review on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-13 04:41 Message: Logged In: YES user_id=38388 Thanks for your descriptions, Hye-Shik. Since the application space is very much targetted at East Asian scripts, I would like the implementation to be moved into unicodedata where all the other special Unicode features are implemented. The .width() method should be removed. Now that I understand better what the EAW is about, I would also like to see the function be renamed to east_asian_width() since that's what the function is based on. If possible, I'd also rather like to see the full width mapping implemented (as defined in the TR). The reduction to narrow vs. wide seems to be oversimplified. The east_asian_width() function should return the characters: "N", "A", "H", "W", "F", "Na" and let the user decide how to map these to character or string widths. We have followed the same methodology for the other Unicode database properties and this has not only given us much more flexibility, it also is standards compliant and you can get good documentation on these features. Matthew, I suggest you write your own implementation of what you think is right. In the face of ambiguity, there's no such thing as the right approach to a certain problem. Thanks. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-13 01:03 Message: Logged In: YES user_id=65253 My complaint was that you were attacking my example using non-asian characters, when the TR specifically says they are handled as narrow. I write Asian characters the same as anything else. If it's a unicode string python converts it with sys.stdout.encoding (for print anyway). Otherwise you just have to write in whatever encoding the terminal expects. And when you are talking about a fixed-width text terminal, wide characters take 2 columns, narrow take 1. Assuming you ignore combining characters, which is what this is all about. You said the width is only a "hint for rendering engines", but I cannot think of any rendering engine that would benefit from a hint that can be 2-3x wider (due to counting combining characters) than when you actually display it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-13 00:53 Message: Logged In: YES user_id=55188 Major usages that I expected for width() are: - Hints for terminal-based applications (for cursor position and layouts) - To generate fixed-width text documents not ugly: eg. printing "------" decoration under each subjects. - More readable limit for table columns: eg. topics in web bulletins; limiting by same 'characters' will recur very wide some topic lines full of East Asian characters and narrow snipped english topics. - To locate "^" in correct position on Python tracebacks. This isn't implemented in standard traceback, but width() allows 3rd party can implement sys.excepthook for East Asian easily. In fact, I don't known if width() can easily modified to support variety of combining characters from Western characters. But if it isn't too heavy or complicated, I would volunteer to extend the width() implemention to make it provide generic fixed-width rendering hint. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-13 00:23 Message: Logged In: YES user_id=38388 I don't understand your complaint: width 1 means "narrow" just as defined in the TR ?! How do you write Asian characters to a terminal ? I think you are mixing glyphs with code points here. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 23:28 Message: Logged In: YES user_id=65253 TR11 says "Strictly speaking, it makes no sense to talk of narrow and wide for neutral characters, but since for all practical purposes they behave like Na, they are treated as narrow characters (the same as Na) under the recommendations below." In addition, the current implementation gives a width of 1 to not east asian characters. So talking about fixing the effect of combining characters on non-east asian charecters is IMHO, just as applicable as combining characters on asian text. And for display width, I'd say it is useful when writing to a terminal. But not it its current form. Combining characters obviously have no width, whether they are "wide"(which just means they are normally combined with wide characters) or not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 23:00 Message: Logged In: YES user_id=38388 It would help if you would include the Unicode code point descriptions... 01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER Z BAR;;;01B6; 0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;; 0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING DIAERESIS;Dialytika;;; Ie. your example does not even include East Asian characters. If you read the TR11, you'll find that: """ ED7. Not East Asian (Neutral) - all other characters. Neutral characters do not occur in legacy East Asian character sets. By extension, they also do not occur in East Asian typography. For example, there is no traditional Japanese way of typesetting Devanagari. Strictly speaking, it makes no sense to talk of narrow and wide for neutral characters, but since for all practical purposes they behave like Na, they are treated as narrow characters (the same as Na) under the recommendations below. """ Combining marks as the ones that your example uses cannot be processed by doing a simple database lookup. The two marks you include are marked as A -- Ambiguous. Furthermore, you should not mistake the East Asian Width for the display width. It is merely a hint for rendering engines. See the TR for details. Hye-Shik, could you give an example of where the EAS is actually useful in Python programming ? I hvae a feeling that it is going to cause more confusion than do good. It may also be wise to rename the function to east_asian_width() to signal that the return value does not have anything to do with a display with, glyphs, etc. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 22:06 Message: Logged In: YES user_id=65253 I don't think normalization is sufficient. For example, consider: >>> u'\u01b5\u0327\u0308'.width() 3 >>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width() 3 But width should be one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 18:45 Message: Logged In: YES user_id=38388 To be honest: I don't really know how .width() ended up as method. The use context seems to be rather limited in that it only applies to East Asian code points according to Unicode Standard Annex #11. I'd suggest to move the whole implementation to unicodedata instead (and then apply normalization before looking up the width). Reading the UAX11 (http://www.unicode.org/reports/tr11/) I also have a feeling that taking the sum of all widths in a string of Unicode code points is not a very useful approach. Since the width is mainly used for rendering East Asian text, only the per code point information is useful. I think that it would be more appropriate to raise an exception if you pass in more than one code point to the function. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-12 13:46 Message: Logged In: YES user_id=55188 This sounds that we need to normalize to NFC before evaluations for unicode.width(). So, I think we'll need to choose how to use normalization database from width() method. 1. export normalization CAPI functions from unicodedata module like ucnhash_CAPI and unicodeobject uses it when width() is first called. 2. move unicode.width() to unicodedata module and use normalization functions statically. I would prefer 2. ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470 From noreply at sourceforge.net Sun Aug 1 21:20:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 1 21:20:18 2004 Subject: [ python-Bugs-1001604 ] glob unicode Message-ID: Bugs item #1001604, was opened at 2004-08-01 19:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001604&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) Summary: glob unicode Initial Comment: #Here is the script #Python 2.3 on W2K import glob name = glob.glob(u"./*.mp3")[0] print type(name) name = glob.glob(u"*.mp3")[0] print type(name) ##OUTPUT## # # #The second line should be too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001604&group_id=5470 From noreply at sourceforge.net Mon Aug 2 00:37:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 00:37:18 2004 Subject: [ python-Bugs-1001088 ] incorrect reference to macro named foo Message-ID: Bugs item #1001088, was opened at 2004-07-31 02:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001088&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Clinton Roy (clintonroy) >Assigned to: Neal Norwitz (nnorwitz) Summary: incorrect reference to macro named foo Initial Comment: Hi guys, In _Documenting Python_, section 4.1 Syntax, a paragraph begins: For example, a macro named ``foo'' which takes a single parameter would appear like this: But the example macros use the name `name' instead of `foo'. Since it's quite obvious what's going on, I suggest the reference to foo is lost, so the leading sentence becomes: For example, a macro wich takes a single parameter would appear like this: cheers, ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-01 18:37 Message: Logged In: YES user_id=33168 Thanks! Checked in as: doc/doc.tex 1.87 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-07-31 02:45 Message: Logged In: YES user_id=671362 FYI, this is the address of the page Clinton is talking about. http://www.python.org/doc/2.3.4/doc/latex-syntax.html http://www.python.org/dev/doc/devel/doc/latex-syntax.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001088&group_id=5470 From noreply at sourceforge.net Mon Aug 2 00:48:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 00:48:22 2004 Subject: [ python-Bugs-1001053 ] wave.open() with unicode filename fails Message-ID: Bugs item #1001053, was opened at 2004-07-30 23:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001053&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John Popplewell (johnnypops) >Assigned to: Neal Norwitz (nnorwitz) Summary: wave.open() with unicode filename fails Initial Comment: If you pass a unicode string to wave.open() it is treated as if it was an open file object and fails with an AttributeError. For example, the following code behaves correctly: import wave f = wave.open("sound.wav", "r") but this fails: import wave f = wave.open(u"sound.wav", "r") ... AttributeError: 'unicode' object has no attribute 'read' The error occurs twice in the file 'wave.py' in the __init__ functions for Wave_read and Wave_write. I was playing with the unicode version of wxPython on Windows XP at the time, but the bug applies to other platforms as well. Hope the patch is of use, best regards, John. ---8<--------------------------------------------------------------- 158c158 < if type(f) == type(''): --- > if isinstance(f, basestring): 297c297 < if type(f) == type(''): --- > if isinstance(f, basestring): ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-01 18:48 Message: Logged In: YES user_id=33168 Thanks! Checked in as Lib/wave.py 1.18 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001053&group_id=5470 From noreply at sourceforge.net Mon Aug 2 01:38:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 01:39:00 2004 Subject: [ python-Bugs-1001018 ] setdefaulttimeout causes unnecessary timeouts on connect err Message-ID: Bugs item #1001018, was opened at 2004-07-31 11:07 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) >Assigned to: Guido van Rossum (gvanrossum) Summary: setdefaulttimeout causes unnecessary timeouts on connect err Initial Comment: This looks like a bug to me: >>> import socket, httplib >>> socket.setdefaulttimeout(10) >>> httplib.HTTPConnection("www.python.org", 9999).connect() [.... 10 second delay ....] Traceback (most recent call last): File "", line 1, in ? File "e:\src\python-cvs\lib\httplib.py", line 548, in connect raise socket.error, msg socket.timeout: timed out >>> On Linux, there is no significant delay, and the traceback reads: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/httplib.py", line 548, in connect raise socket.error, msg socket.error: (111, 'Connection refused') The linux result is what I expected on Windows. Sockets aren't my strong point, so I'd prefer someone confirming it is a real bug before I burn too much time on it. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-08-02 09:38 Message: Logged In: YES user_id=14198 Guido - it looks like this change was made by you in Rev 1.257. Can you please confirm the new behaviour is not correct and I will try and dig a little deeper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 From noreply at sourceforge.net Mon Aug 2 01:53:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 01:53:19 2004 Subject: [ python-Feature Requests-960454 ] old/new class documentation Message-ID: Feature Requests item #960454, was opened at 2004-05-25 18:33 Message generated for change (Comment added) made by eldiener You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: old/new class documentation Initial Comment: The distributed documentation refers to old and new-style classes, but they do not appear in the index, and the difference is not explained. (Users who ask are referred to documentation on www.python.org, which is not currently shipped with the default distrubution.) As best I understand it, the only differences are: (1) New-style classes inherit from object. Because of this inheritance, new-style classes have a few extra capabilities, such as descriptors and super. (2) Method Resolution Order can be different in cases of multiple inheritance. (3) New style classes take precedence over old-style classes when doing rich comparison. (4) If rich comparison fails, numeric coercion will be attempted if -- and only if -- at least one of the objects is an old-style class. ---------------------------------------------------------------------- Comment By: Edward Diener (eldiener) Date: 2004-08-01 19:53 Message: Logged In: YES user_id=490593 New style classes, with all their new attributes, member functions, static methods, and class methods, need to be documented in the official Python distribution. Included in this is the explanation of metaclasses and how to use them. Essentially Guido's paper on new style classes, reworked to fit within the existing documentation framework, should be added to the official documantation.. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 11:21 Message: Logged In: YES user_id=764593 Found a new difference -- you can't assign to the __bases__ or __name__ of a new-style class, and you can't usually assign to it's __class__. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 10:05 Message: Logged In: YES user_id=764593 Given that the differences are almost -- but not entirely -- extra options for new-style classes, the language lawyer section on classes (ref/7.6) might be a good location. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&group_id=5470 From noreply at sourceforge.net Mon Aug 2 02:31:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 02:31:38 2004 Subject: [ python-Bugs-1001018 ] setdefaulttimeout causes unnecessary timeouts on connect err Message-ID: Bugs item #1001018, was opened at 2004-07-30 21:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Guido van Rossum (gvanrossum) Summary: setdefaulttimeout causes unnecessary timeouts on connect err Initial Comment: This looks like a bug to me: >>> import socket, httplib >>> socket.setdefaulttimeout(10) >>> httplib.HTTPConnection("www.python.org", 9999).connect() [.... 10 second delay ....] Traceback (most recent call last): File "", line 1, in ? File "e:\src\python-cvs\lib\httplib.py", line 548, in connect raise socket.error, msg socket.timeout: timed out >>> On Linux, there is no significant delay, and the traceback reads: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/httplib.py", line 548, in connect raise socket.error, msg socket.error: (111, 'Connection refused') The linux result is what I expected on Windows. Sockets aren't my strong point, so I'd prefer someone confirming it is a real bug before I burn too much time on it. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-01 20:31 Message: Logged In: YES user_id=31435 I can confirm that Guido certainly didn't intend for a refused connection to wait for the timeout on Windows. A problem is that the attempt to connect here isn't returning WSAECONNREFUSED on Windows, it's returning WSAEWOULDBLOCK. If you set the default timeout back to None, the attempt to connect *does* return WSAECONNREFUSED on Windows. But for whatever reason, the Windows implementation of sockets appears to turn that into WSAEWOULDBLOCK if (and only if) the socket is in non-blocking mode. The problem then is trying to guess some way to figure out whether WSAEWOULDBLOCK on a Windows non-blocking socket connect *means* "there's no chance this will ever succeed" or "I can't connect immediately, but maybe I can later". It appears to mean both things . Note this: >>> s = socket.socket() >>> s.setblocking(0) >>> s.connect(("www.python.org", 9999)) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (10035, 'The socket operation could not complete without blocking') Now at this point, the code essentially does this: >>> select.select([], [s], [], 10.0) ([], [], []) >>> and select waits 10 seconds before returning. However, if we do this instead (I'm adding a non- empty "error/exception" list argument): >>> select.select([], [s], [s], 10.0) ([], [], []) >>> then it returns immediately, with the socket in the exception list. So that's a clue. How can we tell *what* error occurred? Hmm. For the exception list, MS select docs say a socket will appear there when: "If processing a connect call (nonblocking), connection attempt failed " So the behavior so far matches the docs. Later it says """ If a socket is processing a connect call (nonblocking), failure of the connect attempt is indicated in exceptfds (application must then call getsockopt SO_ERROR to determine the error value to describe why the failure occurred). This document does not define which other errors will be included. """ So there you go : we have to add the socket to the select call's exception set. Then the select call won't wait forever. When it comes back, and there is an exception, we have to call getsockopt() with SO_ERROR to determine the cause. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-01 19:38 Message: Logged In: YES user_id=14198 Guido - it looks like this change was made by you in Rev 1.257. Can you please confirm the new behaviour is not correct and I will try and dig a little deeper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 From noreply at sourceforge.net Mon Aug 2 10:26:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 10:26:45 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 11:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Mon Aug 2 10:41:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 10:41:03 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 11:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Mon Aug 2 10:45:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 10:46:03 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 03:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 03:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Mon Aug 2 11:05:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 11:05:21 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 11:41 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 12:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 11:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Mon Aug 2 11:48:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 11:48:42 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: Nobody/Anonymous (nobody) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Mon Aug 2 12:07:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 12:07:41 2004 Subject: [ python-Bugs-1001018 ] setdefaulttimeout causes unnecessary timeouts on connect err Message-ID: Bugs item #1001018, was opened at 2004-07-31 11:07 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Guido van Rossum (gvanrossum) Summary: setdefaulttimeout causes unnecessary timeouts on connect err Initial Comment: This looks like a bug to me: >>> import socket, httplib >>> socket.setdefaulttimeout(10) >>> httplib.HTTPConnection("www.python.org", 9999).connect() [.... 10 second delay ....] Traceback (most recent call last): File "", line 1, in ? File "e:\src\python-cvs\lib\httplib.py", line 548, in connect raise socket.error, msg socket.timeout: timed out >>> On Linux, there is no significant delay, and the traceback reads: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/httplib.py", line 548, in connect raise socket.error, msg socket.error: (111, 'Connection refused') The linux result is what I expected on Windows. Sockets aren't my strong point, so I'd prefer someone confirming it is a real bug before I burn too much time on it. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-08-02 20:07 Message: Logged In: YES user_id=14198 Thanks Tim! It looks like this patch works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-02 10:31 Message: Logged In: YES user_id=31435 I can confirm that Guido certainly didn't intend for a refused connection to wait for the timeout on Windows. A problem is that the attempt to connect here isn't returning WSAECONNREFUSED on Windows, it's returning WSAEWOULDBLOCK. If you set the default timeout back to None, the attempt to connect *does* return WSAECONNREFUSED on Windows. But for whatever reason, the Windows implementation of sockets appears to turn that into WSAEWOULDBLOCK if (and only if) the socket is in non-blocking mode. The problem then is trying to guess some way to figure out whether WSAEWOULDBLOCK on a Windows non-blocking socket connect *means* "there's no chance this will ever succeed" or "I can't connect immediately, but maybe I can later". It appears to mean both things . Note this: >>> s = socket.socket() >>> s.setblocking(0) >>> s.connect(("www.python.org", 9999)) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (10035, 'The socket operation could not complete without blocking') Now at this point, the code essentially does this: >>> select.select([], [s], [], 10.0) ([], [], []) >>> and select waits 10 seconds before returning. However, if we do this instead (I'm adding a non- empty "error/exception" list argument): >>> select.select([], [s], [s], 10.0) ([], [], []) >>> then it returns immediately, with the socket in the exception list. So that's a clue. How can we tell *what* error occurred? Hmm. For the exception list, MS select docs say a socket will appear there when: "If processing a connect call (nonblocking), connection attempt failed " So the behavior so far matches the docs. Later it says """ If a socket is processing a connect call (nonblocking), failure of the connect attempt is indicated in exceptfds (application must then call getsockopt SO_ERROR to determine the error value to describe why the failure occurred). This document does not define which other errors will be included. """ So there you go : we have to add the socket to the select call's exception set. Then the select call won't wait forever. When it comes back, and there is an exception, we have to call getsockopt() with SO_ERROR to determine the cause. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 09:38 Message: Logged In: YES user_id=14198 Guido - it looks like this change was made by you in Rev 1.257. Can you please confirm the new behaviour is not correct and I will try and dig a little deeper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 From noreply at sourceforge.net Mon Aug 2 12:16:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 12:16:48 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by peter_jacobi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: Nobody/Anonymous (nobody) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Mon Aug 2 12:20:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 12:20:26 2004 Subject: [ python-Bugs-930024 ] os.path.realpath can't handle symlink loops Message-ID: Bugs item #930024, was opened at 2004-04-05 22:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=930024&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Open Resolution: Fixed >Priority: 7 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.realpath can't handle symlink loops Initial Comment: Create a symlink pointing to itself: ln -s infinite infinite Run os.path.realpath() on it, and it recurses infinitely (until the stack limit is hit): >>> import os >>> os.path.realpath('/home/amk/infinite') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/posixpath.py", line 416, in realpath return realpath(newpath) os.path.realpath() should be fixed; /home/amk/infinite is a perfectly good path, though it can't be followed. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:20 Message: Logged In: YES user_id=21627 The code that has been committed is incorrect if the link to be resolved is relative. _resolve_link uses abspath to determine whether the link is absolute. This function returns an absolute path (possibly using getcwd); the function that should have been used is isabs(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-11 00:59 Message: Logged In: YES user_id=357491 Applied as rev. 1.67 in 2.4a2 and rev. 1.62.6.2 in 2.3.5 with only minor cleanup. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-05 20:58 Message: Logged In: YES user_id=11375 Patch attached; review requested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=930024&group_id=5470 From noreply at sourceforge.net Mon Aug 2 12:30:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 12:30:22 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) >Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Mon Aug 2 12:42:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 12:42:09 2004 Subject: [ python-Bugs-992397 ] variable reuse in the logging module Message-ID: Bugs item #992397, was opened at 2004-07-16 15:18 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992397&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Gintautas Miliauskas (gintautasm) >Assigned to: Vinay Sajip (vsajip) Summary: variable reuse in the logging module Initial Comment: I accidentally tried to pass logging levels as strings to Logger.log() instead of numbers. The result was that %(levelname)s produced the number of the level specified and %(levelno)s produced the name... I assumed that passing strings was valid, because if you passed an unregistered level name, the %(levelname)s would just say 'Level XYZ' instead of 'XYZ'. The culprit is this dict in logging/__init__.py: _levelNames = { CRITICAL : 'CRITICAL', ERROR : 'ERROR', WARNING : 'WARNING', INFO : 'INFO', DEBUG : 'DEBUG', NOTSET : 'NOTSET', 'CRITICAL' : CRITICAL, 'ERROR' : ERROR, 'WARN' : WARNING, 'WARNING' : WARNING, 'INFO' : INFO, 'DEBUG' : DEBUG, 'NOTSET' : NOTSET, } I think it would be a good idea to split this dict into two, so that such confusion doesn't result. Also, it should be explicitly stated (in the docs and maybe in code too) if a name of the level as a string argument to Logger.log() is valid or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992397&group_id=5470 From noreply at sourceforge.net Mon Aug 2 13:14:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 13:14:15 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-02 13:14 Message: Logged In: YES user_id=38388 Martin, I think it's a good idea to add the codecs for completeness. We should probably also review the mapping files posted on the unicode.org site every now and then and update the codecs in Python accordingly. Sticking to the Unicode Consortium's view of things is a good way to assure compatibility with other applications, IMO. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Mon Aug 2 14:56:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 14:56:15 2004 Subject: [ python-Bugs-808596 ] leaking snippet Message-ID: Bugs item #808596, was opened at 2003-09-18 15:48 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: leaking snippet Initial Comment: Raymond Hettinger found that the following: fd, fname = tempfile.mkstemp() execfile(fname) leaks a reference. TrackRefs sez it's a string. Haven't dug any further. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-02 13:56 Message: Logged In: YES user_id=6656 I've finally worked out what's going on here. It's because compiling the file interns the name of the file being compiled. Now that interned strings are mortal, this isn't a big deal, but it still results in a string being added to and removed from the interned strings dictionary with net result (almost all of the time) of incrementing the refcount on 'dummy' by one. Once in every thousand or so iterations this results in the interned string dictionary being resized and throwing all the references to dummy away, so this isn't a 'real' leak. OTOH, I'd still like to do something about this (as is, test_pkg appears to leak 10 references per run because of this). The simplest thing would be to just plain not intern the filename during compilation (I find it hard to believe that it's of any real benefit). The more invasive solution would be to not do refcounting on dummy (assuming that's even possible) which is a scarier change, but would stop similar problems with other tests (I have a feeling that test_pkgimport appears to be leaking references because of a different incarnation of the same problem). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 From noreply at sourceforge.net Mon Aug 2 16:22:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 16:23:04 2004 Subject: [ python-Bugs-808756 ] refleaks in _hotshot.c Message-ID: Bugs item #808756, was opened at 2003-09-18 19:01 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: refleaks in _hotshot.c Initial Comment: My regrtest patches revealed a few leaks in Modules/_hotshot.c. Attached patch seems to fix. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-02 15:22 Message: Logged In: YES user_id=6656 This patch is still necessary, still applies and still fixes the leaks. Any objections to just checking it in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-22 14:28 Message: Logged In: YES user_id=31435 Just attaching Armin's patch (hotshot2.diff). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-22 13:01 Message: Logged In: YES user_id=4771 Unless I'm mistaken there is a misplaced DECREF. I'd love to attach my patch but cannot do so. Here it is: http://arigo.tunes.org/hotshot2.diff A more general note is about using 'N' in Py_BuildValue. Its implementation seems to be buggy because it does not always consume a reference: it won't do so if an error occurs before it gets there. I guess I'll submit a separate bug report/patch for this too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470 From noreply at sourceforge.net Mon Aug 2 16:25:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 16:25:53 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-31 01:08 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-02 15:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Mon Aug 2 16:29:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 16:29:53 2004 Subject: [ python-Bugs-1001018 ] setdefaulttimeout causes unnecessary timeouts on connect err Message-ID: Bugs item #1001018, was opened at 2004-07-30 21:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Guido van Rossum (gvanrossum) Summary: setdefaulttimeout causes unnecessary timeouts on connect err Initial Comment: This looks like a bug to me: >>> import socket, httplib >>> socket.setdefaulttimeout(10) >>> httplib.HTTPConnection("www.python.org", 9999).connect() [.... 10 second delay ....] Traceback (most recent call last): File "", line 1, in ? File "e:\src\python-cvs\lib\httplib.py", line 548, in connect raise socket.error, msg socket.timeout: timed out >>> On Linux, there is no significant delay, and the traceback reads: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/httplib.py", line 548, in connect raise socket.error, msg socket.error: (111, 'Connection refused') The linux result is what I expected on Windows. Sockets aren't my strong point, so I'd prefer someone confirming it is a real bug before I burn too much time on it. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-02 10:29 Message: Logged In: YES user_id=31435 I suspect the patch is close but not quite there yet. I believe select will return 1 now if the socket is in *either* of the writable or exception sets upon select's return, so that the patch loses the distinction between "ok, we finally connected" and "oops -- we can't connect". If so, to untangle that we need to pass in *distinct* sets to select, and when the return is > 0 it's an error case if and only if FS_SET then says the socket is in the exception set. If the socket is in the writable set instead, then the connect succeeded. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 06:07 Message: Logged In: YES user_id=14198 Thanks Tim! It looks like this patch works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-01 20:31 Message: Logged In: YES user_id=31435 I can confirm that Guido certainly didn't intend for a refused connection to wait for the timeout on Windows. A problem is that the attempt to connect here isn't returning WSAECONNREFUSED on Windows, it's returning WSAEWOULDBLOCK. If you set the default timeout back to None, the attempt to connect *does* return WSAECONNREFUSED on Windows. But for whatever reason, the Windows implementation of sockets appears to turn that into WSAEWOULDBLOCK if (and only if) the socket is in non-blocking mode. The problem then is trying to guess some way to figure out whether WSAEWOULDBLOCK on a Windows non-blocking socket connect *means* "there's no chance this will ever succeed" or "I can't connect immediately, but maybe I can later". It appears to mean both things . Note this: >>> s = socket.socket() >>> s.setblocking(0) >>> s.connect(("www.python.org", 9999)) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (10035, 'The socket operation could not complete without blocking') Now at this point, the code essentially does this: >>> select.select([], [s], [], 10.0) ([], [], []) >>> and select waits 10 seconds before returning. However, if we do this instead (I'm adding a non- empty "error/exception" list argument): >>> select.select([], [s], [s], 10.0) ([], [], []) >>> then it returns immediately, with the socket in the exception list. So that's a clue. How can we tell *what* error occurred? Hmm. For the exception list, MS select docs say a socket will appear there when: "If processing a connect call (nonblocking), connection attempt failed " So the behavior so far matches the docs. Later it says """ If a socket is processing a connect call (nonblocking), failure of the connect attempt is indicated in exceptfds (application must then call getsockopt SO_ERROR to determine the error value to describe why the failure occurred). This document does not define which other errors will be included. """ So there you go : we have to add the socket to the select call's exception set. Then the select call won't wait forever. When it comes back, and there is an exception, we have to call getsockopt() with SO_ERROR to determine the cause. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-01 19:38 Message: Logged In: YES user_id=14198 Guido - it looks like this change was made by you in Rev 1.257. Can you please confirm the new behaviour is not correct and I will try and dig a little deeper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 From noreply at sourceforge.net Mon Aug 2 17:11:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 17:11:40 2004 Subject: [ python-Bugs-808596 ] leaking snippet Message-ID: Bugs item #808596, was opened at 2003-09-18 09:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: leaking snippet Initial Comment: Raymond Hettinger found that the following: fd, fname = tempfile.mkstemp() execfile(fname) leaks a reference. TrackRefs sez it's a string. Haven't dug any further. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 10:11 Message: Logged In: YES user_id=80475 Not interning the filename seems cleanest. Like you, I do not expect that interning provided any real benefit here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 07:56 Message: Logged In: YES user_id=6656 I've finally worked out what's going on here. It's because compiling the file interns the name of the file being compiled. Now that interned strings are mortal, this isn't a big deal, but it still results in a string being added to and removed from the interned strings dictionary with net result (almost all of the time) of incrementing the refcount on 'dummy' by one. Once in every thousand or so iterations this results in the interned string dictionary being resized and throwing all the references to dummy away, so this isn't a 'real' leak. OTOH, I'd still like to do something about this (as is, test_pkg appears to leak 10 references per run because of this). The simplest thing would be to just plain not intern the filename during compilation (I find it hard to believe that it's of any real benefit). The more invasive solution would be to not do refcounting on dummy (assuming that's even possible) which is a scarier change, but would stop similar problems with other tests (I have a feeling that test_pkgimport appears to be leaking references because of a different incarnation of the same problem). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 From noreply at sourceforge.net Mon Aug 2 17:32:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 17:32:08 2004 Subject: [ python-Bugs-808756 ] refleaks in _hotshot.c Message-ID: Bugs item #808756, was opened at 2003-09-18 14:01 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Armin Rigo (arigo) Summary: refleaks in _hotshot.c Initial Comment: My regrtest patches revealed a few leaks in Modules/_hotshot.c. Attached patch seems to fix. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-02 11:32 Message: Logged In: YES user_id=3066 I just looked over Armin's version of the patch, and it looks good to me. Armin, please go ahead and commit, and close this report. This should be backported to 2.3.x as well; I think the patch should apply cleanly to the branch as well as the trunk. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 10:22 Message: Logged In: YES user_id=6656 This patch is still necessary, still applies and still fixes the leaks. Any objections to just checking it in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-22 09:28 Message: Logged In: YES user_id=31435 Just attaching Armin's patch (hotshot2.diff). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-22 08:01 Message: Logged In: YES user_id=4771 Unless I'm mistaken there is a misplaced DECREF. I'd love to attach my patch but cannot do so. Here it is: http://arigo.tunes.org/hotshot2.diff A more general note is about using 'N' in Py_BuildValue. Its implementation seems to be buggy because it does not always consume a reference: it won't do so if an error occurs before it gets there. I guess I'll submit a separate bug report/patch for this too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470 From noreply at sourceforge.net Mon Aug 2 20:55:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 2 20:55:40 2004 Subject: [ python-Bugs-870382 ] Mingw needs to use the same MSVC runtime as Python Message-ID: Bugs item #870382, was opened at 2004-01-04 15:55 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470 Category: Distutils Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L?wis (loewis) Summary: Mingw needs to use the same MSVC runtime as Python Initial Comment: Python 2.4 is now built with MSVC 7.1, which uses a new MSVC runtime library. Extension DLLs should be built to use the same runtime DLL as Python itself (although it has not been possible to find a real-world example where not doing so causes a problem...) The attached patch adds the appropriate -l flag to the link, based on the MSVC version reported in sys.version. (This has only been tested with a Python built with MSVC 7.1, the version number used for MSVC 7.0 is based on verbal reports only). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-07-29 22:19 Message: Logged In: YES user_id=113328 Can someone suggest what I need to do to get this patch, or something similar, accepted? As things stand, the official Python 2.4 build *does not support* building compatible extensions with mingw, where 2.3 did. I have no means of extending this patch to work with user-built versions of Python - I don't currently have any way of building Python for myself, to test any such change. I don't object to someone making such an extension, but I have seen no-one step forward. I'm getting a little frustrated here. The arguments against applying the patch seem largely theoretical (and outside my expertise). I'd like to invoke "practicality beats purity" here... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-16 13:19 Message: Logged In: YES user_id=11105 In principle, it would be possible to examine the import table of pythonxy.dll, to find out to which msvcrXX.dll it is linked to. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-07-15 06:40 Message: Logged In: YES user_id=552329 FWIW, this patch works for me, and I'd definitely like to see it in 2.4a2. If the MSVC version isn't 1300 or 1310 (the theoretical 1400, for example), then it doesn't do anything different to what 2.4a1 does, so it's hard to see why that would be a problem (and with the patch applied, there's a clear fix, just adding in the appropriate elif and link - it's not like new versions come along all the time). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-07-09 13:17 Message: Logged In: YES user_id=113328 This is still an issue with 2.4a1. I'm not sure what the autodetection buys given that currently it's not possible to build extensions with 2.4a1 using mingw which are compatible with the stock python.org binary. Can I suggest that this patch be applied, and issues around autodetection be deferred until there is a demonstrated need? I've uploaded a revised patch for 2.4a1 (tested against the python.org supplied MSI). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-05 22:30 Message: Logged In: YES user_id=21627 I'm primarily concerned about future (unreleased-as-of-today) MSC versions; they likely have version numbers like "1400"; linking msvcr71 to binaries built with that compiler is likely wrong. Not adding anything for gcc-built python versions is fine. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-01-05 00:01 Message: Logged In: YES user_id=113328 What about Python built with mingw? I don't think that's possible right now, but I'd expect people to work on it. And I've no idea what sys.version for that would be. The only real cases are likely to be MSVC 7.1 (Python 2.4, binary dist), MSVC 6 (Python <= 2.3, binary dist) and hand- built Python versions. The patch does the right thing for all the binary distributions, which are the ones where the user can't be assumed to know how to hack things to make them work. For hand-built versions, the user can do "python setup.py build_ext --compiler=mingw32 -l msvcr71" (or whatever) to manually specify the runtime to use. Leaving the default as msvcrt (the CRT that comes with the OS, and is default for mingw) seems right - and better than aborting (particularly as I'm not sure how to check whether there's an -l option for the CRT specified by the user). The best I could do is effectively to force build_ext to fail unless Python was built with MSVC, which seems unhelpful... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-04 16:03 Message: Logged In: YES user_id=21627 Could you add some kind of assertion to detect the case that an entirely different compiler version is used? It would be best if it gets the case of using MSVC6 right, and gives up if some other compiler version is detected (I can't determine os.version for the VC6 case right now, but Python 2.3 is built with it). Apart from that, the patch looks good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470 From noreply at sourceforge.net Tue Aug 3 00:14:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 00:15:03 2004 Subject: [ python-Bugs-996392 ] math and cmath docs don't specify radians Message-ID: Bugs item #996392, was opened at 2004-07-23 03:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: math and cmath docs don't specify radians Initial Comment: The math and cmath functions take their parameters in radians, but there is nothing stating this. The closest is "The math module consists mostly of thin wrappers around the platform C math library functions.". For starters, are we guaranteed that the platform math functions take radians? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-02 18:14 Message: Logged In: YES user_id=33168 Tim (Peters), did you want to do anything else on this or should it be closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-24 19:04 Message: Logged In: YES user_id=31435 I checked in a major rewrite of the math module docs, as Doc/lib/libmath.tex revision 1.32. This stuffed in "radians" as appropriate (among other things). Note that the function docstrings already told the radiaion story; e.g., >>> print math.cos.__doc__ cos(x) Return the cosine of x (measured in radians). >>> I didn't change the cmath docs, and don't intend to. Anyone using complex "angles" who doesn't already know they're working in radians shouldn't be allowed to import cmath <0.6 wink>. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-24 16:27 Message: Logged In: YES user_id=80475 Yes, the platform math lib will be in radians. You're welcome to submit a clarifying doc patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470 From noreply at sourceforge.net Tue Aug 3 00:18:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 00:18:15 2004 Subject: [ python-Bugs-991735 ] os.access reports true for read-only directories Message-ID: Bugs item #991735, was opened at 2004-07-15 13:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Moales (mmoales) Assigned to: Nobody/Anonymous (nobody) Summary: os.access reports true for read-only directories Initial Comment: It appears that os.access incorrectly reports write access to directories on network drives. For example, if I have a read-only directory called foo\bar on a machine called homeserver, the following code always returns true: print os.access("\\homeserver\foo\bar", os.W_OK) True Similarly, if I map above directory to a drive, the results are the same, i.e.: print os.access("H:\bar", os.W_OK) True However, if I try to create a file in that directory, I get a permission error: f = file("h:\foo\bar\test.txt", 'w+b') Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 13] Permission denied: 'h:\foo\bar\test.txt' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-02 18:18 Message: Logged In: YES user_id=33168 Mark or mkc, can you suggest wording to improve the docs? Thanks. ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-07-29 15:28 Message: Logged In: YES user_id=555 The submitter seems to want os.access to agree with the subsequent behavior of I/O operation, but this is not possible for all cases. The NFS spec, for example, allows NFS servers to deny operations in a capricious manner, over and above any denial that might be due to permissions bits and/or a volume "read only" flag. I don't know if there is an SMB/CIFS server spec, but one could imagine the same thing happening there. It might be possible to add ACL checking to the Windows version of os.access, if a Windows person thinks it's worthwhile. It probably would be valuable to add a clarification to the os.access doc. For example: Note that I/O operations may fail even when the access function indicates that they would succeed, particularly for operations on network filesystems, which may have permissions semantics beyond the usual POSIX permission-bit model. (Also, if someone does this, please update the doc to note that access returns True and False, not 1 and 0.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-15 16:59 Message: Logged In: YES user_id=31435 Heh -- I didn't know it either, Thomas. But I've also noticed how many new Windows bugs get assigned to you, and got curious enough to dig into it. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2004-07-15 15:25 Message: Logged In: YES user_id=565165 This may not be a bug afterall. I think it has to do with Window's ACLs. I believe os.access is just looking at access bits. For example, I can create a directory and leave it as writable, but prevent access to it via an ACL. In this case, os.access reports true, but any operation you try to perform on the dictionary get's a permission error. It might just need to be mentioned in the os.access doc. Thomas: no problem ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-15 15:20 Message: Logged In: YES user_id=11105 Tim: I didn't know that. Thanks for disabling it. Mark: Sorry, it wasn't your fault. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-15 14:56 Message: Logged In: YES user_id=31435 The tracker was set to auto-assign Windows reports to you, Thomas. I disabled that (and Windows reports will be assigned to None by default now). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-15 14:41 Message: Logged In: YES user_id=11105 Please don't assign windows bugs to me. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470 From noreply at sourceforge.net Tue Aug 3 01:01:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 01:01:12 2004 Subject: [ python-Bugs-996392 ] math and cmath docs don't specify radians Message-ID: Bugs item #996392, was opened at 2004-07-23 03:18 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Tim Peters (tim_one) Summary: math and cmath docs don't specify radians Initial Comment: The math and cmath functions take their parameters in radians, but there is nothing stating this. The closest is "The math module consists mostly of thin wrappers around the platform C math library functions.". For starters, are we guaranteed that the platform math functions take radians? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-02 19:01 Message: Logged In: YES user_id=31435 Well, if I refuse to change cmath docs, chances are nobody else will, so closing this . The math module docs were changed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-02 18:14 Message: Logged In: YES user_id=33168 Tim (Peters), did you want to do anything else on this or should it be closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-24 19:04 Message: Logged In: YES user_id=31435 I checked in a major rewrite of the math module docs, as Doc/lib/libmath.tex revision 1.32. This stuffed in "radians" as appropriate (among other things). Note that the function docstrings already told the radiaion story; e.g., >>> print math.cos.__doc__ cos(x) Return the cosine of x (measured in radians). >>> I didn't change the cmath docs, and don't intend to. Anyone using complex "angles" who doesn't already know they're working in radians shouldn't be allowed to import cmath <0.6 wink>. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-24 16:27 Message: Logged In: YES user_id=80475 Yes, the platform math lib will be in radians. You're welcome to submit a clarifying doc patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996392&group_id=5470 From noreply at sourceforge.net Tue Aug 3 03:18:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 03:18:20 2004 Subject: [ python-Bugs-1001018 ] setdefaulttimeout causes unnecessary timeouts on connect err Message-ID: Bugs item #1001018, was opened at 2004-07-31 11:07 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Guido van Rossum (gvanrossum) Summary: setdefaulttimeout causes unnecessary timeouts on connect err Initial Comment: This looks like a bug to me: >>> import socket, httplib >>> socket.setdefaulttimeout(10) >>> httplib.HTTPConnection("www.python.org", 9999).connect() [.... 10 second delay ....] Traceback (most recent call last): File "", line 1, in ? File "e:\src\python-cvs\lib\httplib.py", line 548, in connect raise socket.error, msg socket.timeout: timed out >>> On Linux, there is no significant delay, and the traceback reads: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/httplib.py", line 548, in connect raise socket.error, msg socket.error: (111, 'Connection refused') The linux result is what I expected on Windows. Sockets aren't my strong point, so I'd prefer someone confirming it is a real bug before I burn too much time on it. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-08-03 11:18 Message: Logged In: YES user_id=14198 It is true select does return 1 for either the "can't connect" or "connected" cases. In the "connected" case, the getsockopt() returns 0 - hence the function returns 0, and WSASetLastError(0) has been called. ie, as far as I can see and test, the code works for both success and failure. However, I do agree that the MS docs don't explicitly state anywhere that what I am doing is OK, so I'm attaching a new patch as you suggest, and which also seems to work ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-03 00:29 Message: Logged In: YES user_id=31435 I suspect the patch is close but not quite there yet. I believe select will return 1 now if the socket is in *either* of the writable or exception sets upon select's return, so that the patch loses the distinction between "ok, we finally connected" and "oops -- we can't connect". If so, to untangle that we need to pass in *distinct* sets to select, and when the return is > 0 it's an error case if and only if FS_SET then says the socket is in the exception set. If the socket is in the writable set instead, then the connect succeeded. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 20:07 Message: Logged In: YES user_id=14198 Thanks Tim! It looks like this patch works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-02 10:31 Message: Logged In: YES user_id=31435 I can confirm that Guido certainly didn't intend for a refused connection to wait for the timeout on Windows. A problem is that the attempt to connect here isn't returning WSAECONNREFUSED on Windows, it's returning WSAEWOULDBLOCK. If you set the default timeout back to None, the attempt to connect *does* return WSAECONNREFUSED on Windows. But for whatever reason, the Windows implementation of sockets appears to turn that into WSAEWOULDBLOCK if (and only if) the socket is in non-blocking mode. The problem then is trying to guess some way to figure out whether WSAEWOULDBLOCK on a Windows non-blocking socket connect *means* "there's no chance this will ever succeed" or "I can't connect immediately, but maybe I can later". It appears to mean both things . Note this: >>> s = socket.socket() >>> s.setblocking(0) >>> s.connect(("www.python.org", 9999)) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (10035, 'The socket operation could not complete without blocking') Now at this point, the code essentially does this: >>> select.select([], [s], [], 10.0) ([], [], []) >>> and select waits 10 seconds before returning. However, if we do this instead (I'm adding a non- empty "error/exception" list argument): >>> select.select([], [s], [s], 10.0) ([], [], []) >>> then it returns immediately, with the socket in the exception list. So that's a clue. How can we tell *what* error occurred? Hmm. For the exception list, MS select docs say a socket will appear there when: "If processing a connect call (nonblocking), connection attempt failed " So the behavior so far matches the docs. Later it says """ If a socket is processing a connect call (nonblocking), failure of the connect attempt is indicated in exceptfds (application must then call getsockopt SO_ERROR to determine the error value to describe why the failure occurred). This document does not define which other errors will be included. """ So there you go : we have to add the socket to the select call's exception set. Then the select call won't wait forever. When it comes back, and there is an exception, we have to call getsockopt() with SO_ERROR to determine the cause. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 09:38 Message: Logged In: YES user_id=14198 Guido - it looks like this change was made by you in Rev 1.257. Can you please confirm the new behaviour is not correct and I will try and dig a little deeper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 From noreply at sourceforge.net Tue Aug 3 04:42:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 04:42:19 2004 Subject: [ python-Bugs-1001018 ] setdefaulttimeout causes unnecessary timeouts on connect err Message-ID: Bugs item #1001018, was opened at 2004-07-30 21:07 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 Category: Windows Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Mark Hammond (mhammond) >Assigned to: Mark Hammond (mhammond) Summary: setdefaulttimeout causes unnecessary timeouts on connect err Initial Comment: This looks like a bug to me: >>> import socket, httplib >>> socket.setdefaulttimeout(10) >>> httplib.HTTPConnection("www.python.org", 9999).connect() [.... 10 second delay ....] Traceback (most recent call last): File "", line 1, in ? File "e:\src\python-cvs\lib\httplib.py", line 548, in connect raise socket.error, msg socket.timeout: timed out >>> On Linux, there is no significant delay, and the traceback reads: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/httplib.py", line 548, in connect raise socket.error, msg socket.error: (111, 'Connection refused') The linux result is what I expected on Windows. Sockets aren't my strong point, so I'd prefer someone confirming it is a real bug before I burn too much time on it. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-02 22:42 Message: Logged In: YES user_id=31435 Ya, it's always a good idea to blindly do what I say . Marked accepted and assigned to you -- please check it in. One nit: the comment saying the socket is in the readable set should say that the socket is in the writable set. We passed NULL for the readable set. I don't know what's worse -- the socket API or the Outlook API, eh? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 21:18 Message: Logged In: YES user_id=14198 It is true select does return 1 for either the "can't connect" or "connected" cases. In the "connected" case, the getsockopt() returns 0 - hence the function returns 0, and WSASetLastError(0) has been called. ie, as far as I can see and test, the code works for both success and failure. However, I do agree that the MS docs don't explicitly state anywhere that what I am doing is OK, so I'm attaching a new patch as you suggest, and which also seems to work ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-02 10:29 Message: Logged In: YES user_id=31435 I suspect the patch is close but not quite there yet. I believe select will return 1 now if the socket is in *either* of the writable or exception sets upon select's return, so that the patch loses the distinction between "ok, we finally connected" and "oops -- we can't connect". If so, to untangle that we need to pass in *distinct* sets to select, and when the return is > 0 it's an error case if and only if FS_SET then says the socket is in the exception set. If the socket is in the writable set instead, then the connect succeeded. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 06:07 Message: Logged In: YES user_id=14198 Thanks Tim! It looks like this patch works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-01 20:31 Message: Logged In: YES user_id=31435 I can confirm that Guido certainly didn't intend for a refused connection to wait for the timeout on Windows. A problem is that the attempt to connect here isn't returning WSAECONNREFUSED on Windows, it's returning WSAEWOULDBLOCK. If you set the default timeout back to None, the attempt to connect *does* return WSAECONNREFUSED on Windows. But for whatever reason, the Windows implementation of sockets appears to turn that into WSAEWOULDBLOCK if (and only if) the socket is in non-blocking mode. The problem then is trying to guess some way to figure out whether WSAEWOULDBLOCK on a Windows non-blocking socket connect *means* "there's no chance this will ever succeed" or "I can't connect immediately, but maybe I can later". It appears to mean both things . Note this: >>> s = socket.socket() >>> s.setblocking(0) >>> s.connect(("www.python.org", 9999)) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (10035, 'The socket operation could not complete without blocking') Now at this point, the code essentially does this: >>> select.select([], [s], [], 10.0) ([], [], []) >>> and select waits 10 seconds before returning. However, if we do this instead (I'm adding a non- empty "error/exception" list argument): >>> select.select([], [s], [s], 10.0) ([], [], []) >>> then it returns immediately, with the socket in the exception list. So that's a clue. How can we tell *what* error occurred? Hmm. For the exception list, MS select docs say a socket will appear there when: "If processing a connect call (nonblocking), connection attempt failed " So the behavior so far matches the docs. Later it says """ If a socket is processing a connect call (nonblocking), failure of the connect attempt is indicated in exceptfds (application must then call getsockopt SO_ERROR to determine the error value to describe why the failure occurred). This document does not define which other errors will be included. """ So there you go : we have to add the socket to the select call's exception set. Then the select call won't wait forever. When it comes back, and there is an exception, we have to call getsockopt() with SO_ERROR to determine the cause. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-01 19:38 Message: Logged In: YES user_id=14198 Guido - it looks like this change was made by you in Rev 1.257. Can you please confirm the new behaviour is not correct and I will try and dig a little deeper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 From noreply at sourceforge.net Tue Aug 3 05:35:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 05:35:38 2004 Subject: [ python-Bugs-1002398 ] os.path.sameopenfile documentation wrong. Message-ID: Bugs item #1002398, was opened at 2004-08-02 23:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002398&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.sameopenfile documentation wrong. Initial Comment: At http://docs.python.org/lib/module-os.path.html it very clearly states this: sameopenfile(fp1, fp2) Return True if the file objects fp1 and fp2 refer to the same file. The two file objects may represent different file descriptors. Availability: Macintosh, Unix. However, on my OSX box, the source to posixpath.py clearly says otherwise: def sameopenfile(fp1, fp2): """Test whether two open file objects reference the same file""" s1 = os.fstat(fp1) s2 = os.fstat(fp2) return samestat(s1, s2) I.e., sameopenfile accepts two integer filenos, not two file objects. Running it gives this exception: File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/site-packages/supybot/plugins/Tail.py", line 77, in samefile return os.path.sameopenfile(fd1, fd2) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/posixpath.py", line 220, in sameopenfile s1 = os.fstat(fp1) TypeError: an integer is required Perhaps the (much more useful) documented behavior can be retained, and two if statements added to the definition of sameopenfile: if not isinstance(fp1, int): fp1 = fp1.fileno() if not isinstance(fp2, int): fp2 = fp2.fileno() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002398&group_id=5470 From noreply at sourceforge.net Tue Aug 3 06:39:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 06:39:48 2004 Subject: [ python-Bugs-991735 ] os.access reports true for read-only directories Message-ID: Bugs item #991735, was opened at 2004-07-15 12:08 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Moales (mmoales) Assigned to: Nobody/Anonymous (nobody) Summary: os.access reports true for read-only directories Initial Comment: It appears that os.access incorrectly reports write access to directories on network drives. For example, if I have a read-only directory called foo\bar on a machine called homeserver, the following code always returns true: print os.access("\\homeserver\foo\bar", os.W_OK) True Similarly, if I map above directory to a drive, the results are the same, i.e.: print os.access("H:\bar", os.W_OK) True However, if I try to create a file in that directory, I get a permission error: f = file("h:\foo\bar\test.txt", 'w+b') Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 13] Permission denied: 'h:\foo\bar\test.txt' ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-08-02 23:39 Message: Logged In: YES user_id=555 nnorwitz: The penultimate paragraph of my comment (the one that begins "Note that...") is what I'd suggest adding to the doc... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-02 17:18 Message: Logged In: YES user_id=33168 Mark or mkc, can you suggest wording to improve the docs? Thanks. ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-07-29 14:28 Message: Logged In: YES user_id=555 The submitter seems to want os.access to agree with the subsequent behavior of I/O operation, but this is not possible for all cases. The NFS spec, for example, allows NFS servers to deny operations in a capricious manner, over and above any denial that might be due to permissions bits and/or a volume "read only" flag. I don't know if there is an SMB/CIFS server spec, but one could imagine the same thing happening there. It might be possible to add ACL checking to the Windows version of os.access, if a Windows person thinks it's worthwhile. It probably would be valuable to add a clarification to the os.access doc. For example: Note that I/O operations may fail even when the access function indicates that they would succeed, particularly for operations on network filesystems, which may have permissions semantics beyond the usual POSIX permission-bit model. (Also, if someone does this, please update the doc to note that access returns True and False, not 1 and 0.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-15 15:59 Message: Logged In: YES user_id=31435 Heh -- I didn't know it either, Thomas. But I've also noticed how many new Windows bugs get assigned to you, and got curious enough to dig into it. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2004-07-15 14:25 Message: Logged In: YES user_id=565165 This may not be a bug afterall. I think it has to do with Window's ACLs. I believe os.access is just looking at access bits. For example, I can create a directory and leave it as writable, but prevent access to it via an ACL. In this case, os.access reports true, but any operation you try to perform on the dictionary get's a permission error. It might just need to be mentioned in the os.access doc. Thomas: no problem ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-15 14:20 Message: Logged In: YES user_id=11105 Tim: I didn't know that. Thanks for disabling it. Mark: Sorry, it wasn't your fault. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-15 13:56 Message: Logged In: YES user_id=31435 The tracker was set to auto-assign Windows reports to you, Thomas. I disabled that (and Windows reports will be assigned to None by default now). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-15 13:41 Message: Logged In: YES user_id=11105 Please don't assign windows bugs to me. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&group_id=5470 From noreply at sourceforge.net Tue Aug 3 07:08:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 07:08:29 2004 Subject: [ python-Bugs-1001018 ] setdefaulttimeout causes unnecessary timeouts on connect err Message-ID: Bugs item #1001018, was opened at 2004-07-31 11:07 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: setdefaulttimeout causes unnecessary timeouts on connect err Initial Comment: This looks like a bug to me: >>> import socket, httplib >>> socket.setdefaulttimeout(10) >>> httplib.HTTPConnection("www.python.org", 9999).connect() [.... 10 second delay ....] Traceback (most recent call last): File "", line 1, in ? File "e:\src\python-cvs\lib\httplib.py", line 548, in connect raise socket.error, msg socket.timeout: timed out >>> On Linux, there is no significant delay, and the traceback reads: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/httplib.py", line 548, in connect raise socket.error, msg socket.error: (111, 'Connection refused') The linux result is what I expected on Windows. Sockets aren't my strong point, so I'd prefer someone confirming it is a real bug before I burn too much time on it. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-08-03 15:08 Message: Logged In: YES user_id=14198 Thanks Tim! Checking in socketmodule.c; new revision: 1.297; previous revision: 1.296 Do we want this on the 2.3 branch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-03 12:42 Message: Logged In: YES user_id=31435 Ya, it's always a good idea to blindly do what I say . Marked accepted and assigned to you -- please check it in. One nit: the comment saying the socket is in the readable set should say that the socket is in the writable set. We passed NULL for the readable set. I don't know what's worse -- the socket API or the Outlook API, eh? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-03 11:18 Message: Logged In: YES user_id=14198 It is true select does return 1 for either the "can't connect" or "connected" cases. In the "connected" case, the getsockopt() returns 0 - hence the function returns 0, and WSASetLastError(0) has been called. ie, as far as I can see and test, the code works for both success and failure. However, I do agree that the MS docs don't explicitly state anywhere that what I am doing is OK, so I'm attaching a new patch as you suggest, and which also seems to work ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-03 00:29 Message: Logged In: YES user_id=31435 I suspect the patch is close but not quite there yet. I believe select will return 1 now if the socket is in *either* of the writable or exception sets upon select's return, so that the patch loses the distinction between "ok, we finally connected" and "oops -- we can't connect". If so, to untangle that we need to pass in *distinct* sets to select, and when the return is > 0 it's an error case if and only if FS_SET then says the socket is in the exception set. If the socket is in the writable set instead, then the connect succeeded. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 20:07 Message: Logged In: YES user_id=14198 Thanks Tim! It looks like this patch works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-02 10:31 Message: Logged In: YES user_id=31435 I can confirm that Guido certainly didn't intend for a refused connection to wait for the timeout on Windows. A problem is that the attempt to connect here isn't returning WSAECONNREFUSED on Windows, it's returning WSAEWOULDBLOCK. If you set the default timeout back to None, the attempt to connect *does* return WSAECONNREFUSED on Windows. But for whatever reason, the Windows implementation of sockets appears to turn that into WSAEWOULDBLOCK if (and only if) the socket is in non-blocking mode. The problem then is trying to guess some way to figure out whether WSAEWOULDBLOCK on a Windows non-blocking socket connect *means* "there's no chance this will ever succeed" or "I can't connect immediately, but maybe I can later". It appears to mean both things . Note this: >>> s = socket.socket() >>> s.setblocking(0) >>> s.connect(("www.python.org", 9999)) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (10035, 'The socket operation could not complete without blocking') Now at this point, the code essentially does this: >>> select.select([], [s], [], 10.0) ([], [], []) >>> and select waits 10 seconds before returning. However, if we do this instead (I'm adding a non- empty "error/exception" list argument): >>> select.select([], [s], [s], 10.0) ([], [], []) >>> then it returns immediately, with the socket in the exception list. So that's a clue. How can we tell *what* error occurred? Hmm. For the exception list, MS select docs say a socket will appear there when: "If processing a connect call (nonblocking), connection attempt failed " So the behavior so far matches the docs. Later it says """ If a socket is processing a connect call (nonblocking), failure of the connect attempt is indicated in exceptfds (application must then call getsockopt SO_ERROR to determine the error value to describe why the failure occurred). This document does not define which other errors will be included. """ So there you go : we have to add the socket to the select call's exception set. Then the select call won't wait forever. When it comes back, and there is an exception, we have to call getsockopt() with SO_ERROR to determine the cause. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 09:38 Message: Logged In: YES user_id=14198 Guido - it looks like this change was made by you in Rev 1.257. Can you please confirm the new behaviour is not correct and I will try and dig a little deeper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 From noreply at sourceforge.net Tue Aug 3 09:25:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 09:25:11 2004 Subject: [ python-Bugs-1002453 ] Wrong documentation of __radd__ etc. Message-ID: Bugs item #1002453, was opened at 2004-08-03 09:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002453&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong documentation of __radd__ etc. Initial Comment: Info node 'Emulating numeric types' says: __radd__(self, other) __rsub__(self, other) ... These functions are only called if the left operand does not support the corresponding operation. Not so. Info node 'Coercion rules' lists one exception: if the left operand is an instance of a built-in type or a new-style class, and the right operand is an instance of a proper subclass of that type or class, the right operand's `__rop__()' method is tried _before_ the left operand's `__op__()' method. ...and one time where above the text is misleading: When either operand type defines a coercion, this coercion is called before that type's `__op__()' or `__rop__()' method is called, but no sooner. If the coercion returns an object of a different type for the operand whose coercion is invoked, part of the process is redone using the new object. Thus, Python can call __rop__(self, other) even if self.__op__ exists: If one does `x - y' where y.__coerce__(x) coerces x to y's class, y.__rsub__(x) is called instead of (coerced x).__sub__(y). I think this should be documented in the 'Emulating numeric types' node. Unless Python is changed to redo the choice between __op__, __rop__ and __iop__ after coercion. I think it would also be good to explain in that Info node what __op__ and __rop__ can do if they do not support the operation with the supplied arguments, but the other argument might support it. It seems obvious that self.__op__(other) can simply attempt to call other.__rop__(self) and let that fail if it is not supported. However, the above rules seem to mean that self.__rop__(other) might want to call other.__op__(self) too, which could lead to infinite recursion. Are there some special times where it can do that, and other times where it should not? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002453&group_id=5470 From noreply at sourceforge.net Tue Aug 3 10:04:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 10:04:51 2004 Subject: [ python-Bugs-1002465 ] MemoryError on AIX52 Message-ID: Bugs item #1002465, was opened at 2004-08-03 08:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Datranet (richardjmason) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError on AIX52 Initial Comment: I found the orginal problem when trying to send large email attachments on AIX 5.2. I tracked the issue down to the fact that a string can only grow to a very restricted size on AIX 5.2. bin2ascii fails at the pint the function tries to join the list togther to form 1 string. I wrote the following test program to prove the issue: a = '' cnt = 0 while cnt < 1024: a = a + 'x' cnt += 1 c = '' cnt = 0 while cnt < 1024: c = c + a cnt += 1 b = '' cnt2 = 0 while 1: b = b + c cnt2 += 1 print cnt2 On AIX 5.2 you get a MemoryError with a cnt2 value of 42. I can run the test program on all other platforms and get a cnt2 value over 150 before stopping to program myself. I have tried the binary python 2.2 from the IBM site and building python 2.3.4 myself using the gcc from the IBM site. Both fail with a cnt2 value of 42. Can anyone please advise on how to get AIX 5.2 to allow single objects to have more memory allocated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 From noreply at sourceforge.net Tue Aug 3 10:32:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 10:32:54 2004 Subject: [ python-Bugs-1002475 ] email message parser doesn't handle \r\n correctly Message-ID: Bugs item #1002475, was opened at 2004-08-03 10:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Nobody/Anonymous (nobody) Summary: email message parser doesn't handle \r\n correctly Initial Comment: Header lines that end in \r\n only get the \n stripped, not the \r (unless it's the last header which does get the \r stripped): >>> import email.Parser >>> m = 'Header: text\r\nNext-Header: more text\r\n\r\nBody\r\n\r\n' >>> msg = email.Parser.Parser().parsestr(m) >>> msg.get('header') 'text\r' >>> msg.get('next-header') 'more text' >>> This bug showed itself in my SpamBayes setup using sb_imapfilter.py where base64-encoded text/html messages were not decoded in Message.get_payload because the call to get('content-transfer-encoding') returned the string 'base64\r' instead of 'base64'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 From noreply at sourceforge.net Tue Aug 3 11:03:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 11:03:25 2004 Subject: [ python-Bugs-808756 ] refleaks in _hotshot.c Message-ID: Bugs item #808756, was opened at 2003-09-18 18:01 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Armin Rigo (arigo) Summary: refleaks in _hotshot.c Initial Comment: My regrtest patches revealed a few leaks in Modules/_hotshot.c. Attached patch seems to fix. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-08-03 09:03 Message: Logged In: YES user_id=4771 Checked in: trunk _hotshot.c 1.37 release23-maint _hotshot.c 1.34.10.1 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-02 15:32 Message: Logged In: YES user_id=3066 I just looked over Armin's version of the patch, and it looks good to me. Armin, please go ahead and commit, and close this report. This should be backported to 2.3.x as well; I think the patch should apply cleanly to the branch as well as the trunk. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 14:22 Message: Logged In: YES user_id=6656 This patch is still necessary, still applies and still fixes the leaks. Any objections to just checking it in? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-22 13:28 Message: Logged In: YES user_id=31435 Just attaching Armin's patch (hotshot2.diff). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-22 12:01 Message: Logged In: YES user_id=4771 Unless I'm mistaken there is a misplaced DECREF. I'd love to attach my patch but cannot do so. Here it is: http://arigo.tunes.org/hotshot2.diff A more general note is about using 'N' in Py_BuildValue. Its implementation seems to be buggy because it does not always consume a reference: it won't do so if an error occurs before it gets there. I guess I'll submit a separate bug report/patch for this too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808756&group_id=5470 From noreply at sourceforge.net Tue Aug 3 12:25:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 12:25:35 2004 Subject: [ python-Bugs-808596 ] leaking snippet Message-ID: Bugs item #808596, was opened at 2003-09-18 15:48 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: leaking snippet Initial Comment: Raymond Hettinger found that the following: fd, fname = tempfile.mkstemp() execfile(fname) leaks a reference. TrackRefs sez it's a string. Haven't dug any further. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-03 11:25 Message: Logged In: YES user_id=6656 Done, in Python/compile.c revision 2.312. test_pkgimport turned out to be something else (sys.path_importer_cache), so I feel no need to try and be clever with dummy's refcounting today. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 16:11 Message: Logged In: YES user_id=80475 Not interning the filename seems cleanest. Like you, I do not expect that interning provided any real benefit here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 13:56 Message: Logged In: YES user_id=6656 I've finally worked out what's going on here. It's because compiling the file interns the name of the file being compiled. Now that interned strings are mortal, this isn't a big deal, but it still results in a string being added to and removed from the interned strings dictionary with net result (almost all of the time) of incrementing the refcount on 'dummy' by one. Once in every thousand or so iterations this results in the interned string dictionary being resized and throwing all the references to dummy away, so this isn't a 'real' leak. OTOH, I'd still like to do something about this (as is, test_pkg appears to leak 10 references per run because of this). The simplest thing would be to just plain not intern the filename during compilation (I find it hard to believe that it's of any real benefit). The more invasive solution would be to not do refcounting on dummy (assuming that's even possible) which is a scarier change, but would stop similar problems with other tests (I have a feeling that test_pkgimport appears to be leaking references because of a different incarnation of the same problem). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 From noreply at sourceforge.net Tue Aug 3 12:58:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 12:58:20 2004 Subject: [ python-Bugs-1002530 ] test_decimal fails if repeated Message-ID: Bugs item #1002530, was opened at 2004-08-03 11:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002530&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Facundo Batista (facundobatista) Summary: test_decimal fails if repeated Initial Comment: You can see this by trying, eg, $ ./python ../Lib/test/regrtest.py test_decimal test_decimal I think it's something like precision not being restored in the default context, but I don't really know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002530&group_id=5470 From noreply at sourceforge.net Tue Aug 3 13:17:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 13:17:47 2004 Subject: [ python-Bugs-1002537 ] test_logging fails if run twice Message-ID: Bugs item #1002537, was opened at 2004-08-03 12:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002537&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails if run twice Initial Comment: Traceback (most recent call last): File "/Users/mwh/Source/python/dist/src/Lib/logging/ __init__.py", line 696, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file over and over again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002537&group_id=5470 From noreply at sourceforge.net Tue Aug 3 13:28:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 13:28:41 2004 Subject: [ python-Bugs-1002537 ] test_logging fails if run twice Message-ID: Bugs item #1002537, was opened at 2004-08-03 21:17 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002537&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails if run twice Initial Comment: Traceback (most recent call last): File "/Users/mwh/Source/python/dist/src/Lib/logging/ __init__.py", line 696, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file over and over again. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-03 21:28 Message: Logged In: YES user_id=29957 Commenting out line 467 stops these errors, but there's still a keyerror lying around. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002537&group_id=5470 From noreply at sourceforge.net Tue Aug 3 14:15:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 14:15:56 2004 Subject: [ python-Bugs-930024 ] os.path.realpath can't handle symlink loops Message-ID: Bugs item #930024, was opened at 2004-04-05 16:59 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=930024&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 7 Submitted By: A.M. Kuchling (akuchling) >Assigned to: A.M. Kuchling (akuchling) Summary: os.path.realpath can't handle symlink loops Initial Comment: Create a symlink pointing to itself: ln -s infinite infinite Run os.path.realpath() on it, and it recurses infinitely (until the stack limit is hit): >>> import os >>> os.path.realpath('/home/amk/infinite') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/posixpath.py", line 416, in realpath return realpath(newpath) os.path.realpath() should be fixed; /home/amk/infinite is a perfectly good path, though it can't be followed. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-03 08:15 Message: Logged In: YES user_id=11375 Fixed in 2.3-maint and on the trunk. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 06:20 Message: Logged In: YES user_id=21627 The code that has been committed is incorrect if the link to be resolved is relative. _resolve_link uses abspath to determine whether the link is absolute. This function returns an absolute path (possibly using getcwd); the function that should have been used is isabs(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-10 18:59 Message: Logged In: YES user_id=357491 Applied as rev. 1.67 in 2.4a2 and rev. 1.62.6.2 in 2.3.5 with only minor cleanup. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-06-05 14:58 Message: Logged In: YES user_id=11375 Patch attached; review requested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=930024&group_id=5470 From noreply at sourceforge.net Tue Aug 3 14:16:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 14:16:44 2004 Subject: [ python-Bugs-998001 ] bsddb has default flag of c, not r Message-ID: Bugs item #998001, was opened at 2004-07-26 08:13 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998001&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: kim bruning (kimbruning) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bsddb has default flag of c, not r Initial Comment: python 2.3.3 has a discrepancy with the documentation at http://docs.python.org/lib/module-bsddb.htm In section: > 7.13 bsddb -- Interface to Berkeley DB library for hashopen, btopen and rnopen, the documentation states that: > The optional flag identifies the mode used to open the file. It >may be "r" (read only, default) It turns out that 'r' is in fact not the default option for any of these 3 in Python 2.3.3. The default option for the flag parameter turns out to be 'c'. I had some trouble with using the bsddb module in conjunction with make, and finally resorted to reading the source code to find out what was wrong. The actual source code has: def hashopen(file, flag='c', mode=0666, pgsize=None, ffactor=None, nelem=None, cachesize=None, lorder=None, hflags=0): def btopen(file, flag='c', mode=0666, btflags=0, cachesize=None, maxkeypage=None, minkeypage=None, pgsize=None, lorder=None): def rnopen(file, flag='c', mode=0666, rnflags=0, cachesize=None, pgsize=None, lorder=None, rlen=None, delim=None, source=None, pad=None): ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-03 08:16 Message: Logged In: YES user_id=11375 Marking as closed. ---------------------------------------------------------------------- Comment By: kim bruning (kimbruning) Date: 2004-07-26 14:00 Message: Logged In: YES user_id=1091452 Fred Drake has fixed this in the documentation source ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998001&group_id=5470 From noreply at sourceforge.net Tue Aug 3 14:18:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 14:19:55 2004 Subject: [ python-Bugs-922690 ] package manager page outdated link Message-ID: Bugs item #922690, was opened at 2004-03-24 15:07 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) >Assigned to: Jack Jansen (jackjansen) Summary: package manager page outdated link Initial Comment: The page http://www.python.org/packman/ has outdated links to Bob Ippolito's page. The correct link appears to be http://undefined.org/python/ (which includes links to various versions of the packages and to descriptions of the same). ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-03-30 11:57 Message: Logged In: YES user_id=593130 To supplement the summary: the two links (xml and html) on the bottom of the packman page work but they are specific to (an older? verseion) the pimp package. The higher link suggested as a substitue lists other packages, including some that appear to have been extracted from pimp. Since the current page references aeve 0.0.3 while the suggested link references aeve 0.0.4, the suggest change seems proper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470 From noreply at sourceforge.net Tue Aug 3 14:42:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 14:42:20 2004 Subject: [ python-Bugs-870382 ] Mingw needs to use the same MSVC runtime as Python Message-ID: Bugs item #870382, was opened at 2004-01-04 15:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470 Category: Distutils Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Paul Moore (pmoore) Assigned to: Martin v. L?wis (loewis) Summary: Mingw needs to use the same MSVC runtime as Python Initial Comment: Python 2.4 is now built with MSVC 7.1, which uses a new MSVC runtime library. Extension DLLs should be built to use the same runtime DLL as Python itself (although it has not been possible to find a real-world example where not doing so causes a problem...) The attached patch adds the appropriate -l flag to the link, based on the MSVC version reported in sys.version. (This has only been tested with a Python built with MSVC 7.1, the version number used for MSVC 7.0 is based on verbal reports only). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 14:42 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as cygwinccompiler.py 1.27. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-07-29 22:19 Message: Logged In: YES user_id=113328 Can someone suggest what I need to do to get this patch, or something similar, accepted? As things stand, the official Python 2.4 build *does not support* building compatible extensions with mingw, where 2.3 did. I have no means of extending this patch to work with user-built versions of Python - I don't currently have any way of building Python for myself, to test any such change. I don't object to someone making such an extension, but I have seen no-one step forward. I'm getting a little frustrated here. The arguments against applying the patch seem largely theoretical (and outside my expertise). I'd like to invoke "practicality beats purity" here... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-07-16 13:19 Message: Logged In: YES user_id=11105 In principle, it would be possible to examine the import table of pythonxy.dll, to find out to which msvcrXX.dll it is linked to. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-07-15 06:40 Message: Logged In: YES user_id=552329 FWIW, this patch works for me, and I'd definitely like to see it in 2.4a2. If the MSVC version isn't 1300 or 1310 (the theoretical 1400, for example), then it doesn't do anything different to what 2.4a1 does, so it's hard to see why that would be a problem (and with the patch applied, there's a clear fix, just adding in the appropriate elif and link - it's not like new versions come along all the time). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-07-09 13:17 Message: Logged In: YES user_id=113328 This is still an issue with 2.4a1. I'm not sure what the autodetection buys given that currently it's not possible to build extensions with 2.4a1 using mingw which are compatible with the stock python.org binary. Can I suggest that this patch be applied, and issues around autodetection be deferred until there is a demonstrated need? I've uploaded a revised patch for 2.4a1 (tested against the python.org supplied MSI). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-05 22:30 Message: Logged In: YES user_id=21627 I'm primarily concerned about future (unreleased-as-of-today) MSC versions; they likely have version numbers like "1400"; linking msvcr71 to binaries built with that compiler is likely wrong. Not adding anything for gcc-built python versions is fine. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2004-01-05 00:01 Message: Logged In: YES user_id=113328 What about Python built with mingw? I don't think that's possible right now, but I'd expect people to work on it. And I've no idea what sys.version for that would be. The only real cases are likely to be MSVC 7.1 (Python 2.4, binary dist), MSVC 6 (Python <= 2.3, binary dist) and hand- built Python versions. The patch does the right thing for all the binary distributions, which are the ones where the user can't be assumed to know how to hack things to make them work. For hand-built versions, the user can do "python setup.py build_ext --compiler=mingw32 -l msvcr71" (or whatever) to manually specify the runtime to use. Leaving the default as msvcrt (the CRT that comes with the OS, and is default for mingw) seems right - and better than aborting (particularly as I'm not sure how to check whether there's an -l option for the CRT specified by the user). The best I could do is effectively to force build_ext to fail unless Python was built with MSVC, which seems unhelpful... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-04 16:03 Message: Logged In: YES user_id=21627 Could you add some kind of assertion to detect the case that an entirely different compiler version is used? It would be best if it gets the case of using MSVC6 right, and gives up if some other compiler version is detected (I can't determine os.version for the VC6 case right now, but Python 2.3 is built with it). Apart from that, the patch looks good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470 From noreply at sourceforge.net Tue Aug 3 15:14:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 15:14:15 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 10:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 15:14 Message: Logged In: YES user_id=21627 Can you report the relevant section from config.log where configure disables sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Tue Aug 3 15:53:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 15:53:55 2004 Subject: [ python-Bugs-1002632 ] glob() unicode bug Message-ID: Bugs item #1002632, was opened at 2004-08-03 13:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002632&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) Summary: glob() unicode bug Initial Comment: #Python 2.3 on W2K import glob name = glob.glob(u"./*.mp3")[0] print type(name) name = glob.glob(u"*.mp3")[0] print type(name) ##OUTPUT## # # ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002632&group_id=5470 From noreply at sourceforge.net Tue Aug 3 16:01:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 16:02:02 2004 Subject: [ python-Bugs-1002632 ] glob() unicode bug Message-ID: Bugs item #1002632, was opened at 2004-08-03 15:53 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002632&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) Summary: glob() unicode bug Initial Comment: #Python 2.3 on W2K import glob name = glob.glob(u"./*.mp3")[0] print type(name) name = glob.glob(u"*.mp3")[0] print type(name) ##OUTPUT## # # ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:01 Message: Logged In: YES user_id=38388 Duplicate of [ 1001604 ] glob doesn't return unicode with no dir in unicode filename ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002632&group_id=5470 From noreply at sourceforge.net Tue Aug 3 16:03:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 16:03:21 2004 Subject: [ python-Bugs-1001018 ] setdefaulttimeout causes unnecessary timeouts on connect err Message-ID: Bugs item #1001018, was opened at 2004-07-30 21:07 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: setdefaulttimeout causes unnecessary timeouts on connect err Initial Comment: This looks like a bug to me: >>> import socket, httplib >>> socket.setdefaulttimeout(10) >>> httplib.HTTPConnection("www.python.org", 9999).connect() [.... 10 second delay ....] Traceback (most recent call last): File "", line 1, in ? File "e:\src\python-cvs\lib\httplib.py", line 548, in connect raise socket.error, msg socket.timeout: timed out >>> On Linux, there is no significant delay, and the traceback reads: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/httplib.py", line 548, in connect raise socket.error, msg socket.error: (111, 'Connection refused') The linux result is what I expected on Windows. Sockets aren't my strong point, so I'd prefer someone confirming it is a real bug before I burn too much time on it. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-03 10:03 Message: Logged In: YES user_id=31435 Closed the report. It *is* a bug, so I hope the patch said "bugfix candidate". If not, you'll have to backport it yourself . ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-03 01:08 Message: Logged In: YES user_id=14198 Thanks Tim! Checking in socketmodule.c; new revision: 1.297; previous revision: 1.296 Do we want this on the 2.3 branch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-02 22:42 Message: Logged In: YES user_id=31435 Ya, it's always a good idea to blindly do what I say . Marked accepted and assigned to you -- please check it in. One nit: the comment saying the socket is in the readable set should say that the socket is in the writable set. We passed NULL for the readable set. I don't know what's worse -- the socket API or the Outlook API, eh? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 21:18 Message: Logged In: YES user_id=14198 It is true select does return 1 for either the "can't connect" or "connected" cases. In the "connected" case, the getsockopt() returns 0 - hence the function returns 0, and WSASetLastError(0) has been called. ie, as far as I can see and test, the code works for both success and failure. However, I do agree that the MS docs don't explicitly state anywhere that what I am doing is OK, so I'm attaching a new patch as you suggest, and which also seems to work ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-02 10:29 Message: Logged In: YES user_id=31435 I suspect the patch is close but not quite there yet. I believe select will return 1 now if the socket is in *either* of the writable or exception sets upon select's return, so that the patch loses the distinction between "ok, we finally connected" and "oops -- we can't connect". If so, to untangle that we need to pass in *distinct* sets to select, and when the return is > 0 it's an error case if and only if FS_SET then says the socket is in the exception set. If the socket is in the writable set instead, then the connect succeeded. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-02 06:07 Message: Logged In: YES user_id=14198 Thanks Tim! It looks like this patch works. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-01 20:31 Message: Logged In: YES user_id=31435 I can confirm that Guido certainly didn't intend for a refused connection to wait for the timeout on Windows. A problem is that the attempt to connect here isn't returning WSAECONNREFUSED on Windows, it's returning WSAEWOULDBLOCK. If you set the default timeout back to None, the attempt to connect *does* return WSAECONNREFUSED on Windows. But for whatever reason, the Windows implementation of sockets appears to turn that into WSAEWOULDBLOCK if (and only if) the socket is in non-blocking mode. The problem then is trying to guess some way to figure out whether WSAEWOULDBLOCK on a Windows non-blocking socket connect *means* "there's no chance this will ever succeed" or "I can't connect immediately, but maybe I can later". It appears to mean both things . Note this: >>> s = socket.socket() >>> s.setblocking(0) >>> s.connect(("www.python.org", 9999)) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (10035, 'The socket operation could not complete without blocking') Now at this point, the code essentially does this: >>> select.select([], [s], [], 10.0) ([], [], []) >>> and select waits 10 seconds before returning. However, if we do this instead (I'm adding a non- empty "error/exception" list argument): >>> select.select([], [s], [s], 10.0) ([], [], []) >>> then it returns immediately, with the socket in the exception list. So that's a clue. How can we tell *what* error occurred? Hmm. For the exception list, MS select docs say a socket will appear there when: "If processing a connect call (nonblocking), connection attempt failed " So the behavior so far matches the docs. Later it says """ If a socket is processing a connect call (nonblocking), failure of the connect attempt is indicated in exceptfds (application must then call getsockopt SO_ERROR to determine the error value to describe why the failure occurred). This document does not define which other errors will be included. """ So there you go : we have to add the socket to the select call's exception set. Then the select call won't wait forever. When it comes back, and there is an exception, we have to call getsockopt() with SO_ERROR to determine the cause. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-08-01 19:38 Message: Logged In: YES user_id=14198 Guido - it looks like this change was made by you in Rev 1.257. Can you please confirm the new behaviour is not correct and I will try and dig a little deeper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001018&group_id=5470 From noreply at sourceforge.net Tue Aug 3 16:34:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 16:34:56 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:34 Message: Logged In: YES user_id=38388 Peter, could you attach the generated codecs to this report ? Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-02 13:14 Message: Logged In: YES user_id=38388 Martin, I think it's a good idea to add the codecs for completeness. We should probably also review the mapping files posted on the unicode.org site every now and then and update the codecs in Python accordingly. Sticking to the Unicode Consortium's view of things is a good way to assure compatibility with other applications, IMO. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Tue Aug 3 16:39:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 16:39:19 2004 Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters Message-ID: Bugs item #989185, was opened at 2004-07-12 05:59 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode.width broken for combining characters Initial Comment: Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) [GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> u'\u3060'.width() 2 >>> u'\u305f\u3099'.width() 4 Width should be two in both cases. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:39 Message: Logged In: YES user_id=38388 Looks good. Please check it in. Thanks, Hye-Shik ! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-01 18:01 Message: Logged In: YES user_id=55188 Here's my revised patch for new API. :) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 14:31 Message: Logged In: YES user_id=38388 Great ! Thanks. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-23 14:29 Message: Logged In: YES user_id=55188 Yes. I am. I was little bit busy. I'll submit new patch after this weekend. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 12:12 Message: Logged In: YES user_id=38388 Hye-Shik, are you working on a patch to move the implementation as suggested ? Just asking, because I don't was the current layout to go into the Python 2.4 final... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-15 19:36 Message: Logged In: YES user_id=38388 Martin, you can code such a function in your application based on the information you'd get from unicodedata.east_asian_width(). As we've seen, there is no generally sound way to define such a function. As for the location of the data: the unicodedata module is the place where any extra information related to Unicode should go. unicodectype.c is reserved for data needed at C level by the Python Unicode C API. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 19:24 Message: Logged In: YES user_id=21627 I still think a function is useful which computes the number of Ems that a conventional application would expect. That function should raise an exception for a neutral character - the example of the combining characters shows that such characters should *not* be treated as narrow "for all practical purposes". Whether or not it is useful to include the entire UAX#11 classification in the database I don't know - it seems the only application of the data would be computation of the width, anyway. It would not be wise to move the data to the unicode database, as the extra data currently don't affect Python programs that don't use the function, anyway - the data does not consume any additional space. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-15 11:39 Message: Logged In: YES user_id=38388 Hye-Shik, the patch only includes the move to unicodedata, but not the full implementation of the EAW as per the TR. I would much prefer to have the east_asian_width() function return the strings defined in the TR because this allows users of the function to read the information and implement their own interpretation of "width". The new function should work very much like unicodedata.category(). It would also be wise to move the data itself over to the unicode database - that way the extra data does not affect Python programs that don't use the function. Thanks. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-14 17:15 Message: Logged In: YES user_id=55188 Marc-Andre, here's a patch written as you've suggested. Can you please give a review on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 21:41 Message: Logged In: YES user_id=38388 Thanks for your descriptions, Hye-Shik. Since the application space is very much targetted at East Asian scripts, I would like the implementation to be moved into unicodedata where all the other special Unicode features are implemented. The .width() method should be removed. Now that I understand better what the EAW is about, I would also like to see the function be renamed to east_asian_width() since that's what the function is based on. If possible, I'd also rather like to see the full width mapping implemented (as defined in the TR). The reduction to narrow vs. wide seems to be oversimplified. The east_asian_width() function should return the characters: "N", "A", "H", "W", "F", "Na" and let the user decide how to map these to character or string widths. We have followed the same methodology for the other Unicode database properties and this has not only given us much more flexibility, it also is standards compliant and you can get good documentation on these features. Matthew, I suggest you write your own implementation of what you think is right. In the face of ambiguity, there's no such thing as the right approach to a certain problem. Thanks. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 18:03 Message: Logged In: YES user_id=65253 My complaint was that you were attacking my example using non-asian characters, when the TR specifically says they are handled as narrow. I write Asian characters the same as anything else. If it's a unicode string python converts it with sys.stdout.encoding (for print anyway). Otherwise you just have to write in whatever encoding the terminal expects. And when you are talking about a fixed-width text terminal, wide characters take 2 columns, narrow take 1. Assuming you ignore combining characters, which is what this is all about. You said the width is only a "hint for rendering engines", but I cannot think of any rendering engine that would benefit from a hint that can be 2-3x wider (due to counting combining characters) than when you actually display it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-12 17:53 Message: Logged In: YES user_id=55188 Major usages that I expected for width() are: - Hints for terminal-based applications (for cursor position and layouts) - To generate fixed-width text documents not ugly: eg. printing "------" decoration under each subjects. - More readable limit for table columns: eg. topics in web bulletins; limiting by same 'characters' will recur very wide some topic lines full of East Asian characters and narrow snipped english topics. - To locate "^" in correct position on Python tracebacks. This isn't implemented in standard traceback, but width() allows 3rd party can implement sys.excepthook for East Asian easily. In fact, I don't known if width() can easily modified to support variety of combining characters from Western characters. But if it isn't too heavy or complicated, I would volunteer to extend the width() implemention to make it provide generic fixed-width rendering hint. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 17:23 Message: Logged In: YES user_id=38388 I don't understand your complaint: width 1 means "narrow" just as defined in the TR ?! How do you write Asian characters to a terminal ? I think you are mixing glyphs with code points here. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 16:28 Message: Logged In: YES user_id=65253 TR11 says "Strictly speaking, it makes no sense to talk of narrow and wide for neutral characters, but since for all practical purposes they behave like Na, they are treated as narrow characters (the same as Na) under the recommendations below." In addition, the current implementation gives a width of 1 to not east asian characters. So talking about fixing the effect of combining characters on non-east asian charecters is IMHO, just as applicable as combining characters on asian text. And for display width, I'd say it is useful when writing to a terminal. But not it its current form. Combining characters obviously have no width, whether they are "wide"(which just means they are normally combined with wide characters) or not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 16:00 Message: Logged In: YES user_id=38388 It would help if you would include the Unicode code point descriptions... 01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER Z BAR;;;01B6; 0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;; 0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING DIAERESIS;Dialytika;;; Ie. your example does not even include East Asian characters. If you read the TR11, you'll find that: """ ED7. Not East Asian (Neutral) - all other characters. Neutral characters do not occur in legacy East Asian character sets. By extension, they also do not occur in East Asian typography. For example, there is no traditional Japanese way of typesetting Devanagari. Strictly speaking, it makes no sense to talk of narrow and wide for neutral characters, but since for all practical purposes they behave like Na, they are treated as narrow characters (the same as Na) under the recommendations below. """ Combining marks as the ones that your example uses cannot be processed by doing a simple database lookup. The two marks you include are marked as A -- Ambiguous. Furthermore, you should not mistake the East Asian Width for the display width. It is merely a hint for rendering engines. See the TR for details. Hye-Shik, could you give an example of where the EAS is actually useful in Python programming ? I hvae a feeling that it is going to cause more confusion than do good. It may also be wise to rename the function to east_asian_width() to signal that the return value does not have anything to do with a display with, glyphs, etc. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 15:06 Message: Logged In: YES user_id=65253 I don't think normalization is sufficient. For example, consider: >>> u'\u01b5\u0327\u0308'.width() 3 >>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width() 3 But width should be one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 11:45 Message: Logged In: YES user_id=38388 To be honest: I don't really know how .width() ended up as method. The use context seems to be rather limited in that it only applies to East Asian code points according to Unicode Standard Annex #11. I'd suggest to move the whole implementation to unicodedata instead (and then apply normalization before looking up the width). Reading the UAX11 (http://www.unicode.org/reports/tr11/) I also have a feeling that taking the sum of all widths in a string of Unicode code points is not a very useful approach. Since the width is mainly used for rendering East Asian text, only the per code point information is useful. I think that it would be more appropriate to raise an exception if you pass in more than one code point to the function. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-12 06:46 Message: Logged In: YES user_id=55188 This sounds that we need to normalize to NFC before evaluations for unicode.width(). So, I think we'll need to choose how to use normalization database from width() method. 1. export normalization CAPI functions from unicodedata module like ucnhash_CAPI and unicodeobject uses it when width() is first called. 2. move unicode.width() to unicodedata module and use normalization functions statically. I would prefer 2. ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470 From noreply at sourceforge.net Tue Aug 3 17:21:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 17:22:05 2004 Subject: [ python-Bugs-1002530 ] test_decimal fails if repeated Message-ID: Bugs item #1002530, was opened at 2004-08-03 05:58 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002530&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Raymond Hettinger (rhettinger) Summary: test_decimal fails if repeated Initial Comment: You can see this by trying, eg, $ ./python ../Lib/test/regrtest.py test_decimal test_decimal I think it's something like precision not being restored in the default context, but I don't really know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002530&group_id=5470 From noreply at sourceforge.net Tue Aug 3 18:03:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 18:03:41 2004 Subject: [ python-Bugs-882332 ] boolobject.h documentation missing from Python/C API Message-ID: Bugs item #882332, was opened at 2004-01-22 14:13 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882332&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: boolobject.h documentation missing from Python/C API Initial Comment: The items in boolobject.h do not appear to be documented in the current documentation. I just checked the index of the online docs and PyBool_FromLong, Py_True, and Py_False are all missing. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-03 12:03 Message: Logged In: YES user_id=3066 I made a minor change to avoid excessive nesting of sections by moving the booleans section up one level. Otherwise, this looks fine. Closing. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-07-28 22:19 Message: Logged In: YES user_id=44345 I just added Py_True/Py_False (concrete.tex v1.50). Leaving for Fred to review and close. I will backport the relevant bits to the 2.3 branch as well. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-07-28 11:14 Message: Logged In: YES user_id=3066 Skip added much of the missing documentation in Doc/api/concrete.tex revision 1.49. Py_True and Py_False still need to be added. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=882332&group_id=5470 From noreply at sourceforge.net Tue Aug 3 18:19:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 18:19:59 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 11:26 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 19:19 Message: Logged In: YES user_id=358087 Attaching the whole log just in case :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 16:14 Message: Logged In: YES user_id=21627 Can you report the relevant section from config.log where configure disables sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Tue Aug 3 18:57:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 18:57:36 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 10:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 18:57 Message: Logged In: YES user_id=21627 Please retry, checking the checkbox. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 18:19 Message: Logged In: YES user_id=358087 Attaching the whole log just in case :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 15:14 Message: Logged In: YES user_id=21627 Can you report the relevant section from config.log where configure disables sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Tue Aug 3 19:35:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 19:35:47 2004 Subject: [ python-Bugs-1002763 ] asynchat does not accept 'long' terminator Message-ID: Bugs item #1002763, was opened at 2004-08-03 10:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002763&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jey Kottalam (jeyk) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat does not accept 'long' terminator Initial Comment: I was browsing the asynchat source code and noticed that the asynchat module accepts ints but not longs for the set_terminator function. I'm attaching a patch that allows it to accept longs as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002763&group_id=5470 From noreply at sourceforge.net Tue Aug 3 19:37:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 19:37:08 2004 Subject: [ python-Bugs-1002763 ] asynchat does not accept 'long' terminator Message-ID: Bugs item #1002763, was opened at 2004-08-03 10:35 Message generated for change (Settings changed) made by jeyk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002763&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jey Kottalam (jeyk) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat does not accept 'long' terminator Initial Comment: I was browsing the asynchat source code and noticed that the asynchat module accepts ints but not longs for the set_terminator function. I'm attaching a patch that allows it to accept longs as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002763&group_id=5470 From noreply at sourceforge.net Tue Aug 3 19:56:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 19:56:56 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 11:26 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 20:56 Message: Logged In: YES user_id=358087 Sorry. Hope it's OK now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 19:57 Message: Logged In: YES user_id=21627 Please retry, checking the checkbox. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 19:19 Message: Logged In: YES user_id=358087 Attaching the whole log just in case :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 16:14 Message: Logged In: YES user_id=21627 Can you report the relevant section from config.log where configure disables sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Tue Aug 3 20:02:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 20:02:59 2004 Subject: [ python-Bugs-658254 ] Accept None for time.ctime() and friends Message-ID: Bugs item #658254, was opened at 2002-12-24 11:58 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658254&group_id=5470 Category: Extension Modules Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Accept None for time.ctime() and friends Initial Comment: Several functions in the time module can have the time value they operate on omitted to indicate the current time, but they do not accept None as equivalent to omitting the value. It should be equivalent. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-03 14:02 Message: Logged In: YES user_id=3066 Fixed using portions of SF patch #663482 and new implementation and test patches. Doc/lib/libtime.tex 1.65 Lib/test/test_time.py 1.18 Misc/NEWS 1.1065 Modules/timemodule.c 2.144 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-02 03:03 Message: Logged In: YES user_id=80475 Assigning back to Fred. I fully support the ipath on the basis that it will make user code less complicated. Blunk's patch had some minor review comments, but is basically ready to go. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-10 11:45 Message: Logged In: YES user_id=3066 I generally expect that None should be accepted for an omitted arg, but Guido has certainly never cared about that. Given that no existing code passes None, it's ok to reject. If the truth be told, though, the current situation certainly complicates some existing code! ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-06 22:43 Message: Logged In: YES user_id=531881 see patch 663482 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658254&group_id=5470 From noreply at sourceforge.net Tue Aug 3 21:21:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 3 21:22:03 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 10:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 21:21 Message: Logged In: YES user_id=21627 Got the file in email now; 290k is too large for an SF attachment. However, I still cannot find out what you mean by "./configure disables socket module". What message that you got are you referring to, and what specifically did you do to "add it manually"? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 19:56 Message: Logged In: YES user_id=358087 Sorry. Hope it's OK now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 18:57 Message: Logged In: YES user_id=21627 Please retry, checking the checkbox. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 18:19 Message: Logged In: YES user_id=358087 Attaching the whole log just in case :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 15:14 Message: Logged In: YES user_id=21627 Can you report the relevant section from config.log where configure disables sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Wed Aug 4 00:58:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 00:58:37 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by peter_jacobi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-04 00:58 Message: Logged In: YES user_id=845149 Attached are the output if gencodec.py for ISO-8859-11, ISO-8859-16 and for reference also the original mapping files. Peter ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:34 Message: Logged In: YES user_id=38388 Peter, could you attach the generated codecs to this report ? Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-02 13:14 Message: Logged In: YES user_id=38388 Martin, I think it's a good idea to add the codecs for completeness. We should probably also review the mapping files posted on the unicode.org site every now and then and update the codecs in Python accordingly. Sticking to the Unicode Consortium's view of things is a good way to assure compatibility with other applications, IMO. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Wed Aug 4 03:52:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 03:52:53 2004 Subject: [ python-Bugs-990911 ] Crash from Rapid Clicks Message-ID: Bugs item #990911, was opened at 2004-07-14 09:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Karl (thedisciple) Assigned to: Kurt B. Kaiser (kbk) Summary: Crash from Rapid Clicks Initial Comment: IDLE crashes when I rapidly (within 1/2 second, maybe) click the Run, then Options menus on the menu bar. These seem to be the only menus for which the crash happens, which is odd. I'm running Windows XP SP1 on an AMD system using Python 2.3.3 ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-03 20:52 Message: Logged In: YES user_id=149084 I can't duplicate this on W2K using 2.3.4 or 2.4a1. Please try 2.4a2 when it comes out and if this issue is still there please provide the code which was running and whether you used F5 or the menu to start the run. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-20 20:46 Message: Logged In: YES user_id=33168 Kurt, have you heard of this before? ---------------------------------------------------------------------- Comment By: Karl (thedisciple) Date: 2004-07-14 11:04 Message: Logged In: YES user_id=1083575 Update: With a little more expirimentation I found that it often crashes whenever any of the last 3 menus (Options, Windows, Help) are clicked. It works fine if another menu is clicked then the mouse is moved over one of the last three menus to open it. I also noticed that after crashing the program many times to determine the problem, I see about twenty pythonw.exe processes running in Windows Task Manager. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990911&group_id=5470 From noreply at sourceforge.net Wed Aug 4 03:57:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 03:57:23 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 03:41 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-03 20:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 04:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 03:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Wed Aug 4 06:03:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 06:03:34 2004 Subject: [ python-Bugs-775541 ] idle.py doesn't accept ( in some cases Message-ID: Bugs item #775541, was opened at 2003-07-22 04:31 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Gregor Lingl (glingl) Assigned to: Kurt B. Kaiser (kbk) Summary: idle.py doesn't accept ( in some cases Initial Comment: I start IDLE in one-process-mode, in order to be able to use turtle.py in interactive mode. i:\python23\python.exe idle.py -n I enter in the shell-window: Python 2.3c1 (#44, Jul 18 2003, 14:32:36) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0rc1 ==== No Subprocess ==== >>> from turtle import * >>> Exception in Tkinter callback Traceback (most recent call last): File "I:\Python23\lib\lib-tk\Tkinter.py", line 1345, in __call__ return self.func(*args) File "i:\python23\lib\idlelib\CallTips.py", line 47, in paren_open_event arg_text = self.fetch_tip(name) File "i:\python23\lib\idlelib\CallTips.py", line 106, in fetch_tip return get_arg_text(entity) File "i:\python23\lib\idlelib\CallTips.py", line 165, in get_arg_text doc = getattr(ob, "__doc__", "").lstrip() AttributeError: 'NoneType' object has no attribute 'lstrip' forward( Just after typing the opening parentheses after the function name forward the shown error-message appears, and the just typed in forward( is appended to it. When I continue e.g. with 50), the turtle does, what I want. The same with all following function-calls. Maybe the reason for this bug lies (in some way) in turtle.py. Nevertheless, IMHO IDLE SHOULD accept modules like turtle.py withoult breaking (I can't understand how getattr with 3. arg "" can return NoneType at all. Or is this a bug in getattr?) Interestingly IDLE started ordinarily in multiprocess mode doesn't show this behaviour. >>> from turtle import * >>> forward(50 Alas! It's not recommended to complete this, as then IDLE would hang from other reasons ... Regards, Gregor ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-03 23:03 Message: Logged In: YES user_id=149084 Original problem fixed 23Jul03. I find that IDLE 1.1a2 with subprocess works OK with turtle.py. If there are problems I haven't detected, please enter as separate bugs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 17:28 Message: Logged In: YES user_id=149084 Basic cause is fixed. I had some comments on his comments on turtle.py which I'm holding off until I can get 2.3rc2 on XP. Lowering priority. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 17:03 Message: Logged In: YES user_id=149084 Basic cause is fixed. I had some comments on his comments on turtle.py which I'm holding off until I can get 2.3rc2 on XP. Lowering priority. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-23 16:43 Message: Logged In: YES user_id=12800 Kurt, you applied the referenced patch, right? So this bug report can be closed, right? If so, please do. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 00:04 Message: Logged In: YES user_id=149084 functions/methods with no docstrings will raise this error. Patch 776062 submitted for 2.3rc2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 From noreply at sourceforge.net Wed Aug 4 08:40:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 08:40:29 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 11:26 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 09:40 Message: Logged In: YES user_id=358087 When running "./configure --prefix=/usr" python is built OK, but socketmodule (_socket.dll) is not build. There is no message on that. By "adding manually" I mean uncommeting the socketmodule line in Modules/Setup and then running "make". Then the build system tries to build socketmodule and fails with the above error. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 22:21 Message: Logged In: YES user_id=21627 Got the file in email now; 290k is too large for an SF attachment. However, I still cannot find out what you mean by "./configure disables socket module". What message that you got are you referring to, and what specifically did you do to "add it manually"? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 20:56 Message: Logged In: YES user_id=358087 Sorry. Hope it's OK now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 19:57 Message: Logged In: YES user_id=21627 Please retry, checking the checkbox. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 19:19 Message: Logged In: YES user_id=358087 Attaching the whole log just in case :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 16:14 Message: Logged In: YES user_id=21627 Can you report the relevant section from config.log where configure disables sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Wed Aug 4 09:41:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 09:41:11 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 20:26 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-08-04 19:41 Message: Logged In: YES user_id=552329 I get exactly the same results as tebeka, FWIW. (make works fine, but doesn't build the module, then uncommenting the line gives the above error). ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 18:40 Message: Logged In: YES user_id=358087 When running "./configure --prefix=/usr" python is built OK, but socketmodule (_socket.dll) is not build. There is no message on that. By "adding manually" I mean uncommeting the socketmodule line in Modules/Setup and then running "make". Then the build system tries to build socketmodule and fails with the above error. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 07:21 Message: Logged In: YES user_id=21627 Got the file in email now; 290k is too large for an SF attachment. However, I still cannot find out what you mean by "./configure disables socket module". What message that you got are you referring to, and what specifically did you do to "add it manually"? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 05:56 Message: Logged In: YES user_id=358087 Sorry. Hope it's OK now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 04:57 Message: Logged In: YES user_id=21627 Please retry, checking the checkbox. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 04:19 Message: Logged In: YES user_id=358087 Attaching the whole log just in case :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 01:14 Message: Logged In: YES user_id=21627 Can you report the relevant section from config.log where configure disables sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Wed Aug 4 09:44:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 09:44:27 2004 Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters Message-ID: Bugs item #989185, was opened at 2004-07-12 12:59 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode.width broken for combining characters Initial Comment: Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) [GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> u'\u3060'.width() 2 >>> u'\u305f\u3099'.width() 4 Width should be two in both cases. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-04 16:44 Message: Logged In: YES user_id=55188 Committed in CVS. Doc/api/concrete.tex 1.54 Doc/lib/libstdtypes.tex 1.159 Doc/lib/libunicodedata.tex 1.6 Include/unicodeobject.h 2.45 Lib/test/string_tests.py 1.39 Lib/test/test_unicode.py 1.92 Lib/test/test_unicodedata.py 1.11 Lib/test/test_userstring.py 1.13 Misc/NEWS 1.1068 Modules/unicodedata.c 2.32 Modules/unicodedata_db.h 1.11 Objects/unicodectype.c 2.16 Objects/unicodeobject.c 2.219 Objects/unicodetype_db.h 1.9 Tools/unicode/makeunicodedata.py 1.19 Thanks! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 23:39 Message: Logged In: YES user_id=38388 Looks good. Please check it in. Thanks, Hye-Shik ! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-02 01:01 Message: Logged In: YES user_id=55188 Here's my revised patch for new API. :) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 21:31 Message: Logged In: YES user_id=38388 Great ! Thanks. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-23 21:29 Message: Logged In: YES user_id=55188 Yes. I am. I was little bit busy. I'll submit new patch after this weekend. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 19:12 Message: Logged In: YES user_id=38388 Hye-Shik, are you working on a patch to move the implementation as suggested ? Just asking, because I don't was the current layout to go into the Python 2.4 final... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-16 02:36 Message: Logged In: YES user_id=38388 Martin, you can code such a function in your application based on the information you'd get from unicodedata.east_asian_width(). As we've seen, there is no generally sound way to define such a function. As for the location of the data: the unicodedata module is the place where any extra information related to Unicode should go. unicodectype.c is reserved for data needed at C level by the Python Unicode C API. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-16 02:24 Message: Logged In: YES user_id=21627 I still think a function is useful which computes the number of Ems that a conventional application would expect. That function should raise an exception for a neutral character - the example of the combining characters shows that such characters should *not* be treated as narrow "for all practical purposes". Whether or not it is useful to include the entire UAX#11 classification in the database I don't know - it seems the only application of the data would be computation of the width, anyway. It would not be wise to move the data to the unicode database, as the extra data currently don't affect Python programs that don't use the function, anyway - the data does not consume any additional space. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-15 18:39 Message: Logged In: YES user_id=38388 Hye-Shik, the patch only includes the move to unicodedata, but not the full implementation of the EAW as per the TR. I would much prefer to have the east_asian_width() function return the strings defined in the TR because this allows users of the function to read the information and implement their own interpretation of "width". The new function should work very much like unicodedata.category(). It would also be wise to move the data itself over to the unicode database - that way the extra data does not affect Python programs that don't use the function. Thanks. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-15 00:15 Message: Logged In: YES user_id=55188 Marc-Andre, here's a patch written as you've suggested. Can you please give a review on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-13 04:41 Message: Logged In: YES user_id=38388 Thanks for your descriptions, Hye-Shik. Since the application space is very much targetted at East Asian scripts, I would like the implementation to be moved into unicodedata where all the other special Unicode features are implemented. The .width() method should be removed. Now that I understand better what the EAW is about, I would also like to see the function be renamed to east_asian_width() since that's what the function is based on. If possible, I'd also rather like to see the full width mapping implemented (as defined in the TR). The reduction to narrow vs. wide seems to be oversimplified. The east_asian_width() function should return the characters: "N", "A", "H", "W", "F", "Na" and let the user decide how to map these to character or string widths. We have followed the same methodology for the other Unicode database properties and this has not only given us much more flexibility, it also is standards compliant and you can get good documentation on these features. Matthew, I suggest you write your own implementation of what you think is right. In the face of ambiguity, there's no such thing as the right approach to a certain problem. Thanks. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-13 01:03 Message: Logged In: YES user_id=65253 My complaint was that you were attacking my example using non-asian characters, when the TR specifically says they are handled as narrow. I write Asian characters the same as anything else. If it's a unicode string python converts it with sys.stdout.encoding (for print anyway). Otherwise you just have to write in whatever encoding the terminal expects. And when you are talking about a fixed-width text terminal, wide characters take 2 columns, narrow take 1. Assuming you ignore combining characters, which is what this is all about. You said the width is only a "hint for rendering engines", but I cannot think of any rendering engine that would benefit from a hint that can be 2-3x wider (due to counting combining characters) than when you actually display it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-13 00:53 Message: Logged In: YES user_id=55188 Major usages that I expected for width() are: - Hints for terminal-based applications (for cursor position and layouts) - To generate fixed-width text documents not ugly: eg. printing "------" decoration under each subjects. - More readable limit for table columns: eg. topics in web bulletins; limiting by same 'characters' will recur very wide some topic lines full of East Asian characters and narrow snipped english topics. - To locate "^" in correct position on Python tracebacks. This isn't implemented in standard traceback, but width() allows 3rd party can implement sys.excepthook for East Asian easily. In fact, I don't known if width() can easily modified to support variety of combining characters from Western characters. But if it isn't too heavy or complicated, I would volunteer to extend the width() implemention to make it provide generic fixed-width rendering hint. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-13 00:23 Message: Logged In: YES user_id=38388 I don't understand your complaint: width 1 means "narrow" just as defined in the TR ?! How do you write Asian characters to a terminal ? I think you are mixing glyphs with code points here. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 23:28 Message: Logged In: YES user_id=65253 TR11 says "Strictly speaking, it makes no sense to talk of narrow and wide for neutral characters, but since for all practical purposes they behave like Na, they are treated as narrow characters (the same as Na) under the recommendations below." In addition, the current implementation gives a width of 1 to not east asian characters. So talking about fixing the effect of combining characters on non-east asian charecters is IMHO, just as applicable as combining characters on asian text. And for display width, I'd say it is useful when writing to a terminal. But not it its current form. Combining characters obviously have no width, whether they are "wide"(which just means they are normally combined with wide characters) or not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 23:00 Message: Logged In: YES user_id=38388 It would help if you would include the Unicode code point descriptions... 01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER Z BAR;;;01B6; 0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;; 0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING DIAERESIS;Dialytika;;; Ie. your example does not even include East Asian characters. If you read the TR11, you'll find that: """ ED7. Not East Asian (Neutral) - all other characters. Neutral characters do not occur in legacy East Asian character sets. By extension, they also do not occur in East Asian typography. For example, there is no traditional Japanese way of typesetting Devanagari. Strictly speaking, it makes no sense to talk of narrow and wide for neutral characters, but since for all practical purposes they behave like Na, they are treated as narrow characters (the same as Na) under the recommendations below. """ Combining marks as the ones that your example uses cannot be processed by doing a simple database lookup. The two marks you include are marked as A -- Ambiguous. Furthermore, you should not mistake the East Asian Width for the display width. It is merely a hint for rendering engines. See the TR for details. Hye-Shik, could you give an example of where the EAS is actually useful in Python programming ? I hvae a feeling that it is going to cause more confusion than do good. It may also be wise to rename the function to east_asian_width() to signal that the return value does not have anything to do with a display with, glyphs, etc. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 22:06 Message: Logged In: YES user_id=65253 I don't think normalization is sufficient. For example, consider: >>> u'\u01b5\u0327\u0308'.width() 3 >>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width() 3 But width should be one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 18:45 Message: Logged In: YES user_id=38388 To be honest: I don't really know how .width() ended up as method. The use context seems to be rather limited in that it only applies to East Asian code points according to Unicode Standard Annex #11. I'd suggest to move the whole implementation to unicodedata instead (and then apply normalization before looking up the width). Reading the UAX11 (http://www.unicode.org/reports/tr11/) I also have a feeling that taking the sum of all widths in a string of Unicode code points is not a very useful approach. Since the width is mainly used for rendering East Asian text, only the per code point information is useful. I think that it would be more appropriate to raise an exception if you pass in more than one code point to the function. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-12 13:46 Message: Logged In: YES user_id=55188 This sounds that we need to normalize to NFC before evaluations for unicode.width(). So, I think we'll need to choose how to use normalization database from width() method. 1. export normalization CAPI functions from unicodedata module like ucnhash_CAPI and unicodeobject uses it when width() is first called. 2. move unicode.width() to unicodedata module and use normalization functions statically. I would prefer 2. ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470 From noreply at sourceforge.net Wed Aug 4 10:04:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 10:04:40 2004 Subject: [ python-Bugs-989185 ] unicode.width broken for combining characters Message-ID: Bugs item #989185, was opened at 2004-07-12 05:59 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470 Category: Unicode Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: M.-A. Lemburg (lemburg) Summary: unicode.width broken for combining characters Initial Comment: Python 2.4a1+ (#38, Jul 11 2004, 20:36:10) [GCC 3.3.4 (Debian 1:3.3.4-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> u'\u3060'.width() 2 >>> u'\u305f\u3099'.width() 4 Width should be two in both cases. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-04 09:44 Message: Logged In: YES user_id=55188 Committed in CVS. Doc/api/concrete.tex 1.54 Doc/lib/libstdtypes.tex 1.159 Doc/lib/libunicodedata.tex 1.6 Include/unicodeobject.h 2.45 Lib/test/string_tests.py 1.39 Lib/test/test_unicode.py 1.92 Lib/test/test_unicodedata.py 1.11 Lib/test/test_userstring.py 1.13 Misc/NEWS 1.1068 Modules/unicodedata.c 2.32 Modules/unicodedata_db.h 1.11 Objects/unicodectype.c 2.16 Objects/unicodeobject.c 2.219 Objects/unicodetype_db.h 1.9 Tools/unicode/makeunicodedata.py 1.19 Thanks! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:39 Message: Logged In: YES user_id=38388 Looks good. Please check it in. Thanks, Hye-Shik ! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-01 18:01 Message: Logged In: YES user_id=55188 Here's my revised patch for new API. :) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 14:31 Message: Logged In: YES user_id=38388 Great ! Thanks. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-23 14:29 Message: Logged In: YES user_id=55188 Yes. I am. I was little bit busy. I'll submit new patch after this weekend. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-23 12:12 Message: Logged In: YES user_id=38388 Hye-Shik, are you working on a patch to move the implementation as suggested ? Just asking, because I don't was the current layout to go into the Python 2.4 final... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-15 19:36 Message: Logged In: YES user_id=38388 Martin, you can code such a function in your application based on the information you'd get from unicodedata.east_asian_width(). As we've seen, there is no generally sound way to define such a function. As for the location of the data: the unicodedata module is the place where any extra information related to Unicode should go. unicodectype.c is reserved for data needed at C level by the Python Unicode C API. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-07-15 19:24 Message: Logged In: YES user_id=21627 I still think a function is useful which computes the number of Ems that a conventional application would expect. That function should raise an exception for a neutral character - the example of the combining characters shows that such characters should *not* be treated as narrow "for all practical purposes". Whether or not it is useful to include the entire UAX#11 classification in the database I don't know - it seems the only application of the data would be computation of the width, anyway. It would not be wise to move the data to the unicode database, as the extra data currently don't affect Python programs that don't use the function, anyway - the data does not consume any additional space. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-15 11:39 Message: Logged In: YES user_id=38388 Hye-Shik, the patch only includes the move to unicodedata, but not the full implementation of the EAW as per the TR. I would much prefer to have the east_asian_width() function return the strings defined in the TR because this allows users of the function to read the information and implement their own interpretation of "width". The new function should work very much like unicodedata.category(). It would also be wise to move the data itself over to the unicode database - that way the extra data does not affect Python programs that don't use the function. Thanks. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-14 17:15 Message: Logged In: YES user_id=55188 Marc-Andre, here's a patch written as you've suggested. Can you please give a review on this? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 21:41 Message: Logged In: YES user_id=38388 Thanks for your descriptions, Hye-Shik. Since the application space is very much targetted at East Asian scripts, I would like the implementation to be moved into unicodedata where all the other special Unicode features are implemented. The .width() method should be removed. Now that I understand better what the EAW is about, I would also like to see the function be renamed to east_asian_width() since that's what the function is based on. If possible, I'd also rather like to see the full width mapping implemented (as defined in the TR). The reduction to narrow vs. wide seems to be oversimplified. The east_asian_width() function should return the characters: "N", "A", "H", "W", "F", "Na" and let the user decide how to map these to character or string widths. We have followed the same methodology for the other Unicode database properties and this has not only given us much more flexibility, it also is standards compliant and you can get good documentation on these features. Matthew, I suggest you write your own implementation of what you think is right. In the face of ambiguity, there's no such thing as the right approach to a certain problem. Thanks. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 18:03 Message: Logged In: YES user_id=65253 My complaint was that you were attacking my example using non-asian characters, when the TR specifically says they are handled as narrow. I write Asian characters the same as anything else. If it's a unicode string python converts it with sys.stdout.encoding (for print anyway). Otherwise you just have to write in whatever encoding the terminal expects. And when you are talking about a fixed-width text terminal, wide characters take 2 columns, narrow take 1. Assuming you ignore combining characters, which is what this is all about. You said the width is only a "hint for rendering engines", but I cannot think of any rendering engine that would benefit from a hint that can be 2-3x wider (due to counting combining characters) than when you actually display it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-12 17:53 Message: Logged In: YES user_id=55188 Major usages that I expected for width() are: - Hints for terminal-based applications (for cursor position and layouts) - To generate fixed-width text documents not ugly: eg. printing "------" decoration under each subjects. - More readable limit for table columns: eg. topics in web bulletins; limiting by same 'characters' will recur very wide some topic lines full of East Asian characters and narrow snipped english topics. - To locate "^" in correct position on Python tracebacks. This isn't implemented in standard traceback, but width() allows 3rd party can implement sys.excepthook for East Asian easily. In fact, I don't known if width() can easily modified to support variety of combining characters from Western characters. But if it isn't too heavy or complicated, I would volunteer to extend the width() implemention to make it provide generic fixed-width rendering hint. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 17:23 Message: Logged In: YES user_id=38388 I don't understand your complaint: width 1 means "narrow" just as defined in the TR ?! How do you write Asian characters to a terminal ? I think you are mixing glyphs with code points here. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 16:28 Message: Logged In: YES user_id=65253 TR11 says "Strictly speaking, it makes no sense to talk of narrow and wide for neutral characters, but since for all practical purposes they behave like Na, they are treated as narrow characters (the same as Na) under the recommendations below." In addition, the current implementation gives a width of 1 to not east asian characters. So talking about fixing the effect of combining characters on non-east asian charecters is IMHO, just as applicable as combining characters on asian text. And for display width, I'd say it is useful when writing to a terminal. But not it its current form. Combining characters obviously have no width, whether they are "wide"(which just means they are normally combined with wide characters) or not. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 16:00 Message: Logged In: YES user_id=38388 It would help if you would include the Unicode code point descriptions... 01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER Z BAR;;;01B6; 0327;COMBINING CEDILLA;Mn;202;NSM;;;;;N;NON-SPACING CEDILLA;;;; 0308;COMBINING DIAERESIS;Mn;230;NSM;;;;;N;NON-SPACING DIAERESIS;Dialytika;;; Ie. your example does not even include East Asian characters. If you read the TR11, you'll find that: """ ED7. Not East Asian (Neutral) - all other characters. Neutral characters do not occur in legacy East Asian character sets. By extension, they also do not occur in East Asian typography. For example, there is no traditional Japanese way of typesetting Devanagari. Strictly speaking, it makes no sense to talk of narrow and wide for neutral characters, but since for all practical purposes they behave like Na, they are treated as narrow characters (the same as Na) under the recommendations below. """ Combining marks as the ones that your example uses cannot be processed by doing a simple database lookup. The two marks you include are marked as A -- Ambiguous. Furthermore, you should not mistake the East Asian Width for the display width. It is merely a hint for rendering engines. See the TR for details. Hye-Shik, could you give an example of where the EAS is actually useful in Python programming ? I hvae a feeling that it is going to cause more confusion than do good. It may also be wise to rename the function to east_asian_width() to signal that the return value does not have anything to do with a display with, glyphs, etc. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2004-07-12 15:06 Message: Logged In: YES user_id=65253 I don't think normalization is sufficient. For example, consider: >>> u'\u01b5\u0327\u0308'.width() 3 >>> unicodedata.normalize('NFC',u'\u01b5\u0327\u0308').width() 3 But width should be one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-07-12 11:45 Message: Logged In: YES user_id=38388 To be honest: I don't really know how .width() ended up as method. The use context seems to be rather limited in that it only applies to East Asian code points according to Unicode Standard Annex #11. I'd suggest to move the whole implementation to unicodedata instead (and then apply normalization before looking up the width). Reading the UAX11 (http://www.unicode.org/reports/tr11/) I also have a feeling that taking the sum of all widths in a string of Unicode code points is not a very useful approach. Since the width is mainly used for rendering East Asian text, only the per code point information is useful. I think that it would be more appropriate to raise an exception if you pass in more than one code point to the function. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-12 06:46 Message: Logged In: YES user_id=55188 This sounds that we need to normalize to NFC before evaluations for unicode.width(). So, I think we'll need to choose how to use normalization database from width() method. 1. export normalization CAPI functions from unicodedata module like ucnhash_CAPI and unicodeobject uses it when width() is first called. 2. move unicode.width() to unicodedata module and use normalization functions statically. I would prefer 2. ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989185&group_id=5470 From noreply at sourceforge.net Wed Aug 4 10:11:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 10:11:28 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 11:41 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 11:11 Message: Logged In: YES user_id=358087 1. "Pure" Python (without IDLE) don't hang after 2 hours 2. I didn't try this time but I'm pretty sure it hanged without screen saver as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-04 04:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 12:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 11:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Wed Aug 4 10:31:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 10:31:58 2004 Subject: [ python-Bugs-1002537 ] test_logging fails if run twice Message-ID: Bugs item #1002537, was opened at 2004-08-03 11:17 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002537&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Vinay Sajip (vsajip) Summary: test_logging fails if run twice Initial Comment: Traceback (most recent call last): File "/Users/mwh/Source/python/dist/src/Lib/logging/ __init__.py", line 696, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file over and over again. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-08-04 08:31 Message: Logged In: YES user_id=308438 Fixed by closing used handlers and tidying up loggers to remove closed handlers. Checked into CVS. Tested on Windows only. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-03 11:28 Message: Logged In: YES user_id=29957 Commenting out line 467 stops these errors, but there's still a keyerror lying around. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002537&group_id=5470 From noreply at sourceforge.net Wed Aug 4 10:38:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 10:38:33 2004 Subject: [ python-Bugs-992397 ] variable reuse in the logging module Message-ID: Bugs item #992397, was opened at 2004-07-16 15:18 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992397&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Gintautas Miliauskas (gintautasm) Assigned to: Vinay Sajip (vsajip) Summary: variable reuse in the logging module Initial Comment: I accidentally tried to pass logging levels as strings to Logger.log() instead of numbers. The result was that %(levelname)s produced the number of the level specified and %(levelno)s produced the name... I assumed that passing strings was valid, because if you passed an unregistered level name, the %(levelname)s would just say 'Level XYZ' instead of 'XYZ'. The culprit is this dict in logging/__init__.py: _levelNames = { CRITICAL : 'CRITICAL', ERROR : 'ERROR', WARNING : 'WARNING', INFO : 'INFO', DEBUG : 'DEBUG', NOTSET : 'NOTSET', 'CRITICAL' : CRITICAL, 'ERROR' : ERROR, 'WARN' : WARNING, 'WARNING' : WARNING, 'INFO' : INFO, 'DEBUG' : DEBUG, 'NOTSET' : NOTSET, } I think it would be a good idea to split this dict into two, so that such confusion doesn't result. Also, it should be explicitly stated (in the docs and maybe in code too) if a name of the level as a string argument to Logger.log() is valid or not. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-08-04 08:38 Message: Logged In: YES user_id=308438 Current CVS Logger.log() throws an exception ("level must be an integer") if you don't pass an integer level, and if raiseExceptions is set. The _levelNames approach is by design. It avoids having two dictionaries and two function calls. Documentation/docstring for Logger.log() updated to indicate that "lvl" should be an integer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992397&group_id=5470 From noreply at sourceforge.net Wed Aug 4 13:43:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 13:43:41 2004 Subject: [ python-Bugs-1003195 ] segfault when running smtplib example Message-ID: Bugs item #1003195, was opened at 2004-08-04 13:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: segfault when running smtplib example Initial Comment: On my system, running the simple smtplib Example from the Documentation results in a segmentation fault. Execution stops and no mail is submitted. I debugged into the Python source code, but my understanding of the inner mechanisms doesn't suffice to fix the problem. I update my system periodically using "apt-get update ; apt-get upgrade". I don't remember, when it was the last time Python was upgraded. I made the files availabe: http://www.bertram-scharpf.de/tmp/smtpex.py.txt http://www.bertram-scharpf.de/tmp/smtpex.desc.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 From noreply at sourceforge.net Wed Aug 4 14:36:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 14:36:07 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 04:26 Message generated for change (Comment added) made by plusk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-04 08:36 Message: Logged In: YES user_id=1083789 The getaddrinfo.c errors seem to be similar to those I reported in #991125. (A required header file which resides in the same directory as getaddrinfo.c is in an #if 0 block. Fix that and getaddrinfo.c builds correctly). ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-08-04 03:41 Message: Logged In: YES user_id=552329 I get exactly the same results as tebeka, FWIW. (make works fine, but doesn't build the module, then uncommenting the line gives the above error). ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 02:40 Message: Logged In: YES user_id=358087 When running "./configure --prefix=/usr" python is built OK, but socketmodule (_socket.dll) is not build. There is no message on that. By "adding manually" I mean uncommeting the socketmodule line in Modules/Setup and then running "make". Then the build system tries to build socketmodule and fails with the above error. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 15:21 Message: Logged In: YES user_id=21627 Got the file in email now; 290k is too large for an SF attachment. However, I still cannot find out what you mean by "./configure disables socket module". What message that you got are you referring to, and what specifically did you do to "add it manually"? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 13:56 Message: Logged In: YES user_id=358087 Sorry. Hope it's OK now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 12:57 Message: Logged In: YES user_id=21627 Please retry, checking the checkbox. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 12:19 Message: Logged In: YES user_id=358087 Attaching the whole log just in case :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 09:14 Message: Logged In: YES user_id=21627 Can you report the relevant section from config.log where configure disables sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Wed Aug 4 15:02:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 15:02:50 2004 Subject: [ python-Bugs-1002465 ] MemoryError on AIX52 Message-ID: Bugs item #1002465, was opened at 2004-08-03 08:04 Message generated for change (Settings changed) made by richardjmason You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 9 Submitted By: Datranet (richardjmason) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError on AIX52 Initial Comment: I found the orginal problem when trying to send large email attachments on AIX 5.2. I tracked the issue down to the fact that a string can only grow to a very restricted size on AIX 5.2. bin2ascii fails at the pint the function tries to join the list togther to form 1 string. I wrote the following test program to prove the issue: a = '' cnt = 0 while cnt < 1024: a = a + 'x' cnt += 1 c = '' cnt = 0 while cnt < 1024: c = c + a cnt += 1 b = '' cnt2 = 0 while 1: b = b + c cnt2 += 1 print cnt2 On AIX 5.2 you get a MemoryError with a cnt2 value of 42. I can run the test program on all other platforms and get a cnt2 value over 150 before stopping to program myself. I have tried the binary python 2.2 from the IBM site and building python 2.3.4 myself using the gcc from the IBM site. Both fail with a cnt2 value of 42. Can anyone please advise on how to get AIX 5.2 to allow single objects to have more memory allocated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 From noreply at sourceforge.net Wed Aug 4 16:45:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 16:45:45 2004 Subject: [ python-Bugs-1003323 ] telnetlib on Windows: read_until() freezes Message-ID: Bugs item #1003323, was opened at 2004-08-04 10:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003323&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yannick Turgeon (yturgeon) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib on Windows: read_until() freezes Initial Comment: I'm currently trying to pass commands to a telnet session and get the texte generated (stdin + stdout) by the session. The problem I get is that the Telnet.read_until() function seems to freeze after a couple of command. I did a simplified script (attached) that reproduce the problem each time. In the script, when I send the command "echo bar7" to the telnet session, it freezes forever without a Timeout. I'm using 2.3.4 on Windows 2000 Server. According to a feedback for the comp.lang.python newsgroup, this problem do not occur on linux systems. Thanks Yannick yannick.turgeon@cablevision.qc.ca ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003323&group_id=5470 From noreply at sourceforge.net Wed Aug 4 19:36:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 19:36:44 2004 Subject: [ python-Bugs-991125 ] Make Problem on HPUX Message-ID: Bugs item #991125, was opened at 2004-07-14 21:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Nobody/Anonymous (nobody) Summary: Make Problem on HPUX Initial Comment: Build of _socket fails: In file included from /home/python/Python- 2.4a1/Modules/socketmodule.c:314: /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_gai_strerror': /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: `EAI_MAX' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: (Each undeclared identifier is reported only once /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: for each function it appears in.) /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_getaddrinfo': /home/python/Python-2.4a1/Modules/getaddrinfo.c:282: `EAI_BADHINTS' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:283: `AI_MASK' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:373: `EAI_PROTOCOL' undeclared (first use in this function) The problem seems to be that #include "addrinfo.h" is in an #if 0 block in getaddrinfo.c When that include is moved out of the #if 0 block, the _socket module compiles and make test does not show any errors. System information: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license The above problem occurs with both gcc and with HP's C compiler. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 19:36 Message: Logged In: YES user_id=21627 Does that mean HP-UX does not have a native getaddrinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 From noreply at sourceforge.net Wed Aug 4 20:09:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 20:09:56 2004 Subject: [ python-Bugs-1002465 ] MemoryError on AIX52 Message-ID: Bugs item #1002465, was opened at 2004-08-03 10:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Datranet (richardjmason) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError on AIX52 Initial Comment: I found the orginal problem when trying to send large email attachments on AIX 5.2. I tracked the issue down to the fact that a string can only grow to a very restricted size on AIX 5.2. bin2ascii fails at the pint the function tries to join the list togther to form 1 string. I wrote the following test program to prove the issue: a = '' cnt = 0 while cnt < 1024: a = a + 'x' cnt += 1 c = '' cnt = 0 while cnt < 1024: c = c + a cnt += 1 b = '' cnt2 = 0 while 1: b = b + c cnt2 += 1 print cnt2 On AIX 5.2 you get a MemoryError with a cnt2 value of 42. I can run the test program on all other platforms and get a cnt2 value over 150 before stopping to program myself. I have tried the binary python 2.2 from the IBM site and building python 2.3.4 myself using the gcc from the IBM site. Both fail with a cnt2 value of 42. Can anyone please advise on how to get AIX 5.2 to allow single objects to have more memory allocated. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 20:09 Message: Logged In: YES user_id=21627 You need to use a debugger to find the cause of the problem. What is the string parameter of the MemoryError? This might give a clue where precisely it is raised. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 From noreply at sourceforge.net Wed Aug 4 20:42:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 20:42:05 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability Message-ID: Bugs item #1003471, was opened at 2004-08-04 11:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Wed Aug 4 21:39:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 21:39:58 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-30 20:08 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 15:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 10:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Wed Aug 4 22:17:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 22:17:07 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 04:41 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 16:17 Message: Logged In: YES user_id=593130 By 'hangs' do you mean when viewing the TasKManager Applications list, and killable with its End Task button? or something more evil, like locks the computer and prevents rebooting? Even Outlook Express and Internet Explore, with MS's billions, still do the former. With Win95, 98, and XP home and pro, I have had several problems, often intermittent, and maybe hardware specific, with bad interactions between programs, screen savers, and stand-by. On LCDs (and, I believe, modern CRTs) 'screen savers' save nothing except the boredom of a constant picture. I would turn it off and also check screen properites/screensaver/power button and the bios to see if anything is scheduled to happen at 2 hours. The timing, if consistent, is definitely suspicious. A major change for Windows between 2.3.4 and 2.4 is the compiler 'upgrade' which could change a program's interaction with Windows and its vulnerability to bugs within. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 04:11 Message: Logged In: YES user_id=358087 1. "Pure" Python (without IDLE) don't hang after 2 hours 2. I didn't try this time but I'm pretty sure it hanged without screen saver as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-03 21:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 05:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 04:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Wed Aug 4 22:28:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 4 22:28:19 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-31 02:08 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-04 22:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 21:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 16:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Thu Aug 5 01:24:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 01:24:47 2004 Subject: [ python-Bugs-976878 ] PDB: unreliable breakpoints on functions Message-ID: Bugs item #976878, was opened at 2004-06-21 09:56 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=976878&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: PDB: unreliable breakpoints on functions Initial Comment: Breakpoints set on functions are unreliable because "pdb.Pdb.checkline" thinks lines inside a multi-column docstring were adequate lines for breakpoints. Of course, such breakpoints are ignored during execution. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-04 16:24 Message: Logged In: YES user_id=971153 Patch 1003640 should fix this problem ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-07-15 15:59 Message: Logged In: YES user_id=971153 I'd like to add that this bug is probably related (but not identical) to: bug#926369 & bug#875404 which are also caused by pdb.checkline() it might be a good idea to fix all three bugs at once... ---------------------------------------------------------------------- Comment By: Dieter Maurer (dmaurer) Date: 2004-06-21 09:58 Message: Logged In: YES user_id=265829 Patch attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=976878&group_id=5470 From noreply at sourceforge.net Thu Aug 5 01:25:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 01:25:44 2004 Subject: [ python-Bugs-926369 ] pdb sometimes sets breakpoints in the wrong location Message-ID: Bugs item #926369, was opened at 2004-03-30 16:22 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926369&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: pdb sometimes sets breakpoints in the wrong location Initial Comment: If one attempts to set a breakpoint in one line function: e.g for this code: def f(x): return x*x z=23 pdb silently sets a breakpoint on the line right after the function definition (i.e. outside the function body!): ../python pdb.py.v1.66 pdb_one_line_func > (1)?() (Pdb) b f Breakpoint 1 /src/Lib/pdb_one_line_func:3 (Pdb) c > /src/Lib/pdb_one_line_func(3)?() -> z=23 It's probably acceptable to limit pdb breakpoints to multiline functions, but i don't think, it's acceptable to create wrong breakpoints. Note: that anyone attempting to fix this should also take a look at bug 875404 (global statment causes breakpoints..), as both bugs are caused by pdb.checkline() logic ---------------------------------------------------------------------- >Comment By: Ilya Sandler (isandler) Date: 2004-08-04 16:25 Message: Logged In: YES user_id=971153 Patch 1003640 should fix this problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926369&group_id=5470 From noreply at sourceforge.net Thu Aug 5 01:26:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 01:26:43 2004 Subject: [ python-Bugs-875404 ] global stmt causes breakpoints to be ignored Message-ID: Bugs item #875404, was opened at 2004-01-12 06:52 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875404&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Maciej Kalisiak (mackal) Assigned to: Nobody/Anonymous (nobody) Summary: global stmt causes breakpoints to be ignored Initial Comment: It seems that having a "global" statement in "main()" (perhaps elsewhere too) causes pdb to ignore breakpoints in the whole application. See the attached example small program. Procedure: - pdb python_bug.py # the attached program - 's', and then 'n' once or twice to make sure prog loaded - 'break main' - 'c' If the "global foo" statement is present, pdb will not stop at the breakpoint. If it is commented out (and "foo = 1" as well, of course), the breakpoint is obeyed. I'm using Python 2.3 (from the Debian "sid" distribution) Tried under Linux 2.2.20, as well as 2.4.*. Maciej Kalisiak mac at dgp dot toronto dot edu ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-04 16:26 Message: Logged In: YES user_id=971153 Patch 1003640 should fix this problem ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-03-10 14:22 Message: Logged In: YES user_id=971153 The same behaviour exists in the CVS version of python Here is what (I think) happens: 1. When you try to set a break on a function: e.g "b main" pdb sets a breakpoint not at "def main", but at the next non comment/non-blank line of code 2. Sample code has "global " as a first non-comment/non-blank line of code, so that's where pdb sets the breakpoint 3. But global is a compile-time statement, the line with global is never reached at run time, so pdb never stops there Workaround for the original submitter: put any other executable stmt as the first line of your main(), or set a bkpt via line number However, this behaviour is still wrong...The bug could be probably fixed by adding more logic to pdb.checkline().... Are there any other compile-time only statements? I think I could submit a patch for this problem, but does anyone look at pdb related patches?? My previous pdb patch #896011 has been sitting in the queue for a month now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875404&group_id=5470 From noreply at sourceforge.net Thu Aug 5 03:28:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 03:28:21 2004 Subject: [ python-Bugs-1002475 ] email message parser doesn't handle \r\n correctly Message-ID: Bugs item #1002475, was opened at 2004-08-03 20:32 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Nobody/Anonymous (nobody) Summary: email message parser doesn't handle \r\n correctly Initial Comment: Header lines that end in \r\n only get the \n stripped, not the \r (unless it's the last header which does get the \r stripped): >>> import email.Parser >>> m = 'Header: text\r\nNext-Header: more text\r\n\r\nBody\r\n\r\n' >>> msg = email.Parser.Parser().parsestr(m) >>> msg.get('header') 'text\r' >>> msg.get('next-header') 'more text' >>> This bug showed itself in my SpamBayes setup using sb_imapfilter.py where base64-encoded text/html messages were not decoded in Message.get_payload because the call to get('content-transfer-encoding') returned the string 'base64\r' instead of 'base64'. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-08-05 13:28 Message: Logged In: YES user_id=552329 A patch to fix this is in: [ 1003693 ] Fix for 1002475 (Feedparser not handling \r\n correctly) http://sourceforge.net/tracker/index.php?func=detail&aid=1003693&group_id=5470&atid=305470 I'll try to write a test for it, too, and also attach that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 From noreply at sourceforge.net Thu Aug 5 06:04:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 06:04:33 2004 Subject: [ python-Bugs-988300 ] Compiler warnings for Modules/readline.c:flex_complete() Message-ID: Bugs item #988300, was opened at 2004-07-09 16:53 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470 Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Compiler warnings for Modules/readline.c:flex_complete() Initial Comment: When I compile on my OS X 10.3.4 with Fink's readline 4.3-25 I get the following two warnings: /Users/drifty/Code/CVS/python/dist/src/Modules/readline.c: In function `flex_complete': /Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: warning: implicit declaration of function `completion_matches' /Users/drifty/Code/CVS/python/dist/src/Modules/readline.c:604: warning: return makes pointer from integer without a cast Now, although I have a version greater than 4.2, this only makes sense if HAVE_RL_COMPLETION_MATCHES is undefined and thus the completion_matches() macro is not being defined (although I checked and the headers have a prototype for rl_completion_matches() and my readline seems to compile and work well enough). Would a #else statement that defines completion_matches() fit in there? Problem would be the return type for flex_complete() might need to be covered as well unless a clever macro can be created that returns a char **. Initially assigned to Michael since he seems to always deal with the readline stuff. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-04 21:04 Message: Logged In: YES user_id=357491 Closing as won't fix since turned out mostly to be a setup issue on my box of not having Configure know where the header file was. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-15 22:57 Message: Logged In: YES user_id=357491 OK, that seemed to solve it. I will fire off a quick email to python-dev to see if anyone feels we should try to deal with this or add a mention in the README. Reassigning to myself. Thanks, Michael, for the help. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-14 03:59 Message: Logged In: YES user_id=6656 Hmm. Does running LDFLAGS=-L/sw/lib ./configure acheive anything interesting? Speaking for myself, I'd prefer it if python's build process ignored /sw/ entirely by default... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-12 12:31 Message: Logged In: YES user_id=357491 Sounds like the right solution. But unfortunately I don't know how to implement the fix either. Ask on python-dev? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-12 11:56 Message: Logged In: YES user_id=6656 So I'm guessing that the answer to this is to teach the configure test to look in /sw/lib, then. Not sure how to do that... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-12 11:46 Message: Logged In: YES user_id=357491 > Oh, er, "good". If I was wrong to assign it to you feel free to unassign it. I don't know when it was introduced; it might be old. I just decided to go through my make output and look for any warnings before a1 when out the door. I tend to compile with ``--without-toolbox-glue`` and that leads to a ton of output from modules wanting Carbon stuff and throwing a fit that they can't link so it just didn't catch my eye. As for RL_COMPLETION_MATCHES, pyconfig.h has it commented out and config.log has test code fail at compilation because it can't find code for -lreadline:: configure:17625: checking for rl_completion_matches in -lreadline configure:17656: gcc -o conftest -g -O2 conftest.c -lreadline -ltermcap -ldl > &5 ld: can't locate file for: -lreadline so I end up with:: ``ac_cv_lib_readline_rl_completion_matches=no``. in config.log . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-12 05:23 Message: Logged In: YES user_id=6656 > Initially assigned to Michael since he seems to always > deal with the readline stuff. Oh, er, "good". I'm a little confused. Is this a new thing? As in, introduced by my changes just before 2.4a1? *Why* is HAVE_RL_COMPLETION_MATCHES undefined? What do config.log and pyconfig.h have to say on the matter? > Would a #else statement that defines completion_matches() > fit in there? Not unless we can work out why it's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=988300&group_id=5470 From noreply at sourceforge.net Thu Aug 5 13:15:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 13:15:08 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 13:15 Message: Logged In: YES user_id=38388 Thank you. Please also provide suitable aliases (I couldn't find any on the IANA site), then I'll add them to Python 2.4. ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-04 00:58 Message: Logged In: YES user_id=845149 Attached are the output if gencodec.py for ISO-8859-11, ISO-8859-16 and for reference also the original mapping files. Peter ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:34 Message: Logged In: YES user_id=38388 Peter, could you attach the generated codecs to this report ? Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-02 13:14 Message: Logged In: YES user_id=38388 Martin, I think it's a good idea to add the codecs for completeness. We should probably also review the mapping files posted on the unicode.org site every now and then and update the codecs in Python accordingly. Sticking to the Unicode Consortium's view of things is a good way to assure compatibility with other applications, IMO. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Thu Aug 5 13:41:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 13:41:21 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 13:41 Message: Logged In: YES user_id=21627 The unfortunate problem is that ISO-8859-11 is not a IANA-registered character set. For ISO-8859-16, http://www.iana.org/assignments/character-sets lists: Name: ISO-8859-16 MIBenum: 112 Source: ISO Alias: iso-ir-226 Alias: ISO_8859-16:2001 Alias: ISO_8859-16 Alias: latin10 Alias: l10 I believe ISO-8859-11 does not have any aliases. Some people may claim TIS-620 is an alias, but it is not (as it does not contain \xa0). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 13:15 Message: Logged In: YES user_id=38388 Thank you. Please also provide suitable aliases (I couldn't find any on the IANA site), then I'll add them to Python 2.4. ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-04 00:58 Message: Logged In: YES user_id=845149 Attached are the output if gencodec.py for ISO-8859-11, ISO-8859-16 and for reference also the original mapping files. Peter ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:34 Message: Logged In: YES user_id=38388 Peter, could you attach the generated codecs to this report ? Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-02 13:14 Message: Logged In: YES user_id=38388 Martin, I think it's a good idea to add the codecs for completeness. We should probably also review the mapping files posted on the unicode.org site every now and then and update the codecs in Python accordingly. Sticking to the Unicode Consortium's view of things is a good way to assure compatibility with other applications, IMO. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Thu Aug 5 13:59:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 14:02:35 2004 Subject: [ python-Bugs-1002465 ] MemoryError on AIX52 Message-ID: Bugs item #1002465, was opened at 2004-08-03 09:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Datranet (richardjmason) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError on AIX52 Initial Comment: I found the orginal problem when trying to send large email attachments on AIX 5.2. I tracked the issue down to the fact that a string can only grow to a very restricted size on AIX 5.2. bin2ascii fails at the pint the function tries to join the list togther to form 1 string. I wrote the following test program to prove the issue: a = '' cnt = 0 while cnt < 1024: a = a + 'x' cnt += 1 c = '' cnt = 0 while cnt < 1024: c = c + a cnt += 1 b = '' cnt2 = 0 while 1: b = b + c cnt2 += 1 print cnt2 On AIX 5.2 you get a MemoryError with a cnt2 value of 42. I can run the test program on all other platforms and get a cnt2 value over 150 before stopping to program myself. I have tried the binary python 2.2 from the IBM site and building python 2.3.4 myself using the gcc from the IBM site. Both fail with a cnt2 value of 42. Can anyone please advise on how to get AIX 5.2 to allow single objects to have more memory allocated. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-05 12:59 Message: Logged In: YES user_id=6656 A way this has happened in the past is calling "malloc(0)", which is entitled to return NULL and Python then thinks this is a memory error. This doesn't seeme especially likely here, though. Agree with Martin that you're probably going to need to use a debugger. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 19:09 Message: Logged In: YES user_id=21627 You need to use a debugger to find the cause of the problem. What is the string parameter of the MemoryError? This might give a clue where precisely it is raised. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 From noreply at sourceforge.net Thu Aug 5 14:04:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 14:04:10 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-31 01:08 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-05 13:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-04 21:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 20:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 15:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Thu Aug 5 14:06:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 14:07:01 2004 Subject: [ python-Bugs-991125 ] Make Problem on HPUX Message-ID: Bugs item #991125, was opened at 2004-07-14 15:49 Message generated for change (Comment added) made by plusk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Nobody/Anonymous (nobody) Summary: Make Problem on HPUX Initial Comment: Build of _socket fails: In file included from /home/python/Python- 2.4a1/Modules/socketmodule.c:314: /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_gai_strerror': /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: `EAI_MAX' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: (Each undeclared identifier is reported only once /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: for each function it appears in.) /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_getaddrinfo': /home/python/Python-2.4a1/Modules/getaddrinfo.c:282: `EAI_BADHINTS' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:283: `AI_MASK' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:373: `EAI_PROTOCOL' undeclared (first use in this function) The problem seems to be that #include "addrinfo.h" is in an #if 0 block in getaddrinfo.c When that include is moved out of the #if 0 block, the _socket module compiles and make test does not show any errors. System information: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license The above problem occurs with both gcc and with HP's C compiler. ---------------------------------------------------------------------- >Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 08:06 Message: Logged In: YES user_id=1083789 I just checked, and man getaddrinfo shows that HPUX _does_ have getaddrinfo: getaddrinfo(3N) getaddrinfo (3N) NAME getaddrinfo(), getnameinfo(), freeaddrinfo(), gai_strerror () - get hostname and address entry SYNOPSIS #include #include int getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res); int getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags); void freeaddrinfo(struct addrinfo *ai); char *gai_strerror(int encode); So the real problem is that configure didn't find it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 13:36 Message: Logged In: YES user_id=21627 Does that mean HP-UX does not have a native getaddrinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 From noreply at sourceforge.net Thu Aug 5 14:15:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 14:16:05 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 14:15 Message: Logged In: YES user_id=38388 I found these references for iso-8859-11: iso_8859-11:1992 (try searching for this in goole :-) http://mnogosearch.kn.vutbr.cz/Download/snapshot/mnogosearch32/src/uconv-alias.c windows-874 http://www.memecode.com/site/ver.php?id=94 thai windows-874 tis-620 iso-8859-11:2001 http://de.wikipedia.org/wiki/ISO_8859-11 The lsat URL suggests that iso-8859-11 is the same as tis-620, but only the "basis" for windows-874. It also quotes the year 2001 as the last revision of the mapping which corresponds to the header of the Unicode mapping file. I think it's safe to add the alias for tis-620 even though the iso mapping has one more character. According to Google that encoding name is much more popular than the iso one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 13:41 Message: Logged In: YES user_id=21627 The unfortunate problem is that ISO-8859-11 is not a IANA-registered character set. For ISO-8859-16, http://www.iana.org/assignments/character-sets lists: Name: ISO-8859-16 MIBenum: 112 Source: ISO Alias: iso-ir-226 Alias: ISO_8859-16:2001 Alias: ISO_8859-16 Alias: latin10 Alias: l10 I believe ISO-8859-11 does not have any aliases. Some people may claim TIS-620 is an alias, but it is not (as it does not contain \xa0). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 13:15 Message: Logged In: YES user_id=38388 Thank you. Please also provide suitable aliases (I couldn't find any on the IANA site), then I'll add them to Python 2.4. ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-04 00:58 Message: Logged In: YES user_id=845149 Attached are the output if gencodec.py for ISO-8859-11, ISO-8859-16 and for reference also the original mapping files. Peter ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:34 Message: Logged In: YES user_id=38388 Peter, could you attach the generated codecs to this report ? Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-02 13:14 Message: Logged In: YES user_id=38388 Martin, I think it's a good idea to add the codecs for completeness. We should probably also review the mapping files posted on the unicode.org site every now and then and update the codecs in Python accordingly. Sticking to the Unicode Consortium's view of things is a good way to assure compatibility with other applications, IMO. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Thu Aug 5 14:25:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 14:25:42 2004 Subject: [ python-Bugs-991125 ] Make Problem on HPUX Message-ID: Bugs item #991125, was opened at 2004-07-14 15:49 Message generated for change (Comment added) made by plusk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Nobody/Anonymous (nobody) Summary: Make Problem on HPUX Initial Comment: Build of _socket fails: In file included from /home/python/Python- 2.4a1/Modules/socketmodule.c:314: /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_gai_strerror': /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: `EAI_MAX' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: (Each undeclared identifier is reported only once /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: for each function it appears in.) /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_getaddrinfo': /home/python/Python-2.4a1/Modules/getaddrinfo.c:282: `EAI_BADHINTS' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:283: `AI_MASK' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:373: `EAI_PROTOCOL' undeclared (first use in this function) The problem seems to be that #include "addrinfo.h" is in an #if 0 block in getaddrinfo.c When that include is moved out of the #if 0 block, the _socket module compiles and make test does not show any errors. System information: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license The above problem occurs with both gcc and with HP's C compiler. ---------------------------------------------------------------------- >Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 08:25 Message: Logged In: YES user_id=1083789 But configure thinks it's buggy: configure:14229: checking getaddrinfo bug configure:14332: gcc -o conftest -g -O2 conftest.c -lcl - lnsl -lrt -ldld -lpthread >&5 configure:14335: $? = 0 configure:14337: ./conftest configure:14340: $? = 1 configure: program exited with status 1 configure: failed program was: | #line 14236 "configure" | /* confdefs.h. */ | | #define _GNU_SOURCE 1 | #define _NETBSD_SOURCE 1 | #define __BSD_VISIBLE 1 | #define _XOPEN_SOURCE 600 | #define _XOPEN_SOURCE_EXTENDED 1 | #define _POSIX_C_SOURCE 200112L | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_GRP_H 1 | #define HAVE_LANGINFO_H 1 | #define HAVE_POLL_H 1 | #define HAVE_PTHREAD_H 1 | #define HAVE_STROPTS_H 1 | #define HAVE_TERMIOS_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_UTIME_H 1 | #define HAVE_SYS_BSDTTY_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_LOCK_H 1 | #define HAVE_SYS_MODEM_H 1 | #define HAVE_SYS_PARAM_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TIMES_H 1 | #define HAVE_SYS_UN_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_TERM_H 1 | #define HAVE_SYS_RESOURCE_H 1 | #define HAVE_SYSEXITS_H 1 | #define HAVE_DIRENT_H 1 | #define MAJOR_IN_SYSMACROS 1 | #define _LARGEFILE_SOURCE 1 | #define _FILE_OFFSET_BITS 64 | #if defined(SCO_DS) | #undef _OFF_T | #endif | #define RETSIGTYPE void | #define SIZEOF_INT 4 | #define SIZEOF_LONG 4 | #define SIZEOF_VOID_P 4 | #define SIZEOF_SHORT 2 | #define SIZEOF_FLOAT 4 | #define SIZEOF_DOUBLE 8 | #define SIZEOF_FPOS_T 8 | #define HAVE_LONG_LONG 1 | #define SIZEOF_LONG_LONG 8 | #define SIZEOF_OFF_T 8 | #define HAVE_LARGEFILE_SUPPORT 1 | #define SIZEOF_TIME_T 4 | #define SIZEOF_PTHREAD_T 4 | #define HAVE_LIBDLD 1 | #define _REENTRANT 1 | #define WITH_THREAD 1 | #define _POSIX_THREADS 1 | #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 | #define HAVE_PTHREAD_SIGMASK 1 | #define WITH_DOC_STRINGS 1 | #define WITH_PYMALLOC 1 | #define HAVE_DLOPEN 1 | #define HAVE_DYNAMIC_LOADING 1 | #define HAVE_ALARM 1 | #define HAVE_CHOWN 1 | #define HAVE_CLOCK 1 | #define HAVE_CONFSTR 1 | #define HAVE_CTERMID 1 | #define HAVE_EXECV 1 | #define HAVE_FORK 1 | #define HAVE_FPATHCONF 1 | #define HAVE_FTIME 1 | #define HAVE_FTRUNCATE 1 | #define HAVE_GAI_STRERROR 1 | #define HAVE_GETGROUPS 1 | #define HAVE_GETLOGIN 1 | #define HAVE_GETPEERNAME 1 | #define HAVE_GETPGID 1 | #define HAVE_GETPID 1 | #define HAVE_GETPRIORITY 1 | #define HAVE_GETPWENT 1 | #define HAVE_GETSID 1 | #define HAVE_GETWD 1 | #define HAVE_KILL 1 | #define HAVE_KILLPG 1 | #define HAVE_LCHOWN 1 | #define HAVE_LSTAT 1 | #define HAVE_MKFIFO 1 | #define HAVE_MKNOD 1 | #define HAVE_MKTIME 1 | #define HAVE_NICE 1 | #define HAVE_PATHCONF 1 | #define HAVE_PAUSE 1 | #define HAVE_PLOCK 1 | #define HAVE_POLL 1 | #define HAVE_PUTENV 1 | #define HAVE_READLINK 1 | #define HAVE_REALPATH 1 | #define HAVE_SELECT 1 | #define HAVE_SETGID 1 | #define HAVE_SETLOCALE 1 | #define HAVE_SETREGID 1 | #define HAVE_SETREUID 1 | #define HAVE_SETSID 1 | #define HAVE_SETPGID 1 | #define HAVE_SETPGRP 1 | #define HAVE_SETUID 1 | #define HAVE_SETVBUF 1 | #define HAVE_SNPRINTF 1 | #define HAVE_SIGACTION 1 | #define HAVE_SIGINTERRUPT 1 | #define HAVE_SIGRELSE 1 | #define HAVE_STRFTIME 1 | #define HAVE_SYSCONF 1 | #define HAVE_TCGETPGRP 1 | #define HAVE_TCSETPGRP 1 | #define HAVE_TEMPNAM 1 | #define HAVE_TIMES 1 | #define HAVE_TMPFILE 1 | #define HAVE_TMPNAM 1 | #define HAVE_TRUNCATE 1 | #define HAVE_UNAME 1 | #define HAVE_UTIMES 1 | #define HAVE_WAITPID 1 | #define HAVE_WCSCOLL 1 | #define HAVE_CHROOT 1 | #define HAVE_LINK 1 | #define HAVE_SYMLINK 1 | #define HAVE_FCHDIR 1 | #define HAVE_FSYNC 1 | #define HAVE_FDATASYNC 1 | #define HAVE_GETPAGESIZE 1 | #define HAVE_INET_ATON 1 | #define HAVE_INET_PTON 1 | #define HAVE_SETGROUPS 1 | #define HAVE_FSEEKO 1 | #define HAVE_FSTATVFS 1 | #define HAVE_FTELLO 1 | #define HAVE_STATVFS 1 | #define HAVE_DUP2 1 | #define HAVE_GETCWD 1 | #define HAVE_STRDUP 1 | #define HAVE_STRERROR 1 | #define HAVE_MEMMOVE 1 | #define HAVE_GETPGRP 1 | #define HAVE_SETPGRP 1 | #define HAVE_GETTIMEOFDAY 1 | /* end confdefs.h. */ | | #include | #include | #include | #include | #include | | main() | { | int passive, gaierr, inet4 = 0, inet6 = 0; | struct addrinfo hints, *ai, *aitop; | char straddr[INET6_ADDRSTRLEN], strport[16]; | | for (passive = 0; passive <= 1; passive++) { | memset(&hints, 0, sizeof(hints)); | hints.ai_family = AF_UNSPEC; | hints.ai_flags = passive ? AI_PASSIVE : 0; | hints.ai_socktype = SOCK_STREAM; | hints.ai_protocol = IPPROTO_TCP; | if ((gaierr = getaddrinfo(NULL, "54321", &hints, &aitop)) ! = 0) { | (void)gai_strerror(gaierr); | goto bad; | } | for (ai = aitop; ai; ai = ai->ai_next) { | if (ai->ai_addr == NULL || | ai->ai_addrlen == 0 || | getnameinfo(ai->ai_addr, ai->ai_addrlen, | straddr, sizeof(straddr), strport, sizeof (strport), | NI_NUMERICHOST|NI_NUMERICSERV) != 0) { | goto bad; | } | switch (ai->ai_family) { | case AF_INET: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "0.0.0.0") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "127.0.0.1") != 0) { | goto bad; | } | } | inet4++; | break; | case AF_INET6: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "::") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "::1") != 0) { | goto bad; | } | } | inet6++; | break; | case AF_UNSPEC: | goto bad; | break; | default: | /* another family support? */ | break; | } | } | } | | if (!(inet4 == 0 || inet4 == 2)) | goto bad; | if (!(inet6 == 0 || inet6 == 2)) | goto bad; | | if (aitop) | freeaddrinfo(aitop); | exit(0); | | bad: | if (aitop) | freeaddrinfo(aitop); | exit(1); | } | configure:14351: result: buggy ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 08:06 Message: Logged In: YES user_id=1083789 I just checked, and man getaddrinfo shows that HPUX _does_ have getaddrinfo: getaddrinfo(3N) getaddrinfo (3N) NAME getaddrinfo(), getnameinfo(), freeaddrinfo(), gai_strerror () - get hostname and address entry SYNOPSIS #include #include int getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res); int getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags); void freeaddrinfo(struct addrinfo *ai); char *gai_strerror(int encode); So the real problem is that configure didn't find it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 13:36 Message: Logged In: YES user_id=21627 Does that mean HP-UX does not have a native getaddrinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 From noreply at sourceforge.net Thu Aug 5 15:16:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 15:16:53 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Thu Aug 5 15:49:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 15:49:11 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 08:16 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 08:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Thu Aug 5 14:33:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 16:03:27 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 14:33 Message: Logged In: YES user_id=38388 Nevermind. I'll also add a proper tis_620.py codec. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 14:15 Message: Logged In: YES user_id=38388 I found these references for iso-8859-11: iso_8859-11:1992 (try searching for this in goole :-) http://mnogosearch.kn.vutbr.cz/Download/snapshot/mnogosearch32/src/uconv-alias.c windows-874 http://www.memecode.com/site/ver.php?id=94 thai windows-874 tis-620 iso-8859-11:2001 http://de.wikipedia.org/wiki/ISO_8859-11 The lsat URL suggests that iso-8859-11 is the same as tis-620, but only the "basis" for windows-874. It also quotes the year 2001 as the last revision of the mapping which corresponds to the header of the Unicode mapping file. I think it's safe to add the alias for tis-620 even though the iso mapping has one more character. According to Google that encoding name is much more popular than the iso one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 13:41 Message: Logged In: YES user_id=21627 The unfortunate problem is that ISO-8859-11 is not a IANA-registered character set. For ISO-8859-16, http://www.iana.org/assignments/character-sets lists: Name: ISO-8859-16 MIBenum: 112 Source: ISO Alias: iso-ir-226 Alias: ISO_8859-16:2001 Alias: ISO_8859-16 Alias: latin10 Alias: l10 I believe ISO-8859-11 does not have any aliases. Some people may claim TIS-620 is an alias, but it is not (as it does not contain \xa0). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 13:15 Message: Logged In: YES user_id=38388 Thank you. Please also provide suitable aliases (I couldn't find any on the IANA site), then I'll add them to Python 2.4. ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-04 00:58 Message: Logged In: YES user_id=845149 Attached are the output if gencodec.py for ISO-8859-11, ISO-8859-16 and for reference also the original mapping files. Peter ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:34 Message: Logged In: YES user_id=38388 Peter, could you attach the generated codecs to this report ? Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-02 13:14 Message: Logged In: YES user_id=38388 Martin, I think it's a good idea to add the codecs for completeness. We should probably also review the mapping files posted on the unicode.org site every now and then and update the codecs in Python accordingly. Sticking to the Unicode Consortium's view of things is a good way to assure compatibility with other applications, IMO. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Thu Aug 5 14:44:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 16:03:40 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 >Category: Unicode Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 14:44 Message: Logged In: YES user_id=38388 Checking in Misc/NEWS; /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.1073; previous revision: 1.1072 done Checking in Lib/encodings/aliases.py; /cvsroot/python/python/dist/src/Lib/encodings/aliases.py,v <-- aliases.py new revision: 1.27; previous revision: 1.26 done RCS file: /cvsroot/python/python/dist/src/Lib/encodings/iso8859_11.py,v done Checking in Lib/encodings/iso8859_11.py; /cvsroot/python/python/dist/src/Lib/encodings/iso8859_11.py,v <-- iso8859_11.py initial revision: 1.1 done RCS file: /cvsroot/python/python/dist/src/Lib/encodings/iso8859_16.py,v done Checking in Lib/encodings/iso8859_16.py; /cvsroot/python/python/dist/src/Lib/encodings/iso8859_16.py,v <-- iso8859_16.py initial revision: 1.1 done RCS file: /cvsroot/python/python/dist/src/Lib/encodings/tis_620.py,v done Checking in Lib/encodings/tis_620.py; /cvsroot/python/python/dist/src/Lib/encodings/tis_620.py,v <-- tis_620.py initial revision: 1.1 done ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 14:33 Message: Logged In: YES user_id=38388 Nevermind. I'll also add a proper tis_620.py codec. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 14:15 Message: Logged In: YES user_id=38388 I found these references for iso-8859-11: iso_8859-11:1992 (try searching for this in goole :-) http://mnogosearch.kn.vutbr.cz/Download/snapshot/mnogosearch32/src/uconv-alias.c windows-874 http://www.memecode.com/site/ver.php?id=94 thai windows-874 tis-620 iso-8859-11:2001 http://de.wikipedia.org/wiki/ISO_8859-11 The lsat URL suggests that iso-8859-11 is the same as tis-620, but only the "basis" for windows-874. It also quotes the year 2001 as the last revision of the mapping which corresponds to the header of the Unicode mapping file. I think it's safe to add the alias for tis-620 even though the iso mapping has one more character. According to Google that encoding name is much more popular than the iso one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 13:41 Message: Logged In: YES user_id=21627 The unfortunate problem is that ISO-8859-11 is not a IANA-registered character set. For ISO-8859-16, http://www.iana.org/assignments/character-sets lists: Name: ISO-8859-16 MIBenum: 112 Source: ISO Alias: iso-ir-226 Alias: ISO_8859-16:2001 Alias: ISO_8859-16 Alias: latin10 Alias: l10 I believe ISO-8859-11 does not have any aliases. Some people may claim TIS-620 is an alias, but it is not (as it does not contain \xa0). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 13:15 Message: Logged In: YES user_id=38388 Thank you. Please also provide suitable aliases (I couldn't find any on the IANA site), then I'll add them to Python 2.4. ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-04 00:58 Message: Logged In: YES user_id=845149 Attached are the output if gencodec.py for ISO-8859-11, ISO-8859-16 and for reference also the original mapping files. Peter ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:34 Message: Logged In: YES user_id=38388 Peter, could you attach the generated codecs to this report ? Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-02 13:14 Message: Logged In: YES user_id=38388 Martin, I think it's a good idea to add the codecs for completeness. We should probably also review the mapping files posted on the unicode.org site every now and then and update the codecs in Python accordingly. Sticking to the Unicode Consortium's view of things is a good way to assure compatibility with other applications, IMO. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Thu Aug 5 15:02:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 16:03:42 2004 Subject: [ python-Feature Requests-1001895 ] Adding missing ISO 8859 codecs, especially Thai Message-ID: Feature Requests item #1001895, was opened at 2004-08-02 11:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 >Category: None Group: None >Status: Open >Resolution: None Priority: 5 Submitted By: Peter Jacobi (peter_jacobi) Assigned to: M.-A. Lemburg (lemburg) Summary: Adding missing ISO 8859 codecs, especially Thai Initial Comment: As the missing ISO 8859 codecs, (11:Thai, 16:Romanian) can be automatically generated from the Unicode mapping files (via gencodec.py), I'd like to ask for inclusion in the next version. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 15:02 Message: Logged In: YES user_id=21627 Code page 874 differs from the 8859 one in the definition of \x80..\x9f. http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/PC/CP874.TXT says 0x80 0x20AC #EURO SIGN 0x85 0x2026 #HORIZONTAL ELLIPSIS 0x91 0x2018 #LEFT SINGLE QUOTATION MARK 0x92 0x2019 #RIGHT SINGLE QUOTATION MARK 0x93 0x201C #LEFT DOUBLE QUOTATION MARK 0x94 0x201D #RIGHT DOUBLE QUOTATION MARK 0x95 0x2022 #BULLET 0x96 0x2013 #EN DASH 0x97 0x2014 #EM DASH I assume the Thai version of Windows is likely to generate "windows-874". Debian offers the th_TH locale, with TIS-620, and a th_TH.UTF-8 locale (i.e. no ISO-8859-1 one). If ISO 8859-11 is understood as published by ISO (i.e. no control characters at all), then CP 874 is a strict extension (adding C0, plus the characters above). Google gives these frequencies: tis-620 16,200 windows-874 7,290 iso-8859-11 5,880 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 14:44 Message: Logged In: YES user_id=38388 Checking in Misc/NEWS; /cvsroot/python/python/dist/src/Misc/NEWS,v <-- NEWS new revision: 1.1073; previous revision: 1.1072 done Checking in Lib/encodings/aliases.py; /cvsroot/python/python/dist/src/Lib/encodings/aliases.py,v <-- aliases.py new revision: 1.27; previous revision: 1.26 done RCS file: /cvsroot/python/python/dist/src/Lib/encodings/iso8859_11.py,v done Checking in Lib/encodings/iso8859_11.py; /cvsroot/python/python/dist/src/Lib/encodings/iso8859_11.py,v <-- iso8859_11.py initial revision: 1.1 done RCS file: /cvsroot/python/python/dist/src/Lib/encodings/iso8859_16.py,v done Checking in Lib/encodings/iso8859_16.py; /cvsroot/python/python/dist/src/Lib/encodings/iso8859_16.py,v <-- iso8859_16.py initial revision: 1.1 done RCS file: /cvsroot/python/python/dist/src/Lib/encodings/tis_620.py,v done Checking in Lib/encodings/tis_620.py; /cvsroot/python/python/dist/src/Lib/encodings/tis_620.py,v <-- tis_620.py initial revision: 1.1 done ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 14:33 Message: Logged In: YES user_id=38388 Nevermind. I'll also add a proper tis_620.py codec. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 14:15 Message: Logged In: YES user_id=38388 I found these references for iso-8859-11: iso_8859-11:1992 (try searching for this in goole :-) http://mnogosearch.kn.vutbr.cz/Download/snapshot/mnogosearch32/src/uconv-alias.c windows-874 http://www.memecode.com/site/ver.php?id=94 thai windows-874 tis-620 iso-8859-11:2001 http://de.wikipedia.org/wiki/ISO_8859-11 The lsat URL suggests that iso-8859-11 is the same as tis-620, but only the "basis" for windows-874. It also quotes the year 2001 as the last revision of the mapping which corresponds to the header of the Unicode mapping file. I think it's safe to add the alias for tis-620 even though the iso mapping has one more character. According to Google that encoding name is much more popular than the iso one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 13:41 Message: Logged In: YES user_id=21627 The unfortunate problem is that ISO-8859-11 is not a IANA-registered character set. For ISO-8859-16, http://www.iana.org/assignments/character-sets lists: Name: ISO-8859-16 MIBenum: 112 Source: ISO Alias: iso-ir-226 Alias: ISO_8859-16:2001 Alias: ISO_8859-16 Alias: latin10 Alias: l10 I believe ISO-8859-11 does not have any aliases. Some people may claim TIS-620 is an alias, but it is not (as it does not contain \xa0). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 13:15 Message: Logged In: YES user_id=38388 Thank you. Please also provide suitable aliases (I couldn't find any on the IANA site), then I'll add them to Python 2.4. ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-04 00:58 Message: Logged In: YES user_id=845149 Attached are the output if gencodec.py for ISO-8859-11, ISO-8859-16 and for reference also the original mapping files. Peter ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-03 16:34 Message: Logged In: YES user_id=38388 Peter, could you attach the generated codecs to this report ? Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-02 13:14 Message: Logged In: YES user_id=38388 Martin, I think it's a good idea to add the codecs for completeness. We should probably also review the mapping files posted on the unicode.org site every now and then and update the codecs in Python accordingly. Sticking to the Unicode Consortium's view of things is a good way to assure compatibility with other applications, IMO. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-02 12:30 Message: Logged In: YES user_id=21627 Marc-Andre, should we add these? ---------------------------------------------------------------------- Comment By: Peter Jacobi (peter_jacobi) Date: 2004-08-02 12:16 Message: Logged In: YES user_id=845149 In a thread on news://comp.lang.python I was asked by Martin v. L?wis to provide evidence on the correctness of the ISO 8859-11 Unicode mapping file, as found on ftp://ftp.unicode.org/Public/MAPPINGS/ISO8859/8859-11.TXT (due to the disclaimer boilerplate in these files). So far I can provide these three points: a) ISO 8859-n vs ISO-8859-n If the information at http://en.wikipedia.org/wiki/ISO_8859- 1#ISO_8859-1_vs_ISO-8859-1 is correct, Python 8859-n codecs do implement the ISO standard charsets ISO 8859-n in the specialized IANA forms ISO-8859-n (and in agreement with the Unicode mapping files). So any difficult C0/C1 wording in the original ISO standard can be disregarded. b) libiconv ISO 8859-11 The implementation by Bruno Haible in libiconv does agree with the Unicode mapping file: http://cvs.sourceforge.net/viewcvs.py/libiconv/libiconv/lib/ c) IBM ICU4C The implementation in ICU4C does agree with the Unicode mapping file: http://oss.software.ibm.com/cvs/icu/charset/data/ucm/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1001895&group_id=5470 From noreply at sourceforge.net Thu Aug 5 15:13:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 16:03:45 2004 Subject: [ python-Bugs-991125 ] Make Problem on HPUX Message-ID: Bugs item #991125, was opened at 2004-07-14 21:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Nobody/Anonymous (nobody) Summary: Make Problem on HPUX Initial Comment: Build of _socket fails: In file included from /home/python/Python- 2.4a1/Modules/socketmodule.c:314: /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_gai_strerror': /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: `EAI_MAX' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: (Each undeclared identifier is reported only once /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: for each function it appears in.) /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_getaddrinfo': /home/python/Python-2.4a1/Modules/getaddrinfo.c:282: `EAI_BADHINTS' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:283: `AI_MASK' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:373: `EAI_PROTOCOL' undeclared (first use in this function) The problem seems to be that #include "addrinfo.h" is in an #if 0 block in getaddrinfo.c When that include is moved out of the #if 0 block, the _socket module compiles and make test does not show any errors. System information: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license The above problem occurs with both gcc and with HP's C compiler. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 15:13 Message: Logged In: YES user_id=21627 plusk, can you find out which of the "goto bad" statements was taken, by running the program separately, and adding printf calls? Historically, Python had to make these tests, because many platforms indeed *have* a broken getaddrinfo. sjoerd, in what way does exactly what fix the compilation problem on Cygwin? ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-05 14:59 Message: Logged In: YES user_id=43607 This also fixes the compilation problem on Cygwin. See bug 1001857. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 14:25 Message: Logged In: YES user_id=1083789 But configure thinks it's buggy: configure:14229: checking getaddrinfo bug configure:14332: gcc -o conftest -g -O2 conftest.c -lcl - lnsl -lrt -ldld -lpthread >&5 configure:14335: $? = 0 configure:14337: ./conftest configure:14340: $? = 1 configure: program exited with status 1 configure: failed program was: | #line 14236 "configure" | /* confdefs.h. */ | | #define _GNU_SOURCE 1 | #define _NETBSD_SOURCE 1 | #define __BSD_VISIBLE 1 | #define _XOPEN_SOURCE 600 | #define _XOPEN_SOURCE_EXTENDED 1 | #define _POSIX_C_SOURCE 200112L | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_GRP_H 1 | #define HAVE_LANGINFO_H 1 | #define HAVE_POLL_H 1 | #define HAVE_PTHREAD_H 1 | #define HAVE_STROPTS_H 1 | #define HAVE_TERMIOS_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_UTIME_H 1 | #define HAVE_SYS_BSDTTY_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_LOCK_H 1 | #define HAVE_SYS_MODEM_H 1 | #define HAVE_SYS_PARAM_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TIMES_H 1 | #define HAVE_SYS_UN_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_TERM_H 1 | #define HAVE_SYS_RESOURCE_H 1 | #define HAVE_SYSEXITS_H 1 | #define HAVE_DIRENT_H 1 | #define MAJOR_IN_SYSMACROS 1 | #define _LARGEFILE_SOURCE 1 | #define _FILE_OFFSET_BITS 64 | #if defined(SCO_DS) | #undef _OFF_T | #endif | #define RETSIGTYPE void | #define SIZEOF_INT 4 | #define SIZEOF_LONG 4 | #define SIZEOF_VOID_P 4 | #define SIZEOF_SHORT 2 | #define SIZEOF_FLOAT 4 | #define SIZEOF_DOUBLE 8 | #define SIZEOF_FPOS_T 8 | #define HAVE_LONG_LONG 1 | #define SIZEOF_LONG_LONG 8 | #define SIZEOF_OFF_T 8 | #define HAVE_LARGEFILE_SUPPORT 1 | #define SIZEOF_TIME_T 4 | #define SIZEOF_PTHREAD_T 4 | #define HAVE_LIBDLD 1 | #define _REENTRANT 1 | #define WITH_THREAD 1 | #define _POSIX_THREADS 1 | #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 | #define HAVE_PTHREAD_SIGMASK 1 | #define WITH_DOC_STRINGS 1 | #define WITH_PYMALLOC 1 | #define HAVE_DLOPEN 1 | #define HAVE_DYNAMIC_LOADING 1 | #define HAVE_ALARM 1 | #define HAVE_CHOWN 1 | #define HAVE_CLOCK 1 | #define HAVE_CONFSTR 1 | #define HAVE_CTERMID 1 | #define HAVE_EXECV 1 | #define HAVE_FORK 1 | #define HAVE_FPATHCONF 1 | #define HAVE_FTIME 1 | #define HAVE_FTRUNCATE 1 | #define HAVE_GAI_STRERROR 1 | #define HAVE_GETGROUPS 1 | #define HAVE_GETLOGIN 1 | #define HAVE_GETPEERNAME 1 | #define HAVE_GETPGID 1 | #define HAVE_GETPID 1 | #define HAVE_GETPRIORITY 1 | #define HAVE_GETPWENT 1 | #define HAVE_GETSID 1 | #define HAVE_GETWD 1 | #define HAVE_KILL 1 | #define HAVE_KILLPG 1 | #define HAVE_LCHOWN 1 | #define HAVE_LSTAT 1 | #define HAVE_MKFIFO 1 | #define HAVE_MKNOD 1 | #define HAVE_MKTIME 1 | #define HAVE_NICE 1 | #define HAVE_PATHCONF 1 | #define HAVE_PAUSE 1 | #define HAVE_PLOCK 1 | #define HAVE_POLL 1 | #define HAVE_PUTENV 1 | #define HAVE_READLINK 1 | #define HAVE_REALPATH 1 | #define HAVE_SELECT 1 | #define HAVE_SETGID 1 | #define HAVE_SETLOCALE 1 | #define HAVE_SETREGID 1 | #define HAVE_SETREUID 1 | #define HAVE_SETSID 1 | #define HAVE_SETPGID 1 | #define HAVE_SETPGRP 1 | #define HAVE_SETUID 1 | #define HAVE_SETVBUF 1 | #define HAVE_SNPRINTF 1 | #define HAVE_SIGACTION 1 | #define HAVE_SIGINTERRUPT 1 | #define HAVE_SIGRELSE 1 | #define HAVE_STRFTIME 1 | #define HAVE_SYSCONF 1 | #define HAVE_TCGETPGRP 1 | #define HAVE_TCSETPGRP 1 | #define HAVE_TEMPNAM 1 | #define HAVE_TIMES 1 | #define HAVE_TMPFILE 1 | #define HAVE_TMPNAM 1 | #define HAVE_TRUNCATE 1 | #define HAVE_UNAME 1 | #define HAVE_UTIMES 1 | #define HAVE_WAITPID 1 | #define HAVE_WCSCOLL 1 | #define HAVE_CHROOT 1 | #define HAVE_LINK 1 | #define HAVE_SYMLINK 1 | #define HAVE_FCHDIR 1 | #define HAVE_FSYNC 1 | #define HAVE_FDATASYNC 1 | #define HAVE_GETPAGESIZE 1 | #define HAVE_INET_ATON 1 | #define HAVE_INET_PTON 1 | #define HAVE_SETGROUPS 1 | #define HAVE_FSEEKO 1 | #define HAVE_FSTATVFS 1 | #define HAVE_FTELLO 1 | #define HAVE_STATVFS 1 | #define HAVE_DUP2 1 | #define HAVE_GETCWD 1 | #define HAVE_STRDUP 1 | #define HAVE_STRERROR 1 | #define HAVE_MEMMOVE 1 | #define HAVE_GETPGRP 1 | #define HAVE_SETPGRP 1 | #define HAVE_GETTIMEOFDAY 1 | /* end confdefs.h. */ | | #include | #include | #include | #include | #include | | main() | { | int passive, gaierr, inet4 = 0, inet6 = 0; | struct addrinfo hints, *ai, *aitop; | char straddr[INET6_ADDRSTRLEN], strport[16]; | | for (passive = 0; passive <= 1; passive++) { | memset(&hints, 0, sizeof(hints)); | hints.ai_family = AF_UNSPEC; | hints.ai_flags = passive ? AI_PASSIVE : 0; | hints.ai_socktype = SOCK_STREAM; | hints.ai_protocol = IPPROTO_TCP; | if ((gaierr = getaddrinfo(NULL, "54321", &hints, &aitop)) ! = 0) { | (void)gai_strerror(gaierr); | goto bad; | } | for (ai = aitop; ai; ai = ai->ai_next) { | if (ai->ai_addr == NULL || | ai->ai_addrlen == 0 || | getnameinfo(ai->ai_addr, ai->ai_addrlen, | straddr, sizeof(straddr), strport, sizeof (strport), | NI_NUMERICHOST|NI_NUMERICSERV) != 0) { | goto bad; | } | switch (ai->ai_family) { | case AF_INET: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "0.0.0.0") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "127.0.0.1") != 0) { | goto bad; | } | } | inet4++; | break; | case AF_INET6: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "::") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "::1") != 0) { | goto bad; | } | } | inet6++; | break; | case AF_UNSPEC: | goto bad; | break; | default: | /* another family support? */ | break; | } | } | } | | if (!(inet4 == 0 || inet4 == 2)) | goto bad; | if (!(inet6 == 0 || inet6 == 2)) | goto bad; | | if (aitop) | freeaddrinfo(aitop); | exit(0); | | bad: | if (aitop) | freeaddrinfo(aitop); | exit(1); | } | configure:14351: result: buggy ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 14:06 Message: Logged In: YES user_id=1083789 I just checked, and man getaddrinfo shows that HPUX _does_ have getaddrinfo: getaddrinfo(3N) getaddrinfo (3N) NAME getaddrinfo(), getnameinfo(), freeaddrinfo(), gai_strerror () - get hostname and address entry SYNOPSIS #include #include int getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res); int getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags); void freeaddrinfo(struct addrinfo *ai); char *gai_strerror(int encode); So the real problem is that configure didn't find it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 19:36 Message: Logged In: YES user_id=21627 Does that mean HP-UX does not have a native getaddrinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 From noreply at sourceforge.net Thu Aug 5 14:59:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 16:03:51 2004 Subject: [ python-Bugs-991125 ] Make Problem on HPUX Message-ID: Bugs item #991125, was opened at 2004-07-14 21:49 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Nobody/Anonymous (nobody) Summary: Make Problem on HPUX Initial Comment: Build of _socket fails: In file included from /home/python/Python- 2.4a1/Modules/socketmodule.c:314: /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_gai_strerror': /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: `EAI_MAX' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: (Each undeclared identifier is reported only once /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: for each function it appears in.) /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_getaddrinfo': /home/python/Python-2.4a1/Modules/getaddrinfo.c:282: `EAI_BADHINTS' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:283: `AI_MASK' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:373: `EAI_PROTOCOL' undeclared (first use in this function) The problem seems to be that #include "addrinfo.h" is in an #if 0 block in getaddrinfo.c When that include is moved out of the #if 0 block, the _socket module compiles and make test does not show any errors. System information: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license The above problem occurs with both gcc and with HP's C compiler. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-05 14:59 Message: Logged In: YES user_id=43607 This also fixes the compilation problem on Cygwin. See bug 1001857. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 14:25 Message: Logged In: YES user_id=1083789 But configure thinks it's buggy: configure:14229: checking getaddrinfo bug configure:14332: gcc -o conftest -g -O2 conftest.c -lcl - lnsl -lrt -ldld -lpthread >&5 configure:14335: $? = 0 configure:14337: ./conftest configure:14340: $? = 1 configure: program exited with status 1 configure: failed program was: | #line 14236 "configure" | /* confdefs.h. */ | | #define _GNU_SOURCE 1 | #define _NETBSD_SOURCE 1 | #define __BSD_VISIBLE 1 | #define _XOPEN_SOURCE 600 | #define _XOPEN_SOURCE_EXTENDED 1 | #define _POSIX_C_SOURCE 200112L | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_GRP_H 1 | #define HAVE_LANGINFO_H 1 | #define HAVE_POLL_H 1 | #define HAVE_PTHREAD_H 1 | #define HAVE_STROPTS_H 1 | #define HAVE_TERMIOS_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_UTIME_H 1 | #define HAVE_SYS_BSDTTY_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_LOCK_H 1 | #define HAVE_SYS_MODEM_H 1 | #define HAVE_SYS_PARAM_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TIMES_H 1 | #define HAVE_SYS_UN_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_TERM_H 1 | #define HAVE_SYS_RESOURCE_H 1 | #define HAVE_SYSEXITS_H 1 | #define HAVE_DIRENT_H 1 | #define MAJOR_IN_SYSMACROS 1 | #define _LARGEFILE_SOURCE 1 | #define _FILE_OFFSET_BITS 64 | #if defined(SCO_DS) | #undef _OFF_T | #endif | #define RETSIGTYPE void | #define SIZEOF_INT 4 | #define SIZEOF_LONG 4 | #define SIZEOF_VOID_P 4 | #define SIZEOF_SHORT 2 | #define SIZEOF_FLOAT 4 | #define SIZEOF_DOUBLE 8 | #define SIZEOF_FPOS_T 8 | #define HAVE_LONG_LONG 1 | #define SIZEOF_LONG_LONG 8 | #define SIZEOF_OFF_T 8 | #define HAVE_LARGEFILE_SUPPORT 1 | #define SIZEOF_TIME_T 4 | #define SIZEOF_PTHREAD_T 4 | #define HAVE_LIBDLD 1 | #define _REENTRANT 1 | #define WITH_THREAD 1 | #define _POSIX_THREADS 1 | #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 | #define HAVE_PTHREAD_SIGMASK 1 | #define WITH_DOC_STRINGS 1 | #define WITH_PYMALLOC 1 | #define HAVE_DLOPEN 1 | #define HAVE_DYNAMIC_LOADING 1 | #define HAVE_ALARM 1 | #define HAVE_CHOWN 1 | #define HAVE_CLOCK 1 | #define HAVE_CONFSTR 1 | #define HAVE_CTERMID 1 | #define HAVE_EXECV 1 | #define HAVE_FORK 1 | #define HAVE_FPATHCONF 1 | #define HAVE_FTIME 1 | #define HAVE_FTRUNCATE 1 | #define HAVE_GAI_STRERROR 1 | #define HAVE_GETGROUPS 1 | #define HAVE_GETLOGIN 1 | #define HAVE_GETPEERNAME 1 | #define HAVE_GETPGID 1 | #define HAVE_GETPID 1 | #define HAVE_GETPRIORITY 1 | #define HAVE_GETPWENT 1 | #define HAVE_GETSID 1 | #define HAVE_GETWD 1 | #define HAVE_KILL 1 | #define HAVE_KILLPG 1 | #define HAVE_LCHOWN 1 | #define HAVE_LSTAT 1 | #define HAVE_MKFIFO 1 | #define HAVE_MKNOD 1 | #define HAVE_MKTIME 1 | #define HAVE_NICE 1 | #define HAVE_PATHCONF 1 | #define HAVE_PAUSE 1 | #define HAVE_PLOCK 1 | #define HAVE_POLL 1 | #define HAVE_PUTENV 1 | #define HAVE_READLINK 1 | #define HAVE_REALPATH 1 | #define HAVE_SELECT 1 | #define HAVE_SETGID 1 | #define HAVE_SETLOCALE 1 | #define HAVE_SETREGID 1 | #define HAVE_SETREUID 1 | #define HAVE_SETSID 1 | #define HAVE_SETPGID 1 | #define HAVE_SETPGRP 1 | #define HAVE_SETUID 1 | #define HAVE_SETVBUF 1 | #define HAVE_SNPRINTF 1 | #define HAVE_SIGACTION 1 | #define HAVE_SIGINTERRUPT 1 | #define HAVE_SIGRELSE 1 | #define HAVE_STRFTIME 1 | #define HAVE_SYSCONF 1 | #define HAVE_TCGETPGRP 1 | #define HAVE_TCSETPGRP 1 | #define HAVE_TEMPNAM 1 | #define HAVE_TIMES 1 | #define HAVE_TMPFILE 1 | #define HAVE_TMPNAM 1 | #define HAVE_TRUNCATE 1 | #define HAVE_UNAME 1 | #define HAVE_UTIMES 1 | #define HAVE_WAITPID 1 | #define HAVE_WCSCOLL 1 | #define HAVE_CHROOT 1 | #define HAVE_LINK 1 | #define HAVE_SYMLINK 1 | #define HAVE_FCHDIR 1 | #define HAVE_FSYNC 1 | #define HAVE_FDATASYNC 1 | #define HAVE_GETPAGESIZE 1 | #define HAVE_INET_ATON 1 | #define HAVE_INET_PTON 1 | #define HAVE_SETGROUPS 1 | #define HAVE_FSEEKO 1 | #define HAVE_FSTATVFS 1 | #define HAVE_FTELLO 1 | #define HAVE_STATVFS 1 | #define HAVE_DUP2 1 | #define HAVE_GETCWD 1 | #define HAVE_STRDUP 1 | #define HAVE_STRERROR 1 | #define HAVE_MEMMOVE 1 | #define HAVE_GETPGRP 1 | #define HAVE_SETPGRP 1 | #define HAVE_GETTIMEOFDAY 1 | /* end confdefs.h. */ | | #include | #include | #include | #include | #include | | main() | { | int passive, gaierr, inet4 = 0, inet6 = 0; | struct addrinfo hints, *ai, *aitop; | char straddr[INET6_ADDRSTRLEN], strport[16]; | | for (passive = 0; passive <= 1; passive++) { | memset(&hints, 0, sizeof(hints)); | hints.ai_family = AF_UNSPEC; | hints.ai_flags = passive ? AI_PASSIVE : 0; | hints.ai_socktype = SOCK_STREAM; | hints.ai_protocol = IPPROTO_TCP; | if ((gaierr = getaddrinfo(NULL, "54321", &hints, &aitop)) ! = 0) { | (void)gai_strerror(gaierr); | goto bad; | } | for (ai = aitop; ai; ai = ai->ai_next) { | if (ai->ai_addr == NULL || | ai->ai_addrlen == 0 || | getnameinfo(ai->ai_addr, ai->ai_addrlen, | straddr, sizeof(straddr), strport, sizeof (strport), | NI_NUMERICHOST|NI_NUMERICSERV) != 0) { | goto bad; | } | switch (ai->ai_family) { | case AF_INET: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "0.0.0.0") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "127.0.0.1") != 0) { | goto bad; | } | } | inet4++; | break; | case AF_INET6: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "::") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "::1") != 0) { | goto bad; | } | } | inet6++; | break; | case AF_UNSPEC: | goto bad; | break; | default: | /* another family support? */ | break; | } | } | } | | if (!(inet4 == 0 || inet4 == 2)) | goto bad; | if (!(inet6 == 0 || inet6 == 2)) | goto bad; | | if (aitop) | freeaddrinfo(aitop); | exit(0); | | bad: | if (aitop) | freeaddrinfo(aitop); | exit(1); | } | configure:14351: result: buggy ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 14:06 Message: Logged In: YES user_id=1083789 I just checked, and man getaddrinfo shows that HPUX _does_ have getaddrinfo: getaddrinfo(3N) getaddrinfo (3N) NAME getaddrinfo(), getnameinfo(), freeaddrinfo(), gai_strerror () - get hostname and address entry SYNOPSIS #include #include int getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res); int getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags); void freeaddrinfo(struct addrinfo *ai); char *gai_strerror(int encode); So the real problem is that configure didn't find it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 19:36 Message: Logged In: YES user_id=21627 Does that mean HP-UX does not have a native getaddrinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 From noreply at sourceforge.net Thu Aug 5 16:14:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 16:14:43 2004 Subject: [ python-Bugs-991125 ] Make Problem on HPUX Message-ID: Bugs item #991125, was opened at 2004-07-14 21:49 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Nobody/Anonymous (nobody) Summary: Make Problem on HPUX Initial Comment: Build of _socket fails: In file included from /home/python/Python- 2.4a1/Modules/socketmodule.c:314: /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_gai_strerror': /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: `EAI_MAX' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: (Each undeclared identifier is reported only once /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: for each function it appears in.) /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_getaddrinfo': /home/python/Python-2.4a1/Modules/getaddrinfo.c:282: `EAI_BADHINTS' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:283: `AI_MASK' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:373: `EAI_PROTOCOL' undeclared (first use in this function) The problem seems to be that #include "addrinfo.h" is in an #if 0 block in getaddrinfo.c When that include is moved out of the #if 0 block, the _socket module compiles and make test does not show any errors. System information: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license The above problem occurs with both gcc and with HP's C compiler. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-05 16:14 Message: Logged In: YES user_id=43607 Putting #include "addrinfo.h" outside the #if 0/#endif in getaddrinfo.c. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 15:13 Message: Logged In: YES user_id=21627 plusk, can you find out which of the "goto bad" statements was taken, by running the program separately, and adding printf calls? Historically, Python had to make these tests, because many platforms indeed *have* a broken getaddrinfo. sjoerd, in what way does exactly what fix the compilation problem on Cygwin? ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-05 14:59 Message: Logged In: YES user_id=43607 This also fixes the compilation problem on Cygwin. See bug 1001857. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 14:25 Message: Logged In: YES user_id=1083789 But configure thinks it's buggy: configure:14229: checking getaddrinfo bug configure:14332: gcc -o conftest -g -O2 conftest.c -lcl - lnsl -lrt -ldld -lpthread >&5 configure:14335: $? = 0 configure:14337: ./conftest configure:14340: $? = 1 configure: program exited with status 1 configure: failed program was: | #line 14236 "configure" | /* confdefs.h. */ | | #define _GNU_SOURCE 1 | #define _NETBSD_SOURCE 1 | #define __BSD_VISIBLE 1 | #define _XOPEN_SOURCE 600 | #define _XOPEN_SOURCE_EXTENDED 1 | #define _POSIX_C_SOURCE 200112L | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_GRP_H 1 | #define HAVE_LANGINFO_H 1 | #define HAVE_POLL_H 1 | #define HAVE_PTHREAD_H 1 | #define HAVE_STROPTS_H 1 | #define HAVE_TERMIOS_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_UTIME_H 1 | #define HAVE_SYS_BSDTTY_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_LOCK_H 1 | #define HAVE_SYS_MODEM_H 1 | #define HAVE_SYS_PARAM_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TIMES_H 1 | #define HAVE_SYS_UN_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_TERM_H 1 | #define HAVE_SYS_RESOURCE_H 1 | #define HAVE_SYSEXITS_H 1 | #define HAVE_DIRENT_H 1 | #define MAJOR_IN_SYSMACROS 1 | #define _LARGEFILE_SOURCE 1 | #define _FILE_OFFSET_BITS 64 | #if defined(SCO_DS) | #undef _OFF_T | #endif | #define RETSIGTYPE void | #define SIZEOF_INT 4 | #define SIZEOF_LONG 4 | #define SIZEOF_VOID_P 4 | #define SIZEOF_SHORT 2 | #define SIZEOF_FLOAT 4 | #define SIZEOF_DOUBLE 8 | #define SIZEOF_FPOS_T 8 | #define HAVE_LONG_LONG 1 | #define SIZEOF_LONG_LONG 8 | #define SIZEOF_OFF_T 8 | #define HAVE_LARGEFILE_SUPPORT 1 | #define SIZEOF_TIME_T 4 | #define SIZEOF_PTHREAD_T 4 | #define HAVE_LIBDLD 1 | #define _REENTRANT 1 | #define WITH_THREAD 1 | #define _POSIX_THREADS 1 | #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 | #define HAVE_PTHREAD_SIGMASK 1 | #define WITH_DOC_STRINGS 1 | #define WITH_PYMALLOC 1 | #define HAVE_DLOPEN 1 | #define HAVE_DYNAMIC_LOADING 1 | #define HAVE_ALARM 1 | #define HAVE_CHOWN 1 | #define HAVE_CLOCK 1 | #define HAVE_CONFSTR 1 | #define HAVE_CTERMID 1 | #define HAVE_EXECV 1 | #define HAVE_FORK 1 | #define HAVE_FPATHCONF 1 | #define HAVE_FTIME 1 | #define HAVE_FTRUNCATE 1 | #define HAVE_GAI_STRERROR 1 | #define HAVE_GETGROUPS 1 | #define HAVE_GETLOGIN 1 | #define HAVE_GETPEERNAME 1 | #define HAVE_GETPGID 1 | #define HAVE_GETPID 1 | #define HAVE_GETPRIORITY 1 | #define HAVE_GETPWENT 1 | #define HAVE_GETSID 1 | #define HAVE_GETWD 1 | #define HAVE_KILL 1 | #define HAVE_KILLPG 1 | #define HAVE_LCHOWN 1 | #define HAVE_LSTAT 1 | #define HAVE_MKFIFO 1 | #define HAVE_MKNOD 1 | #define HAVE_MKTIME 1 | #define HAVE_NICE 1 | #define HAVE_PATHCONF 1 | #define HAVE_PAUSE 1 | #define HAVE_PLOCK 1 | #define HAVE_POLL 1 | #define HAVE_PUTENV 1 | #define HAVE_READLINK 1 | #define HAVE_REALPATH 1 | #define HAVE_SELECT 1 | #define HAVE_SETGID 1 | #define HAVE_SETLOCALE 1 | #define HAVE_SETREGID 1 | #define HAVE_SETREUID 1 | #define HAVE_SETSID 1 | #define HAVE_SETPGID 1 | #define HAVE_SETPGRP 1 | #define HAVE_SETUID 1 | #define HAVE_SETVBUF 1 | #define HAVE_SNPRINTF 1 | #define HAVE_SIGACTION 1 | #define HAVE_SIGINTERRUPT 1 | #define HAVE_SIGRELSE 1 | #define HAVE_STRFTIME 1 | #define HAVE_SYSCONF 1 | #define HAVE_TCGETPGRP 1 | #define HAVE_TCSETPGRP 1 | #define HAVE_TEMPNAM 1 | #define HAVE_TIMES 1 | #define HAVE_TMPFILE 1 | #define HAVE_TMPNAM 1 | #define HAVE_TRUNCATE 1 | #define HAVE_UNAME 1 | #define HAVE_UTIMES 1 | #define HAVE_WAITPID 1 | #define HAVE_WCSCOLL 1 | #define HAVE_CHROOT 1 | #define HAVE_LINK 1 | #define HAVE_SYMLINK 1 | #define HAVE_FCHDIR 1 | #define HAVE_FSYNC 1 | #define HAVE_FDATASYNC 1 | #define HAVE_GETPAGESIZE 1 | #define HAVE_INET_ATON 1 | #define HAVE_INET_PTON 1 | #define HAVE_SETGROUPS 1 | #define HAVE_FSEEKO 1 | #define HAVE_FSTATVFS 1 | #define HAVE_FTELLO 1 | #define HAVE_STATVFS 1 | #define HAVE_DUP2 1 | #define HAVE_GETCWD 1 | #define HAVE_STRDUP 1 | #define HAVE_STRERROR 1 | #define HAVE_MEMMOVE 1 | #define HAVE_GETPGRP 1 | #define HAVE_SETPGRP 1 | #define HAVE_GETTIMEOFDAY 1 | /* end confdefs.h. */ | | #include | #include | #include | #include | #include | | main() | { | int passive, gaierr, inet4 = 0, inet6 = 0; | struct addrinfo hints, *ai, *aitop; | char straddr[INET6_ADDRSTRLEN], strport[16]; | | for (passive = 0; passive <= 1; passive++) { | memset(&hints, 0, sizeof(hints)); | hints.ai_family = AF_UNSPEC; | hints.ai_flags = passive ? AI_PASSIVE : 0; | hints.ai_socktype = SOCK_STREAM; | hints.ai_protocol = IPPROTO_TCP; | if ((gaierr = getaddrinfo(NULL, "54321", &hints, &aitop)) ! = 0) { | (void)gai_strerror(gaierr); | goto bad; | } | for (ai = aitop; ai; ai = ai->ai_next) { | if (ai->ai_addr == NULL || | ai->ai_addrlen == 0 || | getnameinfo(ai->ai_addr, ai->ai_addrlen, | straddr, sizeof(straddr), strport, sizeof (strport), | NI_NUMERICHOST|NI_NUMERICSERV) != 0) { | goto bad; | } | switch (ai->ai_family) { | case AF_INET: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "0.0.0.0") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "127.0.0.1") != 0) { | goto bad; | } | } | inet4++; | break; | case AF_INET6: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "::") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "::1") != 0) { | goto bad; | } | } | inet6++; | break; | case AF_UNSPEC: | goto bad; | break; | default: | /* another family support? */ | break; | } | } | } | | if (!(inet4 == 0 || inet4 == 2)) | goto bad; | if (!(inet6 == 0 || inet6 == 2)) | goto bad; | | if (aitop) | freeaddrinfo(aitop); | exit(0); | | bad: | if (aitop) | freeaddrinfo(aitop); | exit(1); | } | configure:14351: result: buggy ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 14:06 Message: Logged In: YES user_id=1083789 I just checked, and man getaddrinfo shows that HPUX _does_ have getaddrinfo: getaddrinfo(3N) getaddrinfo (3N) NAME getaddrinfo(), getnameinfo(), freeaddrinfo(), gai_strerror () - get hostname and address entry SYNOPSIS #include #include int getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res); int getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags); void freeaddrinfo(struct addrinfo *ai); char *gai_strerror(int encode); So the real problem is that configure didn't find it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 19:36 Message: Logged In: YES user_id=21627 Does that mean HP-UX does not have a native getaddrinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 From noreply at sourceforge.net Thu Aug 5 16:55:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 17:02:58 2004 Subject: [ python-Bugs-991125 ] Make Problem on HPUX Message-ID: Bugs item #991125, was opened at 2004-07-14 15:49 Message generated for change (Comment added) made by plusk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul D. Lusk (plusk) Assigned to: Nobody/Anonymous (nobody) Summary: Make Problem on HPUX Initial Comment: Build of _socket fails: In file included from /home/python/Python- 2.4a1/Modules/socketmodule.c:314: /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_gai_strerror': /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: `EAI_MAX' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: (Each undeclared identifier is reported only once /home/python/Python-2.4a1/Modules/getaddrinfo.c:204: for each function it appears in.) /home/python/Python-2.4a1/Modules/getaddrinfo.c: In function `fake_getaddrinfo': /home/python/Python-2.4a1/Modules/getaddrinfo.c:282: `EAI_BADHINTS' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:283: `AI_MASK' undeclared (first use in this function) /home/python/Python-2.4a1/Modules/getaddrinfo.c:373: `EAI_PROTOCOL' undeclared (first use in this function) The problem seems to be that #include "addrinfo.h" is in an #if 0 block in getaddrinfo.c When that include is moved out of the #if 0 block, the _socket module compiles and make test does not show any errors. System information: uname -a HP-UX voyager B.11.11 U 9000/800 3108770354 unlimited-user license The above problem occurs with both gcc and with HP's C compiler. ---------------------------------------------------------------------- >Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 10:55 Message: Logged In: YES user_id=1083789 It is the final inet4 test failing. inet4 is 1. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-05 10:14 Message: Logged In: YES user_id=43607 Putting #include "addrinfo.h" outside the #if 0/#endif in getaddrinfo.c. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 09:13 Message: Logged In: YES user_id=21627 plusk, can you find out which of the "goto bad" statements was taken, by running the program separately, and adding printf calls? Historically, Python had to make these tests, because many platforms indeed *have* a broken getaddrinfo. sjoerd, in what way does exactly what fix the compilation problem on Cygwin? ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-05 08:59 Message: Logged In: YES user_id=43607 This also fixes the compilation problem on Cygwin. See bug 1001857. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 08:25 Message: Logged In: YES user_id=1083789 But configure thinks it's buggy: configure:14229: checking getaddrinfo bug configure:14332: gcc -o conftest -g -O2 conftest.c -lcl - lnsl -lrt -ldld -lpthread >&5 configure:14335: $? = 0 configure:14337: ./conftest configure:14340: $? = 1 configure: program exited with status 1 configure: failed program was: | #line 14236 "configure" | /* confdefs.h. */ | | #define _GNU_SOURCE 1 | #define _NETBSD_SOURCE 1 | #define __BSD_VISIBLE 1 | #define _XOPEN_SOURCE 600 | #define _XOPEN_SOURCE_EXTENDED 1 | #define _POSIX_C_SOURCE 200112L | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_FCNTL_H 1 | #define HAVE_GRP_H 1 | #define HAVE_LANGINFO_H 1 | #define HAVE_POLL_H 1 | #define HAVE_PTHREAD_H 1 | #define HAVE_STROPTS_H 1 | #define HAVE_TERMIOS_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_UTIME_H 1 | #define HAVE_SYS_BSDTTY_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_LOCK_H 1 | #define HAVE_SYS_MODEM_H 1 | #define HAVE_SYS_PARAM_H 1 | #define HAVE_SYS_POLL_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_SYS_TIME_H 1 | #define HAVE_SYS_TIMES_H 1 | #define HAVE_SYS_UN_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_SYS_WAIT_H 1 | #define HAVE_TERM_H 1 | #define HAVE_SYS_RESOURCE_H 1 | #define HAVE_SYSEXITS_H 1 | #define HAVE_DIRENT_H 1 | #define MAJOR_IN_SYSMACROS 1 | #define _LARGEFILE_SOURCE 1 | #define _FILE_OFFSET_BITS 64 | #if defined(SCO_DS) | #undef _OFF_T | #endif | #define RETSIGTYPE void | #define SIZEOF_INT 4 | #define SIZEOF_LONG 4 | #define SIZEOF_VOID_P 4 | #define SIZEOF_SHORT 2 | #define SIZEOF_FLOAT 4 | #define SIZEOF_DOUBLE 8 | #define SIZEOF_FPOS_T 8 | #define HAVE_LONG_LONG 1 | #define SIZEOF_LONG_LONG 8 | #define SIZEOF_OFF_T 8 | #define HAVE_LARGEFILE_SUPPORT 1 | #define SIZEOF_TIME_T 4 | #define SIZEOF_PTHREAD_T 4 | #define HAVE_LIBDLD 1 | #define _REENTRANT 1 | #define WITH_THREAD 1 | #define _POSIX_THREADS 1 | #define PTHREAD_SYSTEM_SCHED_SUPPORTED 1 | #define HAVE_PTHREAD_SIGMASK 1 | #define WITH_DOC_STRINGS 1 | #define WITH_PYMALLOC 1 | #define HAVE_DLOPEN 1 | #define HAVE_DYNAMIC_LOADING 1 | #define HAVE_ALARM 1 | #define HAVE_CHOWN 1 | #define HAVE_CLOCK 1 | #define HAVE_CONFSTR 1 | #define HAVE_CTERMID 1 | #define HAVE_EXECV 1 | #define HAVE_FORK 1 | #define HAVE_FPATHCONF 1 | #define HAVE_FTIME 1 | #define HAVE_FTRUNCATE 1 | #define HAVE_GAI_STRERROR 1 | #define HAVE_GETGROUPS 1 | #define HAVE_GETLOGIN 1 | #define HAVE_GETPEERNAME 1 | #define HAVE_GETPGID 1 | #define HAVE_GETPID 1 | #define HAVE_GETPRIORITY 1 | #define HAVE_GETPWENT 1 | #define HAVE_GETSID 1 | #define HAVE_GETWD 1 | #define HAVE_KILL 1 | #define HAVE_KILLPG 1 | #define HAVE_LCHOWN 1 | #define HAVE_LSTAT 1 | #define HAVE_MKFIFO 1 | #define HAVE_MKNOD 1 | #define HAVE_MKTIME 1 | #define HAVE_NICE 1 | #define HAVE_PATHCONF 1 | #define HAVE_PAUSE 1 | #define HAVE_PLOCK 1 | #define HAVE_POLL 1 | #define HAVE_PUTENV 1 | #define HAVE_READLINK 1 | #define HAVE_REALPATH 1 | #define HAVE_SELECT 1 | #define HAVE_SETGID 1 | #define HAVE_SETLOCALE 1 | #define HAVE_SETREGID 1 | #define HAVE_SETREUID 1 | #define HAVE_SETSID 1 | #define HAVE_SETPGID 1 | #define HAVE_SETPGRP 1 | #define HAVE_SETUID 1 | #define HAVE_SETVBUF 1 | #define HAVE_SNPRINTF 1 | #define HAVE_SIGACTION 1 | #define HAVE_SIGINTERRUPT 1 | #define HAVE_SIGRELSE 1 | #define HAVE_STRFTIME 1 | #define HAVE_SYSCONF 1 | #define HAVE_TCGETPGRP 1 | #define HAVE_TCSETPGRP 1 | #define HAVE_TEMPNAM 1 | #define HAVE_TIMES 1 | #define HAVE_TMPFILE 1 | #define HAVE_TMPNAM 1 | #define HAVE_TRUNCATE 1 | #define HAVE_UNAME 1 | #define HAVE_UTIMES 1 | #define HAVE_WAITPID 1 | #define HAVE_WCSCOLL 1 | #define HAVE_CHROOT 1 | #define HAVE_LINK 1 | #define HAVE_SYMLINK 1 | #define HAVE_FCHDIR 1 | #define HAVE_FSYNC 1 | #define HAVE_FDATASYNC 1 | #define HAVE_GETPAGESIZE 1 | #define HAVE_INET_ATON 1 | #define HAVE_INET_PTON 1 | #define HAVE_SETGROUPS 1 | #define HAVE_FSEEKO 1 | #define HAVE_FSTATVFS 1 | #define HAVE_FTELLO 1 | #define HAVE_STATVFS 1 | #define HAVE_DUP2 1 | #define HAVE_GETCWD 1 | #define HAVE_STRDUP 1 | #define HAVE_STRERROR 1 | #define HAVE_MEMMOVE 1 | #define HAVE_GETPGRP 1 | #define HAVE_SETPGRP 1 | #define HAVE_GETTIMEOFDAY 1 | /* end confdefs.h. */ | | #include | #include | #include | #include | #include | | main() | { | int passive, gaierr, inet4 = 0, inet6 = 0; | struct addrinfo hints, *ai, *aitop; | char straddr[INET6_ADDRSTRLEN], strport[16]; | | for (passive = 0; passive <= 1; passive++) { | memset(&hints, 0, sizeof(hints)); | hints.ai_family = AF_UNSPEC; | hints.ai_flags = passive ? AI_PASSIVE : 0; | hints.ai_socktype = SOCK_STREAM; | hints.ai_protocol = IPPROTO_TCP; | if ((gaierr = getaddrinfo(NULL, "54321", &hints, &aitop)) ! = 0) { | (void)gai_strerror(gaierr); | goto bad; | } | for (ai = aitop; ai; ai = ai->ai_next) { | if (ai->ai_addr == NULL || | ai->ai_addrlen == 0 || | getnameinfo(ai->ai_addr, ai->ai_addrlen, | straddr, sizeof(straddr), strport, sizeof (strport), | NI_NUMERICHOST|NI_NUMERICSERV) != 0) { | goto bad; | } | switch (ai->ai_family) { | case AF_INET: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "0.0.0.0") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "127.0.0.1") != 0) { | goto bad; | } | } | inet4++; | break; | case AF_INET6: | if (strcmp(strport, "54321") != 0) { | goto bad; | } | if (passive) { | if (strcmp(straddr, "::") != 0) { | goto bad; | } | } else { | if (strcmp(straddr, "::1") != 0) { | goto bad; | } | } | inet6++; | break; | case AF_UNSPEC: | goto bad; | break; | default: | /* another family support? */ | break; | } | } | } | | if (!(inet4 == 0 || inet4 == 2)) | goto bad; | if (!(inet6 == 0 || inet6 == 2)) | goto bad; | | if (aitop) | freeaddrinfo(aitop); | exit(0); | | bad: | if (aitop) | freeaddrinfo(aitop); | exit(1); | } | configure:14351: result: buggy ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-05 08:06 Message: Logged In: YES user_id=1083789 I just checked, and man getaddrinfo shows that HPUX _does_ have getaddrinfo: getaddrinfo(3N) getaddrinfo (3N) NAME getaddrinfo(), getnameinfo(), freeaddrinfo(), gai_strerror () - get hostname and address entry SYNOPSIS #include #include int getaddrinfo(const char *hostname, const char *servname, const struct addrinfo *hints, struct addrinfo **res); int getnameinfo(const struct sockaddr *sa, size_t salen, char *host, size_t hostlen, char *serv, size_t servlen, int flags); void freeaddrinfo(struct addrinfo *ai); char *gai_strerror(int encode); So the real problem is that configure didn't find it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 13:36 Message: Logged In: YES user_id=21627 Does that mean HP-UX does not have a native getaddrinfo? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991125&group_id=5470 From noreply at sourceforge.net Thu Aug 5 17:12:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 17:12:54 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 >Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 17:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 15:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Thu Aug 5 17:14:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 17:14:11 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Comment added) made by hfuru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 >Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 17:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 17:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 15:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Thu Aug 5 17:17:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 17:18:00 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Settings changed) made by hfuru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 >Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 17:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 17:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 15:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Thu Aug 5 18:10:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 18:10:59 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-30 20:08 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-05 12:10 Message: Logged In: YES user_id=593130 Duh, my turn to forget. For any beginners reading this ... >>> class ms(str): pass ... >>> a=ms('a') >>> type(''.join((a,))) Expanding mhw's second point: >>> e=ms() >>> type(e) >>> import copy >>> e2=copy.copy(e) >>> type(e2) >>> e3=e[:] >>> type(e3) >>> id(e),id(e2),id(e3) (9494608, 9009936, 8577440) so [:] is not exactly an abbreviated synonym for copy(). Is this a butg? (I haven't rechecked the respective docs yet.) One reason I hesitate to call the OP's original observation a bug is that the whole sujbect of operations on subtype instances seems not completely baked. Knowing the result types in all cases may require experiments as well as doc reading. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 08:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-04 16:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 15:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 10:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Thu Aug 5 18:10:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 18:11:09 2004 Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility Message-ID: Bugs item #997368, was opened at 2004-07-24 23:59 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Jp Calderone (kuran) Assigned to: Barry A. Warsaw (bwarsaw) Summary: strftime() backwards incompatibility Initial Comment: time.strftime() in 2.4a0 places more restrictions on its inputs than does the version in 2.3.x. Revision 2.140 seems to be where this was introduced. I believe it is a common use of strftime() to fill out only some fields of the time tuple. Requiring the day of year and day of week is particularly burdensome. Here is an example that triggers the changed behavior: import time now = time.gmtime() now = now[:-3] + (0, 0, 0) print time.strftime("", now) ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2004-08-05 12:10 Message: Logged In: YES user_id=366566 Diff to update _parseaddr and rfc822 modules to use 0 instead of 1 for values it does not compute. Test module also updated (it explicitly compared to 0, now it explicitly compares to 1). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-27 18:58 Message: Logged In: YES user_id=764593 For me, Day-of-week and day-of-year are typically there because the format was decided externally; I don't track them in my application. I've seen databases with timestamps that all end in "000". I would be happy to have "None" replaced by a default value; it is just that the result should be consistent with what I did pass. For example, I wouldn't want to pass year/month/day and discover that every single day is Monday, or to pass year/ day-of-year and discover that day 345 is still in January. -jJ ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-27 18:41 Message: Logged In: YES user_id=357491 I could live with the None option but not the short tuple option. The former is explicitly not a number and nothing returns that for time tuples to my knowledge. The latter, though, might mask bugs in code when you accidentally truncated your tuple too much. And yes, other values can be computed from other fields (strptime has the code for some slots and I think datetime can do some as well). But why waste the overhead? While strptime has to care since you are getting a time tuple and thus it can't guess what fields you care about, strftime shouldn't need to care since it is assumed that you are passing in as much info as needed for the format directive to have what it needs. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-27 11:01 Message: Logged In: YES user_id=764593 What about a python wrapper to the C function that accepted either short tuples or None in trailing (or any?) positions and automatically filled in a default value. Some can be computed from other fields; if not, the same defaults used in strptime seem as reasonable as any. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-26 20:53 Message: Logged In: YES user_id=357491 =) No need to presume; I know better. Writing strftime in Python would be rather difficult since there is no other consistent way to get at all of that locale info. Yes, you could use the locale module, but even that is iffy at times on some platforms. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-26 11:30 Message: Logged In: YES user_id=31435 Ah, that's a bug in rfc822.parsedate_tz(), with a copy+paste duplicate bug in email._parseaddr.parsedate_tz(). Assigning this report to Barry hoping he'll fix those, and boosted the priority: Barry, 0 is an illegal value for tm_yday in a Python time tuple. Python 2.4 cares about this. You want 1 there instead. I'd do it, but am not familiar with the test suites for those modules. C99's strftime is a large and complicated function, so it would take a peculiar kind of masochism for someone to want to rewrite it in Python. Brett did the Python strptime, but he's older now, and has presumably learned better . ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-07-26 01:25 Message: Logged In: YES user_id=366566 The more I think about it the more I want to suggest that strftime just be implemented in Python so that garbage values that are never required can be accepted, safe in the knowledge that they won't be used by the implementation. I'm not sure how feasible this is. I know strptime is now provided by Python and not the underlying library, so it seems at least in the ballpark of plausibility. On the other hand, looking more closely at what my requirements really are, it seems that the input to strftime() is actually coming from rfc822.parsedate_tz(), which builds up a tuple containing all the interesting values, and uses 0s for the nonsense ones. Would a patch for parsedate_tz() (and similarly behaving functions, I suppose, though I can't think of any off the top of my head) to generate values acceptable to strftime() be more acceptable? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-26 00:45 Message: Logged In: YES user_id=31435 JP, can you define which nonsense values "are needed"? We can't go back to allowing garbage everywhere, because doing so did cause crashes in platform C libraries. The only thing it complains about in the specific example you gave is the middle 0. I agree that one is irritating, and is due to Python inexplicably saying that tm_yday must be in 1 .. 366 (instead of C's 0 .. 365) -- so Python subtracts one from the middle 0, giving a -1 that we can't afford to pass on to the C library. If the only thing you really need is to allow a 0 for tm_yday, perhaps that could be allowed without whining. 0 is fine for tm_wday already, and for tm_isdst. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-25 22:39 Message: Logged In: YES user_id=357491 This was brought up on python-dev in the thread http://mail.python.org/ pipermail/python-dev/2004-July/046418.html . This was all originally discussed back in Feb 2004: http://mail.python.org/pipermail/python- dev/2004-February/042675.html . The current solution was discussed on python-dev and agreed upon. Because using values that are outside of basic boundaries can lead to core dumps (mostly thanks to strftime() implementations that do not check boundary values when indexing into arrays) a check to make sure all values are within sane values, but *without* checking whether they are valid values when compared to each other, was added. The docs do say that "ValueError raised if a field in [tuple] t is out of range". Personally I say close this as won't fix. python-dev came to the conclusion collectively that breaking possible code that played loosely with the passed-in values was better than allowing possible core dumps. A very compelling reason that got multiple support from othe developers would be needed, in my opinion, to overturn this change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470 From noreply at sourceforge.net Thu Aug 5 18:42:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 18:42:40 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Comment added) made by hfuru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 18:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 17:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 17:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 15:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Thu Aug 5 23:48:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 5 23:48:15 2004 Subject: [ python-Bugs-1004217 ] Shortcut keys don't work when CAPS LOCK is on Message-ID: Bugs item #1004217, was opened at 2004-08-05 21:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004217&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: otto (ottoisi) Assigned to: Nobody/Anonymous (nobody) Summary: Shortcut keys don't work when CAPS LOCK is on Initial Comment: IDLE for win32 does not execute keyboard shortcuts when CAPS LOCK is on or the SHIFT key is is pressed. e.g. ctrl-C doesn't work if it's a capital C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004217&group_id=5470 From noreply at sourceforge.net Fri Aug 6 01:49:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 01:49:07 2004 Subject: [ python-Bugs-985478 ] bdist_rpm license documented, but not accepted as valid Message-ID: Bugs item #985478, was opened at 2004-07-05 10:14 Message generated for change (Comment added) made by melicertes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985478&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm license documented, but not accepted as valid Initial Comment: The distutils documentation at http://docs.python.org/dist/postinstallation-script.html#SECTION000620000000000000000 states that the RPM copyright field can be set using the distutils setup script option "licence", but it is refused as invalid by distutils: $ /usr/bin/python2.3 setup.py bdist_rpm --licence="GNU GPL v.2" usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option --licence not recognized It's also refused (same error message output, except for spelling) with the spelling "license". Both spellings are also rejected as errors if placed in setup.cfg's [bdist_rpm] section: $ /usr/bin/python2.3 setup.py bdist_rpm running bdist_rpm error: error in setup.cfg: command 'bdist_rpm' has no such option 'license' ---------------------------------------------------------------------- >Comment By: Charles (melicertes) Date: 2004-08-05 17:48 Message: Logged In: YES user_id=1064824 My error, influenced by imprecise documentation. The docs make it sound like this can be supplied as a setup.cfg parameter, but it's actually a parameter of the setup() function. ---------------------------------------------------------------------- Comment By: Charles (melicertes) Date: 2004-07-09 08:47 Message: Logged In: YES user_id=1064824 No response? I can't use distutils to create RPMs if I can't specify the license. Normally I'd just write my own spec file and use the --spec-file option, but the docs say this isn't implemented yet. ---------------------------------------------------------------------- Comment By: Charles (melicertes) Date: 2004-07-05 10:43 Message: Logged In: YES user_id=1064824 This was tested with Python 2.3.4 final, by the way. The behaviour was unchanged in earlier release candidates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985478&group_id=5470 From noreply at sourceforge.net Fri Aug 6 01:53:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 01:53:34 2004 Subject: [ python-Bugs-1004271 ] imaplib.IMAP4.select doesn't return critical data Message-ID: Bugs item #1004271, was opened at 2004-08-05 17:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004271&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib.IMAP4.select doesn't return critical data Initial Comment: The .select() method of IMAP4 objects returns the EXISTS data, but not the more-critical UIDVALIDITY data. Without UIDVALIDITY, the UID command is useless. I have a patch, but it changes the API of the .select() method, so it's unlikely to go into mainline -- and select() also fails to return two other data items from the SELECT command (FLAGS and RECENT). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004271&group_id=5470 From noreply at sourceforge.net Fri Aug 6 07:10:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 07:10:21 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 09:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-06 01:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 12:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 11:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 11:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 09:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Fri Aug 6 08:40:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 08:40:08 2004 Subject: [ python-Bugs-1002475 ] email message parser doesn't handle \r\n correctly Message-ID: Bugs item #1002475, was opened at 2004-08-03 10:32 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Nobody/Anonymous (nobody) Summary: email message parser doesn't handle \r\n correctly Initial Comment: Header lines that end in \r\n only get the \n stripped, not the \r (unless it's the last header which does get the \r stripped): >>> import email.Parser >>> m = 'Header: text\r\nNext-Header: more text\r\n\r\nBody\r\n\r\n' >>> msg = email.Parser.Parser().parsestr(m) >>> msg.get('header') 'text\r' >>> msg.get('next-header') 'more text' >>> This bug showed itself in my SpamBayes setup using sb_imapfilter.py where base64-encoded text/html messages were not decoded in Message.get_payload because the call to get('content-transfer-encoding') returned the string 'base64\r' instead of 'base64'. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-06 08:40 Message: Logged In: YES user_id=43607 The patch seems to work well. +1 for checking it in. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-08-05 03:28 Message: Logged In: YES user_id=552329 A patch to fix this is in: [ 1003693 ] Fix for 1002475 (Feedparser not handling \r\n correctly) http://sourceforge.net/tracker/index.php?func=detail&aid=1003693&group_id=5470&atid=305470 I'll try to write a test for it, too, and also attach that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 From noreply at sourceforge.net Fri Aug 6 13:15:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 13:15:41 2004 Subject: [ python-Feature Requests-1004533 ] PEP 263: help locating the offending character Message-ID: Feature Requests item #1004533, was opened at 2004-08-06 12:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004533&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Martin v. L?wis (loewis) Summary: PEP 263: help locating the offending character Initial Comment: Would it be (easily) possible to print the column as well as the line of the character with the 8th bit set in the message for the DeprecationWarning? I make this request because emacs sometimes seems to want to put latin1 non-breaking spaces (\xA0) in my comments and they are quite hard to spot :-) I can probably implement this myself, but you (Martin) can probably do it in a snap -- if it's easy, anyway. If it's hard, I'm not sure it's worth it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004533&group_id=5470 From noreply at sourceforge.net Fri Aug 6 13:51:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 13:51:16 2004 Subject: [ python-Feature Requests-1004533 ] PEP 263: help locating the offending character Message-ID: Feature Requests item #1004533, was opened at 2004-08-06 13:15 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004533&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Martin v. L?wis (loewis) Summary: PEP 263: help locating the offending character Initial Comment: Would it be (easily) possible to print the column as well as the line of the character with the 8th bit set in the message for the DeprecationWarning? I make this request because emacs sometimes seems to want to put latin1 non-breaking spaces (\xA0) in my comments and they are quite hard to spot :-) I can probably implement this myself, but you (Martin) can probably do it in a snap -- if it's easy, anyway. If it's hard, I'm not sure it's worth it. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-08-06 13:51 Message: Logged In: YES user_id=89016 StreamReaders that keep track of line and column numbers would help implementors of other types of parsers too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004533&group_id=5470 From noreply at sourceforge.net Fri Aug 6 15:56:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 15:56:55 2004 Subject: [ python-Bugs-1004629 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004629, was opened at 2004-08-06 14:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004629&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ben handley (bhandley) Assigned to: Nobody/Anonymous (nobody) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004629&group_id=5470 From noreply at sourceforge.net Fri Aug 6 17:08:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 17:08:11 2004 Subject: [ python-Bugs-1004669 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004669, was opened at 2004-08-06 16:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ben handley (bhandley) Assigned to: Nobody/Anonymous (nobody) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 From noreply at sourceforge.net Fri Aug 6 18:00:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 18:00:25 2004 Subject: [ python-Feature Requests-1004696 ] translate Windows cr-lf when installing scripts on Linux Message-ID: Feature Requests item #1004696, was opened at 2004-08-06 12:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004696&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Cera (timcera) Assigned to: Nobody/Anonymous (nobody) Summary: translate Windows cr-lf when installing scripts on Linux Initial Comment: PROBLEM If a file installed as a script has Window cr-lf endings, even if the '#!/usr/bin/env python' is included to support direct execution on Linux, it doesn't work because the shell is confused by the cr-lf. This problem has been addressed in the newsgroups, with the usual solution to manually change the line endings, or only develop with an editor that can maintain Linux line endings. SOLUTION Convert line endings on installed scripts to the line endings appropriate to the machine running the installation. Could be limited to Unix/Linux platform because Windows doesn't care about the line endings. kindest regards, tim ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004696&group_id=5470 From noreply at sourceforge.net Fri Aug 6 18:01:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 18:01:44 2004 Subject: [ python-Bugs-1004698 ] Int Type Documentation incomplete Message-ID: Bugs item #1004698, was opened at 2004-08-06 12:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Int Type Documentation incomplete Initial Comment: __new__ and __newargs__ don't appear to be documented c.mro() seems to show a circular definition. Please see the examples below: >>> c >>> c.mro() [, ] >>> c.__getnewargs__() >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: descriptor '__getnewargs__' of 'int' object needs an argument >>> c.__getnewargs__(21) (21,) >>> c= 1+1j >>> c (1+1j) >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: __getnewargs__() takes no arguments (1 given) >>> c.__getnewargs__() ((1+1j),) >>> c.__new__ >>> c.__new__(ComplexType) 0j >>> Colin W. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 From noreply at sourceforge.net Fri Aug 6 20:49:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 20:49:35 2004 Subject: [ python-Bugs-1004669 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004669, was opened at 2004-08-06 08:08 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ben handley (bhandley) Assigned to: Nobody/Anonymous (nobody) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-06 11:49 Message: Logged In: YES user_id=971153 Why do you think the existing behaviour is wrong? All Python type checking is done at run time E.g. >>> 12+"123" Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand types for +: 'int' and 'str' How is your example different? I would suggest to close the bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 From noreply at sourceforge.net Fri Aug 6 20:51:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 20:51:22 2004 Subject: [ python-Bugs-1004810 ] Carbon.File fails if server vol is mounted after launch Message-ID: Bugs item #1004810, was opened at 2004-08-06 14:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004810&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Pharr (pharr) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.File fails if server vol is mounted after launch Initial Comment: On MacOs X 10.3.x (with the stock Python 2.3). Carbon.File.FSSpec(theFile) will fail with a -120 (Directory Not Found) error if theFile is on a server volume which was mounted after the script was launched. In actuality, it may be a little more complex, because if there is only a single server volume mounted, then Carbon.File sometimes will not fail until the volume is mounted, unmounted, and remounted a few times. Mounting two or more volumes causes the situation to become more consistently reproducible. What is going on is that each application's instance of the Carbon File Manager depends on being notified by the MacOS X operating system when volumes are mounted and unmounted through the application's runloop. Since python scripts do not implement a runloop, the running python process' carbon file manager never gets a chance to see these notifications and consequently it's internal data structures describing the state of the mounted volumes become out of date if volumes are mounted or unmounted repeatedly from other processes. This causes most Carbon.File calls to fail when manipulating files on a server volume if that volume is mounted while the script is running. My situation is an automated build script which wants to continue running while mounting and unmounting server volumes onto which to copy the resulting build products. After the first two builds (and mounting and unmounting two AFP volumes twice), all Carbon.File calls subsequently will fail until the python script is relaunched. It seems like there would be a way to get Carbon.File to be able to look a little harder for these volumes, but I haven't found a good workaround other than to call a sub-script for any operation which requires Carbon.File. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004810&group_id=5470 From noreply at sourceforge.net Fri Aug 6 20:53:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 20:53:24 2004 Subject: [ python-Bugs-1004629 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004629, was opened at 2004-08-06 06:56 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004629&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ben handley (bhandley) Assigned to: Nobody/Anonymous (nobody) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-06 11:53 Message: Logged In: YES user_id=971153 Seems like a duplicate of bug #1004669 I would suggest to either delete or close this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004629&group_id=5470 From noreply at sourceforge.net Fri Aug 6 21:36:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 21:36:51 2004 Subject: [ python-Bugs-1004837 ] Limited User gets error in 2.4a2 MSI Message-ID: Bugs item #1004837, was opened at 2004-08-06 21:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004837&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Martin v. L?wis (loewis) Summary: Limited User gets error in 2.4a2 MSI Initial Comment: An XP "Limited User" reportedly gets an error that it cannot write the HKEY_CURRENT_USER registry. This should be detected early on, aborting the installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004837&group_id=5470 From noreply at sourceforge.net Fri Aug 6 22:07:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 22:07:35 2004 Subject: [ python-Bugs-1004629 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004629, was opened at 2004-08-06 08:56 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004629&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ben handley (bhandley) >Assigned to: Raymond Hettinger (rhettinger) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-06 13:53 Message: Logged In: YES user_id=971153 Seems like a duplicate of bug #1004669 I would suggest to either delete or close this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004629&group_id=5470 From noreply at sourceforge.net Fri Aug 6 22:08:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 22:08:13 2004 Subject: [ python-Bugs-1004669 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004669, was opened at 2004-08-06 10:08 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ben handley (bhandley) >Assigned to: Raymond Hettinger (rhettinger) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-06 13:49 Message: Logged In: YES user_id=971153 Why do you think the existing behaviour is wrong? All Python type checking is done at run time E.g. >>> 12+"123" Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand types for +: 'int' and 'str' How is your example different? I would suggest to close the bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 From noreply at sourceforge.net Fri Aug 6 22:08:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 22:08:38 2004 Subject: [ python-Bugs-1004629 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004629, was opened at 2004-08-06 08:56 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004629&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: ben handley (bhandley) Assigned to: Raymond Hettinger (rhettinger) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-06 13:53 Message: Logged In: YES user_id=971153 Seems like a duplicate of bug #1004669 I would suggest to either delete or close this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004629&group_id=5470 From noreply at sourceforge.net Fri Aug 6 22:08:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 22:09:05 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 08:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) >Assigned to: Raymond Hettinger (rhettinger) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-06 00:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 11:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 10:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 10:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 08:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Fri Aug 6 23:03:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 23:03:12 2004 Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility Message-ID: Bugs item #997368, was opened at 2004-07-24 23:59 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Jp Calderone (kuran) Assigned to: Barry A. Warsaw (bwarsaw) Summary: strftime() backwards incompatibility Initial Comment: time.strftime() in 2.4a0 places more restrictions on its inputs than does the version in 2.3.x. Revision 2.140 seems to be where this was introduced. I believe it is a common use of strftime() to fill out only some fields of the time tuple. Requiring the day of year and day of week is particularly burdensome. Here is an example that triggers the changed behavior: import time now = time.gmtime() now = now[:-3] + (0, 0, 0) print time.strftime("", now) ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2004-08-06 17:03 Message: Logged In: YES user_id=366566 0s and 1s reversed in previous post. Correct in patch, though. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-08-05 12:10 Message: Logged In: YES user_id=366566 Diff to update _parseaddr and rfc822 modules to use 0 instead of 1 for values it does not compute. Test module also updated (it explicitly compared to 0, now it explicitly compares to 1). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-27 18:58 Message: Logged In: YES user_id=764593 For me, Day-of-week and day-of-year are typically there because the format was decided externally; I don't track them in my application. I've seen databases with timestamps that all end in "000". I would be happy to have "None" replaced by a default value; it is just that the result should be consistent with what I did pass. For example, I wouldn't want to pass year/month/day and discover that every single day is Monday, or to pass year/ day-of-year and discover that day 345 is still in January. -jJ ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-27 18:41 Message: Logged In: YES user_id=357491 I could live with the None option but not the short tuple option. The former is explicitly not a number and nothing returns that for time tuples to my knowledge. The latter, though, might mask bugs in code when you accidentally truncated your tuple too much. And yes, other values can be computed from other fields (strptime has the code for some slots and I think datetime can do some as well). But why waste the overhead? While strptime has to care since you are getting a time tuple and thus it can't guess what fields you care about, strftime shouldn't need to care since it is assumed that you are passing in as much info as needed for the format directive to have what it needs. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-27 11:01 Message: Logged In: YES user_id=764593 What about a python wrapper to the C function that accepted either short tuples or None in trailing (or any?) positions and automatically filled in a default value. Some can be computed from other fields; if not, the same defaults used in strptime seem as reasonable as any. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-26 20:53 Message: Logged In: YES user_id=357491 =) No need to presume; I know better. Writing strftime in Python would be rather difficult since there is no other consistent way to get at all of that locale info. Yes, you could use the locale module, but even that is iffy at times on some platforms. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-26 11:30 Message: Logged In: YES user_id=31435 Ah, that's a bug in rfc822.parsedate_tz(), with a copy+paste duplicate bug in email._parseaddr.parsedate_tz(). Assigning this report to Barry hoping he'll fix those, and boosted the priority: Barry, 0 is an illegal value for tm_yday in a Python time tuple. Python 2.4 cares about this. You want 1 there instead. I'd do it, but am not familiar with the test suites for those modules. C99's strftime is a large and complicated function, so it would take a peculiar kind of masochism for someone to want to rewrite it in Python. Brett did the Python strptime, but he's older now, and has presumably learned better . ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-07-26 01:25 Message: Logged In: YES user_id=366566 The more I think about it the more I want to suggest that strftime just be implemented in Python so that garbage values that are never required can be accepted, safe in the knowledge that they won't be used by the implementation. I'm not sure how feasible this is. I know strptime is now provided by Python and not the underlying library, so it seems at least in the ballpark of plausibility. On the other hand, looking more closely at what my requirements really are, it seems that the input to strftime() is actually coming from rfc822.parsedate_tz(), which builds up a tuple containing all the interesting values, and uses 0s for the nonsense ones. Would a patch for parsedate_tz() (and similarly behaving functions, I suppose, though I can't think of any off the top of my head) to generate values acceptable to strftime() be more acceptable? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-26 00:45 Message: Logged In: YES user_id=31435 JP, can you define which nonsense values "are needed"? We can't go back to allowing garbage everywhere, because doing so did cause crashes in platform C libraries. The only thing it complains about in the specific example you gave is the middle 0. I agree that one is irritating, and is due to Python inexplicably saying that tm_yday must be in 1 .. 366 (instead of C's 0 .. 365) -- so Python subtracts one from the middle 0, giving a -1 that we can't afford to pass on to the C library. If the only thing you really need is to allow a 0 for tm_yday, perhaps that could be allowed without whining. 0 is fine for tm_wday already, and for tm_isdst. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-25 22:39 Message: Logged In: YES user_id=357491 This was brought up on python-dev in the thread http://mail.python.org/ pipermail/python-dev/2004-July/046418.html . This was all originally discussed back in Feb 2004: http://mail.python.org/pipermail/python- dev/2004-February/042675.html . The current solution was discussed on python-dev and agreed upon. Because using values that are outside of basic boundaries can lead to core dumps (mostly thanks to strftime() implementations that do not check boundary values when indexing into arrays) a check to make sure all values are within sane values, but *without* checking whether they are valid values when compared to each other, was added. The docs do say that "ValueError raised if a field in [tuple] t is out of range". Personally I say close this as won't fix. python-dev came to the conclusion collectively that breaking possible code that played loosely with the passed-in values was better than allowing possible core dumps. A very compelling reason that got multiple support from othe developers would be needed, in my opinion, to overturn this change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470 From noreply at sourceforge.net Fri Aug 6 23:09:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 6 23:09:45 2004 Subject: [ python-Bugs-1003323 ] telnetlib on Windows: read_until() freezes Message-ID: Bugs item #1003323, was opened at 2004-08-04 10:45 Message generated for change (Comment added) made by yturgeon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003323&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Yannick Turgeon (yturgeon) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib on Windows: read_until() freezes Initial Comment: I'm currently trying to pass commands to a telnet session and get the texte generated (stdin + stdout) by the session. The problem I get is that the Telnet.read_until() function seems to freeze after a couple of command. I did a simplified script (attached) that reproduce the problem each time. In the script, when I send the command "echo bar7" to the telnet session, it freezes forever without a Timeout. I'm using 2.3.4 on Windows 2000 Server. According to a feedback for the comp.lang.python newsgroup, this problem do not occur on linux systems. Thanks Yannick yannick.turgeon@cablevision.qc.ca ---------------------------------------------------------------------- >Comment By: Yannick Turgeon (yturgeon) Date: 2004-08-06 17:09 Message: Logged In: YES user_id=280297 Forget this bug. In fact it's not a bug. The problem comes from the fact that Microsoft does not use a *real* telnet server. It's documented in Perl Net::Telnet doc. They are not fully respecting telnet protocol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003323&group_id=5470 From noreply at sourceforge.net Sat Aug 7 01:05:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 01:05:21 2004 Subject: [ python-Bugs-1004669 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004669, was opened at 2004-08-06 16:08 Message generated for change (Comment added) made by bhandley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ben handley (bhandley) Assigned to: Raymond Hettinger (rhettinger) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- >Comment By: ben handley (bhandley) Date: 2004-08-07 00:05 Message: Logged In: YES user_id=765626 If it raised a TypeError rather than SystemError I would think it fine. I didn't think that python code should be able to cause correct C code to generate `bad argument to internal function'. To me, that sounds like `some C function called some other C function badly', rather than just a bad type from python. In fact I believe that that is exactly what is happening. Here are the final two lines from the backtrace: #0 PyList_Sort (v=0x4029bc20) at Objects/listobject.c:2110 #1 0x0807b659 in PyObject_Dir (arg=0x0) at Objects/object.c:1705 PyList_Sort seems to assume that it will always be passed a list, hence it calls PyErr_BadInternalCall() if it's not. Assuming this is true, either PyObject_Dir or PyMapping_Keys should do the type checking and raise TypeError if it's not a list. Doesn't PyErr_BadInternalCall() mean that someone violated the C API of an internal function, therefore the bug is in C code rather than python? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-06 19:49 Message: Logged In: YES user_id=971153 Why do you think the existing behaviour is wrong? All Python type checking is done at run time E.g. >>> 12+"123" Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand types for +: 'int' and 'str' How is your example different? I would suggest to close the bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 From noreply at sourceforge.net Sat Aug 7 01:42:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 01:42:37 2004 Subject: [ python-Bugs-1002530 ] test_decimal fails if repeated Message-ID: Bugs item #1002530, was opened at 2004-08-03 05:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002530&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Raymond Hettinger (rhettinger) Summary: test_decimal fails if repeated Initial Comment: You can see this by trying, eg, $ ./python ../Lib/test/regrtest.py test_decimal test_decimal I think it's something like precision not being restored in the default context, but I don't really know. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-06 18:42 Message: Logged In: YES user_id=80475 Fixed. See Lib/decimal.py 1.20 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002530&group_id=5470 From noreply at sourceforge.net Sat Aug 7 01:43:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 01:43:14 2004 Subject: [ python-Bugs-1004669 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004669, was opened at 2004-08-06 10:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ben handley (bhandley) Assigned to: Raymond Hettinger (rhettinger) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-06 18:43 Message: Logged In: YES user_id=80475 It's a bug. Will fix. ---------------------------------------------------------------------- Comment By: ben handley (bhandley) Date: 2004-08-06 18:05 Message: Logged In: YES user_id=765626 If it raised a TypeError rather than SystemError I would think it fine. I didn't think that python code should be able to cause correct C code to generate `bad argument to internal function'. To me, that sounds like `some C function called some other C function badly', rather than just a bad type from python. In fact I believe that that is exactly what is happening. Here are the final two lines from the backtrace: #0 PyList_Sort (v=0x4029bc20) at Objects/listobject.c:2110 #1 0x0807b659 in PyObject_Dir (arg=0x0) at Objects/object.c:1705 PyList_Sort seems to assume that it will always be passed a list, hence it calls PyErr_BadInternalCall() if it's not. Assuming this is true, either PyObject_Dir or PyMapping_Keys should do the type checking and raise TypeError if it's not a list. Doesn't PyErr_BadInternalCall() mean that someone violated the C API of an internal function, therefore the bug is in C code rather than python? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-06 13:49 Message: Logged In: YES user_id=971153 Why do you think the existing behaviour is wrong? All Python type checking is done at run time E.g. >>> 12+"123" Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand types for +: 'int' and 'str' How is your example different? I would suggest to close the bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 From noreply at sourceforge.net Sat Aug 7 01:44:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 01:47:31 2004 Subject: [ python-Bugs-772091 ] doctest.DocTestSuite does not support __test__ Message-ID: Bugs item #772091, was opened at 2003-07-16 00:04 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772091&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 4 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Tim Peters (tim_one) Summary: doctest.DocTestSuite does not support __test__ Initial Comment: The DocTestSuite tool ignores a module level dictionary named __test__. This limits its usefulness for the current python testsuite. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-06 18:44 Message: Logged In: YES user_id=80475 Perhaps this can be incorporated in your updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772091&group_id=5470 From noreply at sourceforge.net Sat Aug 7 06:55:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 06:55:59 2004 Subject: [ python-Bugs-1004669 ] Type returned from .keys() is not checked Message-ID: Bugs item #1004669, was opened at 2004-08-06 10:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: ben handley (bhandley) Assigned to: Raymond Hettinger (rhettinger) Summary: Type returned from .keys() is not checked Initial Comment: When passing a mapping object as the locals to eval, it doesn't check that the return value of .keys() is a tuple early enough, resulting in a SystemError: >>> class C: ... def __getitem__(self, item): ... raise KeyError, item ... def keys(self): ... return 'a' ... >>> c=C() >>> print eval('dir()', globals(), c) Traceback (most recent call last): File "", line 1, in ? File "", line 0, in ? SystemError: Objects/listobject.c:2110: bad argument to internal function ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-06 23:55 Message: Logged In: YES user_id=80475 Fixed. See: Objects/object.c 2.220 Lib/ test/test_builtin.py 1.33 Thanks for the clear bug report and diagnosis. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-06 18:43 Message: Logged In: YES user_id=80475 It's a bug. Will fix. ---------------------------------------------------------------------- Comment By: ben handley (bhandley) Date: 2004-08-06 18:05 Message: Logged In: YES user_id=765626 If it raised a TypeError rather than SystemError I would think it fine. I didn't think that python code should be able to cause correct C code to generate `bad argument to internal function'. To me, that sounds like `some C function called some other C function badly', rather than just a bad type from python. In fact I believe that that is exactly what is happening. Here are the final two lines from the backtrace: #0 PyList_Sort (v=0x4029bc20) at Objects/listobject.c:2110 #1 0x0807b659 in PyObject_Dir (arg=0x0) at Objects/object.c:1705 PyList_Sort seems to assume that it will always be passed a list, hence it calls PyErr_BadInternalCall() if it's not. Assuming this is true, either PyObject_Dir or PyMapping_Keys should do the type checking and raise TypeError if it's not a list. Doesn't PyErr_BadInternalCall() mean that someone violated the C API of an internal function, therefore the bug is in C code rather than python? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-06 13:49 Message: Logged In: YES user_id=971153 Why do you think the existing behaviour is wrong? All Python type checking is done at run time E.g. >>> 12+"123" Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand types for +: 'int' and 'str' How is your example different? I would suggest to close the bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004669&group_id=5470 From noreply at sourceforge.net Sat Aug 7 07:42:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 07:42:16 2004 Subject: [ python-Bugs-772091 ] doctest.DocTestSuite does not support __test__ Message-ID: Bugs item #772091, was opened at 2003-07-16 01:04 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772091&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Tim Peters (tim_one) Summary: doctest.DocTestSuite does not support __test__ Initial Comment: The DocTestSuite tool ignores a module level dictionary named __test__. This limits its usefulness for the current python testsuite. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 01:42 Message: Logged In: YES user_id=31435 Thanks for pointing it out! This got fixed by magic as part of the refactoring -- doctest's unittest support used to have its own code for finding things to test, entirely distinct from the test-finding code used by the rest of doctest. Everything uses a new common DocTestFinder class now, so there should be no more differences in what the various wrappers find to test. I added a test to ensure that DocTestSuite does indeed make tests from a __test__ dict (if present). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-06 19:44 Message: Logged In: YES user_id=80475 Perhaps this can be incorporated in your updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772091&group_id=5470 From noreply at sourceforge.net Sat Aug 7 07:55:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 07:55:24 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 08:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) >Assigned to: Nobody/Anonymous (nobody) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-06 00:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 11:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 10:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 10:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 08:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Sat Aug 7 13:10:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 13:10:46 2004 Subject: [ python-Bugs-1005078 ] iso-2022-jp crashes Message-ID: Bugs item #1005078, was opened at 2004-08-07 13:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005078&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Hye-Shik Chang (perky) Summary: iso-2022-jp crashes Initial Comment: I get Python 2.4a2 (#88, Aug 7 2004, 12:37:23) [GCC 3.3.4 (Debian 1:3.3.4-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> u"a\u9808".encode("iso-2022-jp") Segmentation fault The gdb backtrace is #0 0x4047f45f in jisx0208_encoder (data=0x98080061, length=0xbfffde1c) at /home/martin/work/py2.4/Modules/cjkcodecs/_codecs_iso2022.c:632 #1 0x4047e915 in iso2022_encode (state=0xbfffdec8, config=0x40481964, inbuf=0xbfffde60, inleft=2, outbuf=0xbfffde6c, outleft=20, flags=3) at /home/martin/work/py2.4/Modules/cjkcodecs/_codecs_iso2022.c:187 #2 0x404835f9 in multibytecodec_encode (codec=0x40481be4, state=0xbfffdec8, data=0xbfffdec4, datalen=2550661217, errors=0x1, flags=3) at /home/martin/work/py2.4/Modules/cjkcodecs/multibytecodec.c:432 #3 0x40483e24 in MultibyteCodec_Encode (self=0x4029d070, args=0x98080061, kwargs=0x98080061) at /home/martin/work/py2.4/Modules/cjkcodecs/multibytecodec.c:512 #4 0x081041fe in PyCFunction_Call (func=0x402ce24c, arg=0x402ce12c, kw=0x4052a2a0) at Objects/methodobject.c:77 It crashes on line 632: 632 else TRYMAP_ENC(jisxcommon, coded, *data) { because data does not point to valid memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005078&group_id=5470 From noreply at sourceforge.net Sat Aug 7 15:23:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 15:23:59 2004 Subject: [ python-Bugs-1005113 ] test__locale fails on MacOS X Message-ID: Bugs item #1005113, was opened at 2004-08-07 15:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: test__locale fails on MacOS X Initial Comment: test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include #include int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 From noreply at sourceforge.net Sat Aug 7 16:30:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 16:31:00 2004 Subject: [ python-Bugs-1003195 ] segfault when running smtplib example Message-ID: Bugs item #1003195, was opened at 2004-08-04 13:43 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: segfault when running smtplib example Initial Comment: On my system, running the simple smtplib Example from the Documentation results in a segmentation fault. Execution stops and no mail is submitted. I debugged into the Python source code, but my understanding of the inner mechanisms doesn't suffice to fix the problem. I update my system periodically using "apt-get update ; apt-get upgrade". I don't remember, when it was the last time Python was upgraded. I made the files availabe: http://www.bertram-scharpf.de/tmp/smtpex.py.txt http://www.bertram-scharpf.de/tmp/smtpex.desc.txt ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 16:30 Message: Logged In: YES user_id=580910 I cannot reproduce this. I've tested: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Python 2.2.3+ (#1, Jun 20 2004, 13:32:48) [GCC 3.3.4 (Debian)] on linux2 The first is the system python on MacOS X, the other two are current Debian packages (python2.3 and python2.2) on Debian stable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 From noreply at sourceforge.net Sat Aug 7 17:10:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 17:10:05 2004 Subject: [ python-Bugs-1005113 ] test__locale fails on MacOS X Message-ID: Bugs item #1005113, was opened at 2004-08-07 15:23 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: test__locale fails on MacOS X Initial Comment: test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include #include int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks.... ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 17:10 Message: Logged In: YES user_id=580910 Because this seems to be a bug in OSX I've filed a bug at bugreport.apple.com (radar#3754835) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 From noreply at sourceforge.net Sat Aug 7 17:12:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 17:12:26 2004 Subject: [ python-Bugs-998307 ] replace file() with open() in libcvs.tex Message-ID: Bugs item #998307, was opened at 2004-07-26 17:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998307&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Fedor Baart (siggyf) >Assigned to: A.M. Kuchling (akuchling) Summary: replace file() with open() in libcvs.tex Initial Comment: It was suggested by BDFL that open() should be prefered above file(). The libcsv.tex documentation uses file() to open files instead of open(). For the cause of consistency they should be changed to open(). See lines 317,326 and 335. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 11:12 Message: Logged In: YES user_id=11375 Fixed; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998307&group_id=5470 From noreply at sourceforge.net Sat Aug 7 17:28:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 17:29:02 2004 Subject: [ python-Bugs-1004271 ] imaplib.IMAP4.select doesn't return critical data Message-ID: Bugs item #1004271, was opened at 2004-08-06 00:53 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004271&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) >Assigned to: Piers Lauder (pierslauder) Summary: imaplib.IMAP4.select doesn't return critical data Initial Comment: The .select() method of IMAP4 objects returns the EXISTS data, but not the more-critical UIDVALIDITY data. Without UIDVALIDITY, the UID command is useless. I have a patch, but it changes the API of the .select() method, so it's unlikely to go into mainline -- and select() also fails to return two other data items from the SELECT command (FLAGS and RECENT). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004271&group_id=5470 From noreply at sourceforge.net Sat Aug 7 17:39:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 17:39:36 2004 Subject: [ python-Bugs-1002475 ] email message parser doesn't handle \r\n correctly Message-ID: Bugs item #1002475, was opened at 2004-08-03 04:32 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email message parser doesn't handle \r\n correctly Initial Comment: Header lines that end in \r\n only get the \n stripped, not the \r (unless it's the last header which does get the \r stripped): >>> import email.Parser >>> m = 'Header: text\r\nNext-Header: more text\r\n\r\nBody\r\n\r\n' >>> msg = email.Parser.Parser().parsestr(m) >>> msg.get('header') 'text\r' >>> msg.get('next-header') 'more text' >>> This bug showed itself in my SpamBayes setup using sb_imapfilter.py where base64-encoded text/html messages were not decoded in Message.get_payload because the call to get('content-transfer-encoding') returned the string 'base64\r' instead of 'base64'. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-06 02:40 Message: Logged In: YES user_id=43607 The patch seems to work well. +1 for checking it in. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-08-04 21:28 Message: Logged In: YES user_id=552329 A patch to fix this is in: [ 1003693 ] Fix for 1002475 (Feedparser not handling \r\n correctly) http://sourceforge.net/tracker/index.php?func=detail&aid=1003693&group_id=5470&atid=305470 I'll try to write a test for it, too, and also attach that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 From noreply at sourceforge.net Sat Aug 7 17:42:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 17:42:56 2004 Subject: [ python-Bugs-1004698 ] Int Type Documentation incomplete Message-ID: Bugs item #1004698, was opened at 2004-08-06 17:01 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Int Type Documentation incomplete Initial Comment: __new__ and __newargs__ don't appear to be documented c.mro() seems to show a circular definition. Please see the examples below: >>> c >>> c.mro() [, ] >>> c.__getnewargs__() >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: descriptor '__getnewargs__' of 'int' object needs an argument >>> c.__getnewargs__(21) (21,) >>> c= 1+1j >>> c (1+1j) >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: __getnewargs__() takes no arguments (1 given) >>> c.__getnewargs__() ((1+1j),) >>> c.__new__ >>> c.__new__(ComplexType) 0j >>> Colin W. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 16:42 Message: Logged In: YES user_id=6656 It's hard to make out which specific bug you are reporting, or even if you are reporting a specific bug. Can you please clarify? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 From noreply at sourceforge.net Sat Aug 7 17:48:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 17:49:03 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-31 00:08 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-08-07 15:48 Message: Logged In: YES user_id=7887 If this was considered a bug: >>> type(ms("a")+ms("b")) >>> type(ms("a")[:]) Are these bugs as well? I belive this is how the implementation was intended to be, even if not optimal for subclasses. I suggest closing this bug as invalid, and writing a PEP about the possible new subclass support change (for all classes), if there's enough interest. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-05 16:10 Message: Logged In: YES user_id=593130 Duh, my turn to forget. For any beginners reading this ... >>> class ms(str): pass ... >>> a=ms('a') >>> type(''.join((a,))) Expanding mhw's second point: >>> e=ms() >>> type(e) >>> import copy >>> e2=copy.copy(e) >>> type(e2) >>> e3=e[:] >>> type(e3) >>> id(e),id(e2),id(e3) (9494608, 9009936, 8577440) so [:] is not exactly an abbreviated synonym for copy(). Is this a butg? (I haven't rechecked the respective docs yet.) One reason I hesitate to call the OP's original observation a bug is that the whole sujbect of operations on subtype instances seems not completely baked. Knowing the result types in all cases may require experiments as well as doc reading. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 12:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-04 20:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 19:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 14:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Sat Aug 7 17:55:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 17:55:17 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability Message-ID: Bugs item #1003471, was opened at 2004-08-04 19:42 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 16:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sat Aug 7 17:58:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 17:58:51 2004 Subject: [ python-Bugs-1002475 ] email message parser doesn't handle \r\n correctly Message-ID: Bugs item #1002475, was opened at 2004-08-03 04:32 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email message parser doesn't handle \r\n correctly Initial Comment: Header lines that end in \r\n only get the \n stripped, not the \r (unless it's the last header which does get the \r stripped): >>> import email.Parser >>> m = 'Header: text\r\nNext-Header: more text\r\n\r\nBody\r\n\r\n' >>> msg = email.Parser.Parser().parsestr(m) >>> msg.get('header') 'text\r' >>> msg.get('next-header') 'more text' >>> This bug showed itself in my SpamBayes setup using sb_imapfilter.py where base64-encoded text/html messages were not decoded in Message.get_payload because the call to get('content-transfer-encoding') returned the string 'base64\r' instead of 'base64'. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-08-07 11:58 Message: Logged In: YES user_id=12800 Patch looks good to me. Accepted and checked in. test_email.py 1.59 FeedParser.py 1.9 ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-08-06 02:40 Message: Logged In: YES user_id=43607 The patch seems to work well. +1 for checking it in. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-08-04 21:28 Message: Logged In: YES user_id=552329 A patch to fix this is in: [ 1003693 ] Fix for 1002475 (Feedparser not handling \r\n correctly) http://sourceforge.net/tracker/index.php?func=detail&aid=1003693&group_id=5470&atid=305470 I'll try to write a test for it, too, and also attach that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002475&group_id=5470 From noreply at sourceforge.net Sat Aug 7 18:14:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 18:14:59 2004 Subject: [ python-Bugs-1000914 ] Carbon.CF.CFMutableArray hangs interpreter Message-ID: Bugs item #1000914, was opened at 2004-07-30 22:18 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.CF.CFMutableArray hangs interpreter Initial Comment: $ /opt/python2.4/bin/python Python 2.4a1+ (#1, Jul 30 2004, 20:22:17) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from Carbon.CF import * >>> c = CFArrayCreateMutable(0) >>> isinstance(c, CFMutableArrayRef) True >>> del c The interpreter hangs after deleting c. This also happens when the call to isinstance is left out. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 18:14 Message: Logged In: YES user_id=580910 It's infinite recursion... - CF.CFMutableArrayRef has is a subtype of CF.CFArrayRef - Both tp_del's call 'self->ob_type->tp_base->tp_dealloc' to deallocate the instance. - When the instance is an CFMutableArrayRef self->ob_type->tp_base is CFArrayRef, which means we get: 1. Object refcount is 0, call tp_dealloc 2. Enter CFMutableArrayRefObj_dealloc 3. Call self->ob_type->tp_dealloc 4. Enter CFArrayRefObj_dealloc 5. Call self->ob_type->tp_dealloc 6. Enter CFArrayRefObj_dealloc 7. ... I guess the right change is in Tools/bgen/bgen/bgenObjectDefinition.py: outputDealloc. Near line 138 this prints the problematic 'self->ob_type->tp_base- >tp_dealloc'. I'd change this to: Output("%s.tp_dealloc((PyObject*)self);"%(self.basetype,)) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-07-30 22:27 Message: Logged In: YES user_id=580910 when I use gdb to check where the program hangs I always end up in CFArrayRefObj_dealloc. This also happens when I continue to program and break again later on. It doesn't seem to be infinite recursion, the stack is 8 levels deep with the code mentioned earlier. However: (gdb) where #0 0x00551f98 in CFArrayRefObj_dealloc (self=0x37f0e0) at /Volumes/ Data/Users/ronald/Software/python-HEAD/dist/src/Mac/Modules/cf/ _CFmodule.c:525 #1 0x0008879c in PyEval_EvalFrame (f=0x60d820) at Python/ceval.c: 1662 #2 0x0008a4bc in PyEval_EvalCodeEx (co=0x2, globals=0x59e54, locals=0x552308, args=0x16c, argcount=6312944, kws=0x874a0, kwcount=1, defs=0x60d96c, defcount=0, closure=0x0) at Python/ ceval.c:2697 #3 0x0008d648 in PyEval_EvalCode (co=0x37f0e0, globals=0x59e54, locals=0x55e1d4) at Python/ceval.c:448 #4 0x0000c9a0 in run_node (n=0x16c, filename=0x59e54 "\201^", globals=0x2, locals=0x60d96c, flags=0x0) at Python/pythonrun.c:1255 #5 0x0000c128 in PyRun_SimpleFileExFlags (fp=0xa0009818, filename=0xbffffc9e "t.py", closeit=6346784, flags=0x377a92) at Python/ pythonrun.c:850 #6 0x00006328 in Py_Main (argc=3533392, argv=0xbffffc9e) at Modules/main.c:413 #7 0x00001ee4 in _start (argc=3533392, argv=0xa0009818, envp=0xbffffc9e) at /SourceCache/Csu/Csu-46/crt.c:267 #8 0x00001d58 in start () (gdb) p self $3 = (CFArrayRefObject *) 0x37f0e0 (gdb) p *self $4 = { ob_refcnt = 0, ob_type = 0x55e2e4, ob_itself = 0x0, ob_freeit = 0x90190b98 } (gdb) p self->ob_type->tp_base $5 = (struct _typeobject *) 0x55e1d4 (gdb) p self->ob_type->tp_base->tp_dealloc $6 = 0x551f48 (gdb) And CFArrayRefObj_dealloc is: static void CFArrayRefObj_dealloc(CFArrayRefObject *self) { if (self->ob_freeit && self->ob_itself) { self->ob_freeit((CFTypeRef)self->ob_itself); self->ob_itself = NULL; } self->ob_type->tp_base->tp_dealloc((PyObject *)self); } BTW: Python 2.4a1+ from anon-CVS as of today, running on OSX 10.3.4 with Xcode 1.2 (gcc 3.3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470 From noreply at sourceforge.net Sat Aug 7 18:25:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 18:25:52 2004 Subject: [ python-Bugs-984952 ] PEP 307 pickle extensions not documented Message-ID: Bugs item #984952, was opened at 2004-07-04 11:45 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984952&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 307 pickle extensions not documented Initial Comment: >From a quick perusal of the developer documentation (from www.python.org), it appears that PEP 307 has not yet been integrated into the standard documentation. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 12:25 Message: Logged In: YES user_id=11375 I've included a bunch of material from PEP 307 in the CVS HEAD version of the pickle docs. I haven't tried to include all the material on old-style classes using protocols 0,1. The details are lengthy; someone who knows more about the pickle module should decide if they're important enough to be in the docs or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=984952&group_id=5470 From noreply at sourceforge.net Sat Aug 7 18:28:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 18:28:53 2004 Subject: [ python-Bugs-874842 ] httplib fails on Akamai URLs Message-ID: Bugs item #874842, was opened at 2004-01-11 11:16 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874842&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Leif Hedstrom (zwoop) Assigned to: Jeremy Hylton (jhylton) Summary: httplib fails on Akamai URLs Initial Comment: Using Python 2.3.2 and httplib, reading from Akamai URLs will always hang at the end of the transacation. As common as this must be, I couldn't find anything related to it on any search engines, nor on the bug list here. The problem is that Akamai returns an HTTP/1.0 response, with a header like: Connection: keep-alive httplib does not recognize this response properly (the Connection: header parsing is only done for HTTP/1.1 responses). I'm not sure exactly what the right solution is, but I'm supplying one alternative solution that does solve the problem. I'm attaching a diff against httplib.py. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-05-14 00:29 Message: Logged In: YES user_id=6380 Looks like nothing happened in CVS... :-( It's too late for 2.3.4 now, Anthony issued the release candidate already. There will be a 2.3.5 though. ---------------------------------------------------------------------- Comment By: Leif Hedstrom (zwoop) Date: 2004-05-13 17:15 Message: Logged In: YES user_id=480913 Hate to beat on a dead horse here, but what was the final outcome of this discussion? Anything I can do to help produce a better patch, documentation or anything? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-04-20 16:53 Message: Logged In: YES user_id=6380 It's great that the ASF can wield such power over the likes of AOL. But I don't want to presume the same for Python (we're not the #1 web language, not even #2). I'd be more concerned if adding this hack would *break* anything, but that doesn't seem to be the case. So I still think Jeremy can check it in. ---------------------------------------------------------------------- Comment By: Leif Hedstrom (zwoop) Date: 2004-04-20 15:36 Message: Logged In: YES user_id=480913 Yeah, the second solution is what I ended up doing, although it's definitely not obvious for anyone using httplib.py that this is required to support Akamai (see my original blog post at http://www.ogre.com/tiki-view_blog_post.php?blogId=3&postId=30 for both alternative solutions). At a minimum, I think we should provide the AkamaiHTTPResponse class in one way or another, and clearly document that this is required for correct support of Akamai URLs. My vote would probably be to "hack" the original HTTPResponse class, since anyone using HTTPlib for anything that might hit Akamai (perhaps as a referral/redirect) will have to use the fixed version anyways. Unfortunately I don't have any contacts left at Akamai, so I'm not sure how to inform them of their problems. I completely agree that we need to inform them about this problem, my point was that since Akamai works with pretty much everything else (browsers, other modules etc.), I think it'll be quite slow to get them to change. And until then, we're stuck with a module that is effectively semi-broken. Thanks, -- Leif ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2004-04-20 06:44 Message: Logged In: YES user_id=6501 Falling into line with "oh, but they won't change it" is why we end up with a whole bunch of bad implementations. If everybody said that, then we wouldn't get anywhere. A long while back, AOL came out with a busted proxy implementation which didn't work with Apache servers. The ASF said, "sorry AOL: you're wrong. fix your proxies." And they did. If we put a hack in for every busted thing that came out over the next ten years, then imagine the craphole we'd be in... :-) That said: yes, you can workaround the issue with a subclass of HTTPResponse which overrides the _check_close() method. You can then create an HTTPConnection subclass which overrides the class variable 'response_class', or you can set that field in an HTTPConnection instance as an instance variable. For example: conn = HTTPConnection(...) conn.response_class = AkamaiBugHandler When the response arrives, the HTTPConnection class uses self.response_class, so there are a few options to get your custom response class into the chain of events. ---------------------------------------------------------------------- Comment By: Leif Hedstrom (zwoop) Date: 2004-04-20 00:57 Message: Logged In: YES user_id=480913 As I said, no matter what we do, it's a hack on something that's broken on the web (now there's a shocker :-). I don't feel terribly strongly on this issue, I merely filed the bug report because I had this problem, and it took me several hours to figure out why my daemon would stall on Akamai URLs. I'm guessing other users of httplib.py might run into the same problem. As for the patch, the comments would of course have to change, I didn't want to impose more changes in the diff than necessary. Besides the suggested patch, an alternative solution is to provide a specialized implementation of the HTTPResponse class, which works with Akamai. The users of the httplib.py module would then have to explicitly request that httplib.HTTPConnection should instantiate that class instead of the default one. Preferably this would be passed as a new argument to the constructor for HTTPConnection. And I agree that it's a hack to have to code around poor server implementations. But not sure what our odds are to get Akamai to fix their servers any time soon, since pretty much any web browser in existance works with their broken implementation. Cheers, -- leif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-04-19 22:32 Message: Logged In: YES user_id=6380 I won't reject the patch on that basis. Like HTML, it's more useful to be able to handle what we see in the real world than to stick to the standard. Clearly the OP needs to be able to access Akamai servers. He doesn't have the power to fix the Akamai servers,so saying "the server is wrong" doesn't do him any good. (The comment should stateclearly that Akamai *is* wrong though!) Or do you have a different suggestion for how the poster can work around the problem? ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2004-04-19 22:26 Message: Logged In: YES user_id=6501 I have a philosophical problem with compensating for servers that obviously break protocols. The server should be fixed, not *every* client on the planet. From that standpoint, this problem/fix should be rejected, though I defer to Guido on that choice. That said, the comment right above the patch should be fixed. The whole point of that comment is, "the header shouldn't be there, so we shouldn't bother to examine the thing." Obviously, the new code does, so the two comments should be merged. The comment about Akamai should also be strengthened to note that it is violating the HTTP protocol (see section 8.1.2.1 of RFC 2616). Summary: I'd reject it, but will leave that to Guido to choose (i.e. "we'll help users even tho it violates protocols"). If he wants it, then +1 if the comments are fixed up. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-04-15 21:59 Message: Logged In: YES user_id=31392 Looks good to me. I want to see if I can come up with a simple test module for httplib with the network resource enabled. I'll see if I can do that tonight. ---------------------------------------------------------------------- Comment By: Leif Hedstrom (zwoop) Date: 2004-04-12 20:54 Message: Logged In: YES user_id=480913 Heh, yeah, I'm pretty sure that's the problem, Akamai being confused about protocols. They claim to be a v1.0 HTTP proxy, yet they use v1.1 HTTP headers :-/. This is why I mentioned I wasn't sure exactly what the right solution is. And no matter what we do, it'll be a hack. Maybe the original author of the module has some insight ? Unfortunately, there's a lot of Akamai content out there that are affected by this. Cheers, -- Leif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-04-12 20:32 Message: Logged In: YES user_id=6380 Hmm... Indeed. read() checks will_close and apparently setting that to False will do the right thing. I don't know HTTP and this code well enough to approve this fix though. Also, the comment right above your patch should probably be fixed; it claims that connection headers on HTTP/1.0 are due to confused proxies. (Maybe that's what Akamai servers are? :-) ---------------------------------------------------------------------- Comment By: Leif Hedstrom (zwoop) Date: 2004-04-12 20:13 Message: Logged In: YES user_id=480913 Yeah, that works for me to. But the problem is in the HTTPResponse class from the httplib.py module. For example, this code (butchered from my application) will hang on Akamai URLs: #!/usr/bin/python import httplib def testHTTPlib(host, url): http = httplib.HTTPConnection(host) try: http.request('GET', url) response = http.getresponse() except IOError: self._log.warning("Can't connect to %s", url) return False except socket.error: self._log.error("Socket error retrieving %s", url) return False except socket.timeout: self._log.warning("Timeout connecting to %s", url) return False else: try: data = response.read() return True except socket.timeout: self._log.warning("Timeout reading from %s", url) return False return False print testHTTPlib("www.ogre.com", "/") print testHTTPlib("www.akamai.com", "/") Granted, I think Akamai aren't strictly following the protocols, but it's inconvenient that this piece of code stalls here (and only for akamai.com domains, I've tried a lot of them). Thanks! -- Leif ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-04-12 19:36 Message: Logged In: YES user_id=6380 Can you give a complete program that reproduces this? I've tried this: >>> import urllib >>> urllib.urlopen("http://www.akamai.com").read() and it doesn't hang for me. I tried a number of Python versions from 2.2 through 2.4a0. ---------------------------------------------------------------------- Comment By: Leif Hedstrom (zwoop) Date: 2004-01-11 19:37 Message: Logged In: YES user_id=480913 Oh, I forgot, this is easiest reproduced by simple requesting the URL http://www.akamai.com/ Fortunately they Akamai their home page as well. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874842&group_id=5470 From noreply at sourceforge.net Sat Aug 7 18:29:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 18:29:05 2004 Subject: [ python-Bugs-1003323 ] telnetlib on Windows: read_until() freezes Message-ID: Bugs item #1003323, was opened at 2004-08-04 15:45 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003323&group_id=5470 Category: Python Library >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Yannick Turgeon (yturgeon) >Assigned to: Michael Hudson (mwh) Summary: telnetlib on Windows: read_until() freezes Initial Comment: I'm currently trying to pass commands to a telnet session and get the texte generated (stdin + stdout) by the session. The problem I get is that the Telnet.read_until() function seems to freeze after a couple of command. I did a simplified script (attached) that reproduce the problem each time. In the script, when I send the command "echo bar7" to the telnet session, it freezes forever without a Timeout. I'm using 2.3.4 on Windows 2000 Server. According to a feedback for the comp.lang.python newsgroup, this problem do not occur on linux systems. Thanks Yannick yannick.turgeon@cablevision.qc.ca ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 17:29 Message: Logged In: YES user_id=6656 OK! ---------------------------------------------------------------------- Comment By: Yannick Turgeon (yturgeon) Date: 2004-08-06 22:09 Message: Logged In: YES user_id=280297 Forget this bug. In fact it's not a bug. The problem comes from the fact that Microsoft does not use a *real* telnet server. It's documented in Perl Net::Telnet doc. They are not fully respecting telnet protocol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003323&group_id=5470 From noreply at sourceforge.net Sat Aug 7 18:29:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 18:29:07 2004 Subject: [ python-Bugs-1003323 ] telnetlib on Windows: read_until() freezes Message-ID: Bugs item #1003323, was opened at 2004-08-04 10:45 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003323&group_id=5470 Category: Python Library >Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Yannick Turgeon (yturgeon) >Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib on Windows: read_until() freezes Initial Comment: I'm currently trying to pass commands to a telnet session and get the texte generated (stdin + stdout) by the session. The problem I get is that the Telnet.read_until() function seems to freeze after a couple of command. I did a simplified script (attached) that reproduce the problem each time. In the script, when I send the command "echo bar7" to the telnet session, it freezes forever without a Timeout. I'm using 2.3.4 on Windows 2000 Server. According to a feedback for the comp.lang.python newsgroup, this problem do not occur on linux systems. Thanks Yannick yannick.turgeon@cablevision.qc.ca ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 12:29 Message: Logged In: YES user_id=11375 Closing as requested. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 12:29 Message: Logged In: YES user_id=6656 OK! ---------------------------------------------------------------------- Comment By: Yannick Turgeon (yturgeon) Date: 2004-08-06 17:09 Message: Logged In: YES user_id=280297 Forget this bug. In fact it's not a bug. The problem comes from the fact that Microsoft does not use a *real* telnet server. It's documented in Perl Net::Telnet doc. They are not fully respecting telnet protocol. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003323&group_id=5470 From noreply at sourceforge.net Sat Aug 7 18:38:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 18:38:33 2004 Subject: [ python-Bugs-997368 ] strftime() backwards incompatibility Message-ID: Bugs item #997368, was opened at 2004-07-24 23:59 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jp Calderone (kuran) Assigned to: Barry A. Warsaw (bwarsaw) Summary: strftime() backwards incompatibility Initial Comment: time.strftime() in 2.4a0 places more restrictions on its inputs than does the version in 2.3.x. Revision 2.140 seems to be where this was introduced. I believe it is a common use of strftime() to fill out only some fields of the time tuple. Requiring the day of year and day of week is particularly burdensome. Here is an example that triggers the changed behavior: import time now = time.gmtime() now = now[:-3] + (0, 0, 0) print time.strftime("", now) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-08-07 12:38 Message: Logged In: YES user_id=12800 The patch isn't quite right, since 0 is only illegal in the yday position - the wday and isdst positions should continue to return 0. Also, your patch didn't include a fix to test_rfc822.py But I'll fix those and commit the changes. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-08-06 17:03 Message: Logged In: YES user_id=366566 0s and 1s reversed in previous post. Correct in patch, though. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-08-05 12:10 Message: Logged In: YES user_id=366566 Diff to update _parseaddr and rfc822 modules to use 0 instead of 1 for values it does not compute. Test module also updated (it explicitly compared to 0, now it explicitly compares to 1). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-27 18:58 Message: Logged In: YES user_id=764593 For me, Day-of-week and day-of-year are typically there because the format was decided externally; I don't track them in my application. I've seen databases with timestamps that all end in "000". I would be happy to have "None" replaced by a default value; it is just that the result should be consistent with what I did pass. For example, I wouldn't want to pass year/month/day and discover that every single day is Monday, or to pass year/ day-of-year and discover that day 345 is still in January. -jJ ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-27 18:41 Message: Logged In: YES user_id=357491 I could live with the None option but not the short tuple option. The former is explicitly not a number and nothing returns that for time tuples to my knowledge. The latter, though, might mask bugs in code when you accidentally truncated your tuple too much. And yes, other values can be computed from other fields (strptime has the code for some slots and I think datetime can do some as well). But why waste the overhead? While strptime has to care since you are getting a time tuple and thus it can't guess what fields you care about, strftime shouldn't need to care since it is assumed that you are passing in as much info as needed for the format directive to have what it needs. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-07-27 11:01 Message: Logged In: YES user_id=764593 What about a python wrapper to the C function that accepted either short tuples or None in trailing (or any?) positions and automatically filled in a default value. Some can be computed from other fields; if not, the same defaults used in strptime seem as reasonable as any. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-26 20:53 Message: Logged In: YES user_id=357491 =) No need to presume; I know better. Writing strftime in Python would be rather difficult since there is no other consistent way to get at all of that locale info. Yes, you could use the locale module, but even that is iffy at times on some platforms. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-26 11:30 Message: Logged In: YES user_id=31435 Ah, that's a bug in rfc822.parsedate_tz(), with a copy+paste duplicate bug in email._parseaddr.parsedate_tz(). Assigning this report to Barry hoping he'll fix those, and boosted the priority: Barry, 0 is an illegal value for tm_yday in a Python time tuple. Python 2.4 cares about this. You want 1 there instead. I'd do it, but am not familiar with the test suites for those modules. C99's strftime is a large and complicated function, so it would take a peculiar kind of masochism for someone to want to rewrite it in Python. Brett did the Python strptime, but he's older now, and has presumably learned better . ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2004-07-26 01:25 Message: Logged In: YES user_id=366566 The more I think about it the more I want to suggest that strftime just be implemented in Python so that garbage values that are never required can be accepted, safe in the knowledge that they won't be used by the implementation. I'm not sure how feasible this is. I know strptime is now provided by Python and not the underlying library, so it seems at least in the ballpark of plausibility. On the other hand, looking more closely at what my requirements really are, it seems that the input to strftime() is actually coming from rfc822.parsedate_tz(), which builds up a tuple containing all the interesting values, and uses 0s for the nonsense ones. Would a patch for parsedate_tz() (and similarly behaving functions, I suppose, though I can't think of any off the top of my head) to generate values acceptable to strftime() be more acceptable? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-07-26 00:45 Message: Logged In: YES user_id=31435 JP, can you define which nonsense values "are needed"? We can't go back to allowing garbage everywhere, because doing so did cause crashes in platform C libraries. The only thing it complains about in the specific example you gave is the middle 0. I agree that one is irritating, and is due to Python inexplicably saying that tm_yday must be in 1 .. 366 (instead of C's 0 .. 365) -- so Python subtracts one from the middle 0, giving a -1 that we can't afford to pass on to the C library. If the only thing you really need is to allow a 0 for tm_yday, perhaps that could be allowed without whining. 0 is fine for tm_wday already, and for tm_isdst. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-25 22:39 Message: Logged In: YES user_id=357491 This was brought up on python-dev in the thread http://mail.python.org/ pipermail/python-dev/2004-July/046418.html . This was all originally discussed back in Feb 2004: http://mail.python.org/pipermail/python- dev/2004-February/042675.html . The current solution was discussed on python-dev and agreed upon. Because using values that are outside of basic boundaries can lead to core dumps (mostly thanks to strftime() implementations that do not check boundary values when indexing into arrays) a check to make sure all values are within sane values, but *without* checking whether they are valid values when compared to each other, was added. The docs do say that "ValueError raised if a field in [tuple] t is out of range". Personally I say close this as won't fix. python-dev came to the conclusion collectively that breaking possible code that played loosely with the passed-in values was better than allowing possible core dumps. A very compelling reason that got multiple support from othe developers would be needed, in my opinion, to overturn this change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997368&group_id=5470 From noreply at sourceforge.net Sat Aug 7 18:43:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 18:43:48 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability Message-ID: Bugs item #1003471, was opened at 2004-08-04 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sat Aug 7 18:54:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 18:54:25 2004 Subject: [ python-Bugs-873146 ] pickletools module is not documented Message-ID: Bugs item #873146, was opened at 2004-01-08 10:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=873146&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: A.M. Kuchling (akuchling) Summary: pickletools module is not documented Initial Comment: LaTeX documentation for the pickletools module should be written. The docstrings are extensive, so it shouldn't be difficult. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 12:54 Message: Logged In: YES user_id=11375 documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=873146&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:08:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:08:21 2004 Subject: [ python-Bugs-1002465 ] MemoryError on AIX52 Message-ID: Bugs item #1002465, was opened at 2004-08-03 09:04 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: Datranet (richardjmason) Assigned to: Nobody/Anonymous (nobody) Summary: MemoryError on AIX52 Initial Comment: I found the orginal problem when trying to send large email attachments on AIX 5.2. I tracked the issue down to the fact that a string can only grow to a very restricted size on AIX 5.2. bin2ascii fails at the pint the function tries to join the list togther to form 1 string. I wrote the following test program to prove the issue: a = '' cnt = 0 while cnt < 1024: a = a + 'x' cnt += 1 c = '' cnt = 0 while cnt < 1024: c = c + a cnt += 1 b = '' cnt2 = 0 while 1: b = b + c cnt2 += 1 print cnt2 On AIX 5.2 you get a MemoryError with a cnt2 value of 42. I can run the test program on all other platforms and get a cnt2 value over 150 before stopping to program myself. I have tried the binary python 2.2 from the IBM site and building python 2.3.4 myself using the gcc from the IBM site. Both fail with a cnt2 value of 42. Can anyone please advise on how to get AIX 5.2 to allow single objects to have more memory allocated. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 12:59 Message: Logged In: YES user_id=6656 A way this has happened in the past is calling "malloc(0)", which is entitled to return NULL and Python then thinks this is a memory error. This doesn't seeme especially likely here, though. Agree with Martin that you're probably going to need to use a debugger. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-04 19:09 Message: Logged In: YES user_id=21627 You need to use a debugger to find the cause of the problem. What is the string parameter of the MemoryError? This might give a clue where precisely it is raised. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:20:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:20:41 2004 Subject: [ python-Bugs-905046 ] test_tcl fails -- Message-ID: Bugs item #905046, was opened at 2004-02-26 13:11 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905046&group_id=5470 Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: David Ascher (david_ascher) Summary: test_tcl fails -- Initial Comment: As summary, really. Fairly stock Redhat 9 install, CVS as of a few minutes back. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 18:20 Message: Logged In: YES user_id=6656 It works now. Don't remember seeing loewis' nag, sorry for leaving this sitting for so long. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-29 23:29 Message: Logged In: YES user_id=21627 mwh, does that still fail? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905046&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:19:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:22:28 2004 Subject: [ python-Bugs-996259 ] readline function pointer with not tty's Message-ID: Bugs item #996259, was opened at 2004-07-23 00:44 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996259&group_id=5470 Category: Parser/Compiler Group: Feature Request >Status: Closed >Resolution: Duplicate Priority: 1 Submitted By: Lisandro Dalcin (dalcinl) Assigned to: Nobody/Anonymous (nobody) Summary: readline function pointer with not tty's Initial Comment: In Python 2.3.x C/C++ API, the souce file Parser/myreadline.c in function PyOS_Readline() says: /* This is needed to handle the unlikely case that the * interpreter is in interactive mode *and* stdin/out are not * a tty. This can happen, for example if python is run like * this: python -i < test1.py */ if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout))) rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt); else */ rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout, prompt); When sys_stdin or sys_stdout are not a tty, there is not way of calling the readline function pointer. I am working in a parallelized version of the Python interpreter, and I used the pointer to implement a specialized version of the readline function: it reads input in 'root' process (using the original readline function) and broadcasts string data to slaves. Some MPI implementations (i.e. MPICH) don seems to have stdin and stdout connected to a tty in processes other than the 'master' or 'root' one, being impossible to me to override the input mechanism. My workaround was patching the sources, eliminating the if/else lines.. There is another way of handling the cases like $ python -i < test1.py ???? Am I forgetting something? Thanks in advance.... ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 18:19 Message: Logged In: YES user_id=6656 I believe this is the same issue as patch 955928, which I'm still thinking about. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-07-30 00:55 Message: Logged In: YES user_id=593130 Are you reporting a bug you think the developers should fix, a patch you think they should apply, or merely asking for info? If the latter, please close this and ask elsewhere, such as comp.lang.python or maybe even the developer list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=996259&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:22:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:22:35 2004 Subject: [ python-Bugs-923315 ] AIX POLLNVAL definition causes problems Message-ID: Bugs item #923315, was opened at 2004-03-25 13:06 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923315&group_id=5470 Category: Python Library >Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Marshall (john_marshall) Assigned to: A.M. Kuchling (akuchling) Summary: AIX POLLNVAL definition causes problems Initial Comment: Under AIX (5.1 at least), POLLNVAL (from sys/poll.h) is 0x8000. This causes a problem because it is stored in a (signed) short (e.g., revents): ----- struct pollfd { int fd; /* file descriptor or file ptr */ short events; /* requested events */ short revents; /* returned events */ }; ----- As such, the following tests and results are given: ----- ashort (%hx) = 8000, ashort (%x) = ffff8000 POLLNVAL (%hx) = 8000, POLLNVAL (%x) = 8000 ashort == POLLNVAL => 0 ashort == (short)POLLNVAL => 1 ----- Note that the 'ashort == POLLNVAL' test is 0 rather than 1 because (I believe) POLLNVAL is treated as a signed integer, the ashort value is then promoted to signed integer thus giving 0xffff8000, not 0x8000. The problem arises because IBM has chosen to use a negative short value (0x8000) in a signed short variable. Neither Linux or IRIX have this problem because they use POLLNVAL=0x20 which promotes to 0x20. This situation will cause the test_poll to fail and will certainly be a gotcha for AIX users. I have added the following code to the selectmodule.c to address the problem (mask out the upper 32 bits): -----~ line 513:selectmodule.c num = PyInt_FromLong(self->ufds[i].revents & 0xffff); ----- John ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 13:22 Message: Logged In: YES user_id=11375 Applied to 2.4 HEAD; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923315&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:29:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:29:22 2004 Subject: [ python-Bugs-998066 ] typo in os.popen4 documentation Message-ID: Bugs item #998066, was opened at 2004-07-26 10:04 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998066&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Eric Chen (chen23) >Assigned to: A.M. Kuchling (akuchling) Summary: typo in os.popen4 documentation Initial Comment: on the page: http://www.python.org/doc/2.3.4/lib/module-popen2.html it lists os.popen4 return as: Returns the file objects (child_stdout_and_stderr, child_stdin) in practice it would appear to be (Solaris): Returns the file objects (child_stdin,child_stdout_and_stderr) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 13:29 Message: Logged In: YES user_id=11375 I've added a note to the popen2 docs about this. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-07-29 20:39 Message: Logged In: YES user_id=593130 You (understandably) confused two nearly identical but different functions with two different return conventions (reversed from each other). >>> from os import popen4 >>> popen4 >>> popen2.popen4 Module-popen2.html talks about popen2.popen4 and not os.popen4. Module popen2 has 3 functions popen2/3/4 which consistently return the read and write pipes in that order (well, popen3 is more complicated, but never mind). The os module also has functions of the same name but with reversed return order -- in/out -- as documented: "This functionality is also available in the popen2 module using functions of the same names, but the return values of those functions have a different order." Why ther reversal? No idea. The same hint/warning currently does NOT appear in the popen2 doc nor in its doc string (as accessed via help()) and I agree it should be. Suggestion to doc fixer: in Lib Ref 6.8 popen2, end of 4th paragraph, ending in " or the equivalent functions in the os module." -- Add "(with reversed return tuples)" before the period. Without this caveat, they are not really equivalent, as Chen tripped over. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=998066&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:41:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:41:42 2004 Subject: [ python-Bugs-1000841 ] "make pdf" failure w/ 2.4 docs Message-ID: Bugs item #1000841, was opened at 2004-07-30 19:01 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mat Martineau (martineau) Assigned to: Nobody/Anonymous (nobody) Summary: "make pdf" failure w/ 2.4 docs Initial Comment: When attempting to build the pdf version of the documentation from CVS, I get the following error: (/.../python/dist/src/Doc/lib/libxmlrpclib.tex ... ! TeX capacity exceeded, sorry [input stack size=1500]. \font@name -> \OT1/phv/m/n/10 l.259 ...//www.xmlrpc.com/discuss/msgReader\208} , an approach ! ==> Fatal error occurred, the output PDF file is not finished! The '$' in line 259 of libxmlrpclib.tex seems to trip up pdflatex. If '%24' is substituted for '$', the link still works, and lib.pdf will build. Info about my version of pdflatex & linux: $ pdflatex --version pdfTeX (Web2C 7.4.5) 3.14159-1.10b kpathsea version 3.4.5 ... $ cat /proc/version Linux version 2.6.5-7.95-default (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 Thu Jul 1 15:23:45 UTC 2004 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 18:41 Message: Logged In: YES user_id=6656 Confirmed, and fixed in the suggested way in Doc/lib/ libxmlrpclib.tex revision 1.17. "make pdf" still chokes, but on dist now. Haven't had a look to see why. aisaac0: you should *really* file another bug for that. ---------------------------------------------------------------------- Comment By: Alan (aisaac0) Date: 2004-07-31 16:02 Message: Logged In: YES user_id=1025672 Hopefully a bug from the 2.3 docs can be fixed at the same time. The PDF production tries to set the vertical bar '|' in textmode rather than math mode. An example of this problem is the documentation for set union, which looks like s--t instead of s|t. Should I submit this as a separate bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:42:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:46:33 2004 Subject: [ python-Bugs-990792 ] sre.sub documentation is incomplete Message-ID: Bugs item #990792, was opened at 2004-07-14 07:06 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990792&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Laurent Pinchart (peter_pan78) >Assigned to: A.M. Kuchling (akuchling) Summary: sre.sub documentation is incomplete Initial Comment: The sre.sub code documentation, as returned by help(sre.sub), is incomplete as it doesn't document the second form of the function which takes a callback function as the first argument. The documentation should be updated to at least state that the reader should refer to the official Python library documentation. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 13:42 Message: Logged In: YES user_id=11375 Fixed in CVS HEAD. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990792&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:54:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:54:11 2004 Subject: [ python-Bugs-991883 ] PyObject_CallMethod docs unclear (with dangerous results) Message-ID: Bugs item #991883, was opened at 2004-07-15 16:40 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991883&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) >Assigned to: A.M. Kuchling (akuchling) Summary: PyObject_CallMethod docs unclear (with dangerous results) Initial Comment: PyObject_CallMethod doesn't make clear that passing a tuple of args is the correct way to use it. While it does work when you don't pass a tuple, this causes memory leak - the objects passed in get extra incref, AFAICT, so it's worth emphasizing the correct API. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 13:54 Message: Logged In: YES user_id=11375 Mentioned in the documentation now; thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991883&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:55:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:55:49 2004 Subject: [ python-Bugs-995458 ] Does not build selected SGI specific modules Message-ID: Bugs item #995458, was opened at 2004-07-21 14:55 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bruce D. Ray (brucedray) Assigned to: Nobody/Anonymous (nobody) Summary: Does not build selected SGI specific modules Initial Comment: System is SGI R10K running Irix 6.5.15 Compiler is MIPSpro 7.3 Default configuration build sequence works and installs a python 2.3.4 that does not support GL, audio, etc. because the SGI specific modules for those are not built in the default configuration. To quote the README: On SGI IRIX, there are modules that interface to many SGI specific system libraries, e.g. the GL library and the audio hardware. These modules will not be built by the setup.py script. Therefore, after the default configuration build and install, I uncommented the lines in Modules/Setup that read: gl glmodule.c cgensupport.c -I$(srcdir) $(GLHACK) -lgl -lX11 fm fmmodule.c $(GLHACK) -lfm -lgl sgi sgimodule.c al almodule.c -laudio cd cdmodule.c -lcdaudio -lds -lmediad cl clmodule.c -lcl -lawareaudio fpectl fpectlmodule.c -lfpe fpetest fpetestmodule.c I then did a make clean followed by make Errors returned were: cc -o python Modules/python.o libpython2.3.a -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/mips4/libmpc.a is not used for resolving any symbol. ld32: ERROR 33 : Unresolved text symbol "initgl" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initfm" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initsgi" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "inital" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initcd" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initcl" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initfpectl" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initfpetest" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: INFO 152: Output file removed because of error. *** Error code 2 (bu21) A previous message on the build said that I would have to rerun make Therefore, I again did a make clean followed by make and got the error message: don't know how to make glmodule.c How is this build to be done? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 13:55 Message: Logged In: YES user_id=11375 So what exactly is the bug? ---------------------------------------------------------------------- Comment By: Bruce D. Ray (brucedray) Date: 2004-07-30 10:00 Message: Logged In: YES user_id=1063363 Would that be something like the message () I posted to comp.lang.python 15 Jul. 2004? I posted that back before I managed to tease out of the various convolutions of the build hints that there might be a problem in the construction of a Makefile that points the build to the wrong directory. As hinted at in that article, I had already done a search of the publicly available documentation on python (actually several searches including a download and grep of these). I also did searches of comp.lang.python for anything related to SGI, Silicon Graphics, or Irix; and of comp.sys.sgi.* for anything related to python (if you wish to reproduce this, you might want to exclude the strings "dat" and "tape" because of the many queries there on how to use a Python brand drive for archiving). By 21 Jul. 2004, when I opened this, I was persuaded that I have found a bug in the build, or at least a deficiency in the documentation for build and install. I believe that I have found a bug in the distribution with respect to building on SGI with MIPSpro 7.3 compilers a python with support for available SGI functionality. Thank-you kindly for your reply, but I really am reporting what appears to be a bug. Accordingly, I will leave this open. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-07-29 19:14 Message: Logged In: YES user_id=593130 The appropriate place for how-to questions is comp.lang.python and the corresponding mailing list. Please consider closing this until you are fairly sure you have found a bug in the distribution itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470 From noreply at sourceforge.net Sat Aug 7 19:57:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 19:57:59 2004 Subject: [ python-Bugs-991812 ] PyArg_ParseTuple can miss errors with warnings as exceptions Message-ID: Bugs item #991812, was opened at 2004-07-15 19:45 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991812&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: mssf (mssf) >Assigned to: Michael Hudson (mwh) Summary: PyArg_ParseTuple can miss errors with warnings as exceptions Initial Comment: in getargs.c, the convertsimple function returns NULL if a float warning raised an exception, for example passing a float to an int conversion. NULL is interpreted by the caller, converttupple, as a NON-error The result is that PyArg_ParseTuple returns TRUE even though it has left the float unconverted (and the receiving integer variable containing whatever garbage it contained before the call) changing the return on the float error from NULL to "converterr("integer", arg, msgbuf, bufsize);", as is done with every other error in this function, corrects the problem. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 18:57 Message: Logged In: YES user_id=6656 You're right, of course. Fixed as suggested in Python/getargs.c revision 2.102. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991812&group_id=5470 From noreply at sourceforge.net Sat Aug 7 20:13:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 20:13:51 2004 Subject: [ python-Bugs-1004217 ] Shortcut keys don't work when CAPS LOCK is on Message-ID: Bugs item #1004217, was opened at 2004-08-05 16:48 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004217&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open >Resolution: Duplicate Priority: 5 Submitted By: otto (ottoisi) >Assigned to: Kurt B. Kaiser (kbk) Summary: Shortcut keys don't work when CAPS LOCK is on Initial Comment: IDLE for win32 does not execute keyboard shortcuts when CAPS LOCK is on or the SHIFT key is is pressed. e.g. ctrl-C doesn't work if it's a capital C. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-07 13:13 Message: Logged In: YES user_id=149084 Dup of 833957 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004217&group_id=5470 From noreply at sourceforge.net Sat Aug 7 20:14:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 20:14:05 2004 Subject: [ python-Bugs-1004698 ] Int Type Documentation incomplete Message-ID: Bugs item #1004698, was opened at 2004-08-06 12:01 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Int Type Documentation incomplete Initial Comment: __new__ and __newargs__ don't appear to be documented c.mro() seems to show a circular definition. Please see the examples below: >>> c >>> c.mro() [, ] >>> c.__getnewargs__() >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: descriptor '__getnewargs__' of 'int' object needs an argument >>> c.__getnewargs__(21) (21,) >>> c= 1+1j >>> c (1+1j) >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: __getnewargs__() takes no arguments (1 given) >>> c.__getnewargs__() ((1+1j),) >>> c.__new__ >>> c.__new__(ComplexType) 0j >>> Colin W. ---------------------------------------------------------------------- >Comment By: Colin J. Williams (cjwhrh) Date: 2004-08-07 14:14 Message: Logged In: YES user_id=285587 The first two seem to be missing from the Reference Doc. This third is more a matter of puzzlement. c is of TypeInt c.mro() returns as the first item in its list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:42 Message: Logged In: YES user_id=6656 It's hard to make out which specific bug you are reporting, or even if you are reporting a specific bug. Can you please clarify? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 From noreply at sourceforge.net Sat Aug 7 20:15:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 20:15:31 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability Message-ID: Bugs item #1003471, was opened at 2004-08-04 11:42 Message generated for change (Comment added) made by vacuum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 11:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 09:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 08:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sat Aug 7 20:30:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 20:30:44 2004 Subject: [ python-Bugs-1004698 ] Int Type Documentation incomplete Message-ID: Bugs item #1004698, was opened at 2004-08-06 17:01 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Colin J. Williams (cjwhrh) >Assigned to: Michael Hudson (mwh) Summary: Int Type Documentation incomplete Initial Comment: __new__ and __newargs__ don't appear to be documented c.mro() seems to show a circular definition. Please see the examples below: >>> c >>> c.mro() [, ] >>> c.__getnewargs__() >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: descriptor '__getnewargs__' of 'int' object needs an argument >>> c.__getnewargs__(21) (21,) >>> c= 1+1j >>> c (1+1j) >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: __getnewargs__() takes no arguments (1 given) >>> c.__getnewargs__() ((1+1j),) >>> c.__new__ >>> c.__new__(ComplexType) 0j >>> Colin W. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 19:30 Message: Logged In: YES user_id=6656 __getnewargs__ is documented in http://docs.python.org/lib/pickle-inst.html#l2h-642 __new__ is documented in http://www.python.org/2.2.2/descrintro.html (that the documentation of new-style classes needs to be integrated into the main documentation is not news). The same page will hopefully explain __mro__ and mro() too. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2004-08-07 19:14 Message: Logged In: YES user_id=285587 The first two seem to be missing from the Reference Doc. This third is more a matter of puzzlement. c is of TypeInt c.mro() returns as the first item in its list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 16:42 Message: Logged In: YES user_id=6656 It's hard to make out which specific bug you are reporting, or even if you are reporting a specific bug. Can you please clarify? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 From noreply at sourceforge.net Sat Aug 7 20:39:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 20:39:42 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability Message-ID: Bugs item #1003471, was opened at 2004-08-04 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 14:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sat Aug 7 20:44:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 20:54:26 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability Message-ID: Bugs item #1003471, was opened at 2004-08-04 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) >Assigned to: Tim Peters (tim_one) Summary: Python 1.5.2 security vulnerability Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 14:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:11:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:11:23 2004 Subject: [ python-Bugs-970799 ] Pyton 2.3.4 Make Test Fails on Mac OS X Message-ID: Bugs item #970799, was opened at 2004-06-10 16:42 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970799&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 3 Submitted By: D. Evan Kiefer (dekiefer) Assigned to: Brett Cannon (bcannon) Summary: Pyton 2.3.4 Make Test Fails on Mac OS X Initial Comment: Under Mac OSX 10.3.4 with latest security update. Power Mac G4 733MHz Trying to install Zope 2.7.0 with Python 2.3.4. I first used fink to install 2.3.4 but Zope could find module 'os' to import. I then followed the instructions at: http://zope.org/Members/jens/docs/Document.2003-12-27.2431/ document_view to install Python with the default configure. Unlike under fink, doing this allowed me to run 'make test'. It too noted import problems for 'os' and 'site'. test_tempfile 'import site' failed; use -v for traceback Traceback (most recent call last): File "/Volumes/Spielen/Python-2.3.4/Lib/test/tf_inherit_check.py", line 6, in ? import os ImportError: No module named os test test_tempfile failed -- Traceback (most recent call last): File "/Volumes/Spielen/Python-2.3.4/Lib/test/test_tempfile.py", line 307, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/Volumes/Spielen/Python-2.3.4/Lib/unittest.py", line 274, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure test_atexit 'import site' failed; use -v for traceback Traceback (most recent call last): File "@test.py", line 1, in ? import atexit ImportError: No module named atexit test test_atexit failed -- '' == "handler2 (7,) {'kw': 'abc'}\nhandler2 () {}\nhandler1\n" test_audioop ---------- test_poll skipped -- select.poll not defined -- skipping test_poll test_popen 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback 'import site' failed; use -v for traceback test_popen2 ------------------- 229 tests OK. 2 tests failed: test_atexit test_tempfile 24 tests skipped: test_al test_bsddb3 test_cd test_cl test_curses test_dl test_email_codecs test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_urllibnet test_winreg test_winsound Those skips are all expected on darwin. make: *** [test] Error 1 deksmacintosh:3-> ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:11 Message: Logged In: YES user_id=357491 OK, since we have not heard from dekiefer in over a month I am closing this bug. ---------------------------------------------------------------------- Comment By: D. Evan Kiefer (dekiefer) Date: 2004-06-28 15:16 Message: Logged In: YES user_id=318754 Thanks Jack, I'll try that. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-06-28 14:12 Message: Logged In: YES user_id=45365 My guess is that something in your environment is messing things up. Various of the tests that give the "import site failed" message use subprocesses. What I tend to do to debug issues like this is create a new dummy user (I tend to use the short name "luser" and the long name "Bill Gates":-), unpack a fresh distribution under that account and try building. ---------------------------------------------------------------------- Comment By: D. Evan Kiefer (dekiefer) Date: 2004-06-28 10:54 Message: Logged In: YES user_id=318754 Do you get these failures if you compile Python from scratch instead of using Fink? How about running the tests directly? See above, the second time I installed without fink and ran the tests directly. The errors are from 'make test' done without fink. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-17 14:31 Message: Logged In: YES user_id=357491 Do you get these failures if you compile Python from scratch instead of using Fink? How about running the tests directly? I suspect the test_atexit failure is a Fink-specific issue and the test_tempfile failure was just a timing quirk since it has a threaded and that can make it sensitive to timing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970799&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:12:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:12:58 2004 Subject: [ python-Bugs-866222 ] SimpleHTTPServer docs out of date Message-ID: Bugs item #866222, was opened at 2003-12-27 01:18 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=866222&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gabriel Genellina (gagenellina) >Assigned to: A.M. Kuchling (akuchling) Summary: SimpleHTTPServer docs out of date Initial Comment: The Library documentation about SimpleHTTPServer. py is out of date: In extensions_map: Default is signified by an empty string, and is considered to be text/plain.[...] should read Default is signified by an empty string, and is considered to be application/octet-stream. In do_GET: If the request was mapped to a directory, a 403 respond is output, followed by the explanation 'Directory listing not supported'. Any IOError [...] should read: If the request was mapped to a directory, a file named index.html or index.htm (in that order) is searched inside it. If found, then its contents are returned; otherwise a directory listing is generated using os.listdir. (In case the os.listdir call fails, a 404 error response is sent). Any IOError [...] Later in do_GET: The file is always opened in binary mode. should read: If the file MIME type starts with 'text/' the file is opened in text mode; in any other case binary mode is used. The docstrings inside the module are outdated too. Line 28 (class SimpleHTTPRequestHandler) says: It assumes that all files are plain text files unless they have the extension ".html" in which case it assumes they are HTML files. That's not true; that paragraph should be deleted, or make a reference to method guess_type() below. Docstring for method guess_type() says: [...] using text/plain as a default [...] should read: [...] using application/octet-stream as a default [...] ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 15:12 Message: Logged In: YES user_id=11375 Fixed on both the CVS HEAD and the 2.3 branch. Thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=866222&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:13:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:13:25 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability Message-ID: Bugs item #1003471, was opened at 2004-08-04 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Tim Peters (tim_one) Summary: Python 1.5.2 security vulnerability Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:13 Message: Logged In: YES user_id=31435 I checked in the change to PC/getpathp.c, which is used on Windows. I'm attaching a patch to Modules/getpath.c, which isn't used on Windows (so I can't test it). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 14:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:14:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:14:14 2004 Subject: [ python-Bugs-1005113 ] test__locale fails on MacOS X Message-ID: Bugs item #1005113, was opened at 2004-08-07 06:23 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: test__locale fails on MacOS X Initial Comment: test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include #include int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks.... ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:14 Message: Logged In: YES user_id=357491 Ah! Nick Bastin and I were trying to solve this and noticed that in a straight C program it worked but under Python, no matter where you were, it was incorrect! Thanks for the insight! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 08:10 Message: Logged In: YES user_id=580910 Because this seems to be a bug in OSX I've filed a bug at bugreport.apple.com (radar#3754835) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:15:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:15:28 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability Message-ID: Bugs item #1003471, was opened at 2004-08-04 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) >Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:15 Message: Logged In: YES user_id=31435 Unassigned myself, since I did all I can here. Someone on Linux should test the patch I attached. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:13 Message: Logged In: YES user_id=31435 I checked in the change to PC/getpathp.c, which is used on Windows. I'm attaching a patch to Modules/getpath.c, which isn't used on Windows (so I can't test it). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 14:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:16:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:17:03 2004 Subject: [ python-Bugs-827209 ] List comprehensions leaking control variable name deprecated Message-ID: Bugs item #827209, was opened at 2003-10-20 19:41 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Delaney (tcdelaney) >Assigned to: A.M. Kuchling (akuchling) Summary: List comprehensions leaking control variable name deprecated Initial Comment: According to the email thread starting: http://mail.python.org/pipermail/python-dev/2003- October/039081.html the control variable name in a list comprehension should not be leaked and any use of such a leaked name is deprecated. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 15:16 Message: Logged In: YES user_id=11375 I've applied Alex's suggested patch. Thanks, everyone. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-11-02 12:28 Message: Logged In: YES user_id=60314 I notice that the tutorial currently in CVS seems to have been already fixed (by exciding the paragraph tjreedy quoted). To fix the reference manual, I propose the enclosed patch. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-21 14:19 Message: Logged In: YES user_id=593130 The tutorial will also need revision of deletion: 5.1.4 List Comprehensions has this: To make list comprehensions match the behavior of for loops, assignments to the loop variable remain visible outside of the comprehension: >>> x = 100 # this gets overwritten >>> [x**3 for x in range(5)] [0, 1, 8, 27, 64] >>> x # the final value for range(5) 4 ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-21 10:26 Message: Logged In: YES user_id=43607 Actually, this is not different from $ python Python 2.4a0 (#2, Oct 14 2003, 11:28:48) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> for x in []: ... pass ... >>> print x Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: name 'x' is not defined >>> where x is also undefined after iteraring through an empty list. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-10-21 09:52 Message: Logged In: YES user_id=44345 A good point raised by Michael Hudson is that foo = [x for x in R] print x will fail if R is empty (and x wasn't previously defined). All the more reason to deprecate its usage and suppress the leaking variable. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-20 20:04 Message: Logged In: YES user_id=593130 Ref Man 5.2.4 List displays: suggested addition at end. Using leaked 'for <exp_list>' control variables outside the list display is deprecated and will not work when the bug is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:32:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:32:16 2004 Subject: [ python-Bugs-991962 ] Building with --disable-toolbox-glue fails Message-ID: Bugs item #991962, was opened at 2004-07-15 15:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Building with --disable-toolbox-glue fails Initial Comment: Building with --disable-toolbox-glue fails, because setup.py still tries to build lots of MacOSX extension modules (which fails). There's a define USE_TOOLBOX_OBJECT_GLUE in pyconfig.h that shows whether we're building with or without toolbox glue, but distutils needs to look at that. If it can, otherwise we need a flag in the Makefile too. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:32 Message: Logged In: YES user_id=357491 It seems like we need some way to either have access in Python to what the arguments to Configure were or what macro defs pyconfig.h comes up with. That would be enough info to find out if compiling with toolbox glue we turned off. Otherwise I don't know how Distutils could possibly get access without somehow parsing pyconfig.h to look to see what is set and what isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:32:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:32:38 2004 Subject: [ python-Bugs-914375 ] modulefinder is not documented Message-ID: Bugs item #914375, was opened at 2004-03-11 14:33 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: A.M. Kuchling (akuchling) Summary: modulefinder is not documented Initial Comment: The "modulefinder" module has not been documented. Now that it is a module, it needs to be documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:42:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:43:01 2004 Subject: [ python-Bugs-693255 ] 2.3a2 site.py non-existing dirs Message-ID: Bugs item #693255, was opened at 2003-02-25 14:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: James P Rutledge (jrut) Assigned to: Just van Rossum (jvr) Summary: 2.3a2 site.py non-existing dirs Initial Comment: In Python 2.3a2 the site.py leaves non-existing directories in sys.path. On my Debian Linux system, using Python 2.3a2, the sys.path, after site.py is executed during interpreter initialization, includes the entry /usr/local/lib/python23.zip although no such directory currently exists on my system. The module documentation contained in site.py does state "Non-existing directories (or non-directories) are never added to sys.path" ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:42 Message: Logged In: YES user_id=357491 Closing this as "won't fix" since the part of the docs in question apply only to .pth files and not directories already in sys.path. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-21 06:33 Message: Logged In: YES user_id=357491 OK, the change was backed out. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-03-20 23:49 Message: Logged In: YES user_id=92689 As I wrote before, the _docs_ are wrong, site.py should NOT remove non-existing elements, since they may be non-file system items to be handled by a custom importer. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-20 13:42 Message: Logged In: YES user_id=357491 In Python 2.4, rev. 1.59 has site.py remove non-existing paths. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-07 21:11 Message: Logged In: YES user_id=357491 Can someone with more experience with the "official" policy of of site.py say whether or not the docs should be changed or site.py itself? ---------------------------------------------------------------------- Comment By: James P Rutledge (jrut) Date: 2003-05-29 12:20 Message: Logged In: YES user_id=720847 I do not know what policy is desired for the condition of the path after executing site.py. I found the problem when I switched to try 2.3 and used an application I wrote which searches the path to obtain information about installed modules. During troubleshooting, the change in site.py from 2.2 to 2.3, to stop removing non-existent directories in the path, became evident as the reason for the application finding a non-existent directory in the path. The application was, of course, easily changed to skip non-existent directories. The question is whether removing of non-existent directories in the path _should_ be done by site.py ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-28 18:33 Message: Logged In: YES user_id=357491 I take it the docs are what needs to change and not site.py? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-26 00:43 Message: Logged In: YES user_id=92689 The docs are indeed wrong. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 19:08 Message: Logged In: YES user_id=33168 Just, does the doc still need to be updated? ---------------------------------------------------------------------- Comment By: James P Rutledge (jrut) Date: 2003-02-25 18:56 Message: Logged In: YES user_id=720847 Additional info -- the site.py used in Python 2.2.2 explicitly removes non-existing and non-directory files from sys.path. The Python 2.3 site.py does not have that feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:46:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:46:42 2004 Subject: [ python-Bugs-921077 ] embedding in multi-threaded & multi sub-interpreter environ Message-ID: Bugs item #921077, was opened at 2004-03-22 07:39 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470 >Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Atul (atulkshirsagar) >Assigned to: Brett Cannon (bcannon) Summary: embedding in multi-threaded & multi sub-interpreter environ Initial Comment: I am embedding python in my C++ application. I am using Python *2.3.2* with a C++ extention DLL in multi- threaded environment. I am using SWIG-1.3.19 to generate C++ to Python interface. Now to explain it in details, 1. Python initialization [Py_Initialize()] and finalization [Py_Finalize()] is done in the *main* thread. 2. For each new thread I create a separate sub- interpreter [Py_NewInterpreter()]. 3. Using PyRun_String("import myModule"...) before execution of python script, extention module is imported. 4. Each thread executes *multiple* python script using PyEval_EvalCode() using the class objects in my extention DLL. 5. Each sub-interpreter is destroyed [Py_EndInterpreter ()] at the end of that particular thread. I am observing that; As explained above when multiple threads are running. And as one of these threads finishes, in other running threads I start getting "TypeError: 'NoneType' object is not callable" error on the methods called on class objects in extention module. The same code *works fine* with Python 2.2.2. I have found these links more or less talking about the same problem migrating from 2.2 to 2.3. http://mail.python.org/pipermail/python-dev/2003- September/038237.html http://mail.python.org/pipermail/python-list/2004- February/206851.html http://mail.python.org/pipermail/python-list/2004- January/204040.html I *guess* what is happening is global variables are zapped to "NoneType" when one thread finishes and other thread trying to access them through the Python script (step 4.) this error is generated. But it *works* sometimes when(*guess*) the running thread is at step 3. and by importing the module the global variables are re-initialized for "Type" information. I tried using reload(myModule) to solve the problem but that is generating big memory leak every time it is called. Is this a know issue with 2.3 (interpreter?) ? Or is there a change for 2.3 in the way embedding should be done in a multi-threaded and multi-sub-interpreter environment ? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:46 Message: Logged In: YES user_id=357491 Have you tried this with the fixes added in 2.3.4 or 2.4? Should print out proper tracebacks now. ---------------------------------------------------------------------- Comment By: Atul (atulkshirsagar) Date: 2004-04-05 13:16 Message: Logged In: YES user_id=1003784 Hello, Did you get a chance to take a look at this yet ? Thanks, Atul ---------------------------------------------------------------------- Comment By: Atul (atulkshirsagar) Date: 2004-04-01 12:12 Message: Logged In: YES user_id=1003784 Hello Martin, I am attaching the sample program which demonstrates the issue; 1. I compiled it on Windows 2000 with VC++ compiler. 2. There is a "Extension Module" [flpythonmodulesu(d).dll] which is used by "Main" program ========================================= Extension Module (extModule.dsp project) generates : (*u.* - release, *ud.* - debug) 1. dll _flpythonmodulesud.dll 2. python script flpythonmodulesud.py ------------------------------------------------------ 1. Module has class FlPythonString and class Record defined 2. Using interface file include\flpythonmodulesud.i, SWIG- 1.3.19 generates include\flpythonmodulesud_wrap.cxx =========================================== ========================================= Main sample program (multiSub.dsp project) generates : 1. executable multiSub.exe ------------------------------------------------------ 1. Links in the extension DLL 2. Initializes and De-initializes python in main thread 3. Main thread creates 2 separate threads: (a) Each thread creating a new sub-interpreter (b) importing extension module (c) Calling following EXPRESSION using PyEval_EvalCode(), Thread 1: myVar = FlPythonStringPtr(STRObject) myRecord = myVar.NewRecord() Thread=str(myVar.Get()) record=str(myRecord.GetValue()) print 'Inside EXPRESSION ' + Thread + ':' + record;myVar.DeleteRecord(myRecord) Thread 2: myVar = FlPythonStringPtr(STRObject) for recordNum in range(1, 11): myRecord = myVar.NewRecord() Thread=str(myVar.Get()) record=str(myRecord.GetValue()) print 'Inside EXPRESSION ' + Thread + ':' + record;myVar.DeleteRecord(myRecord) (d) Destroying sub-interpreter. Comments in the code explain details about each step. =========================================== ========================================== Console Output messages explanations (Attaching a sample console output for the issue [consoleop.txt]) ----------------------------------------------------- -Thread *ID*:IMPORT Module Called:*ITERATION* -Inside EXPRESSION *Thread*:*Record::GetValue() [hardcoded to 1000]* -Thread *ID*:EXPRESSION Done:*ITERATION* -Thread *ID*:ENDINTERPRETER Called -Thread *ID*:EXPRESSION Failed!:*ITERATION* Check the error message demonstrating the issue: ----------------------------------------------- "Thread 2:EXPRESSION Failed!:3 Traceback (most recent call last): File "EXPRESSION", line 4, in ? File "E:\VssLocal\Isis\python23_issue\multiSub\Debug\flpython modulesud.py", line 69, in Get def Get(*args): return apply (_flpythonmodulesud.FlPythonString_Get,args) File "E:\VssLocal\Isis\python23_issue\multiSub\Debug\flpython modulesud.py", line 51, in __init__ _swig_setattr(self, Record, 'this', this) TypeError: 'NoneType' object is not callable" ========================================== Martin, Thanks for taking a look at the issue which has proved to be a major hurdle for our release and made us switch back to Python 2.2.2. Python 2.2.2 in itself has some issues for us; so if this can get fixed we would desperately be seeking a patch on Python 2.3. Let me know if you need any more inputs from my side. Thanks again, Atul ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-29 14:28 Message: Logged In: YES user_id=21627 Can you provide an example that demonstrates the supposed bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470 From noreply at sourceforge.net Sat Aug 7 21:58:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 21:59:07 2004 Subject: [ python-Bugs-713601 ] site.py breaks if prefix is empty Message-ID: Bugs item #713601, was opened at 2003-04-01 15:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lalo Martins (lalo) Assigned to: Nobody/Anonymous (nobody) Summary: site.py breaks if prefix is empty Initial Comment: verified in 2.3a1 and 2.2.2: prefixes = [sys.prefix] if sys.exec_prefix != sys.prefix: prefixes.append(sys.exec_prefix) for prefix in prefixes: if prefix: # do stuff - in particular, define the "sitedir" variable # and add site-packages to the path del prefix, sitedir if sys.prefix == sys.exec_prefix and both are empty (which is the case if you compile with --prefix=/ as for the Gnu OS for example), this will have two unfortunate results: 1. site-packages will not be added to the path. 2. site.py will abort with a NameError (it tries to del sitedir which isn't defined) The fix seems to be as simple as removing the "if prefix" line. From mailing list archives, it seems to have been added to cope with unusual loading environments related to windows and COM - in this case, there is probably a safer way to check for this condition. If the prefix is empty, this just means it's the root, and no further assumptions should be made. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:58 Message: Logged In: YES user_id=357491 The NameError problem has been fixed. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 12:09 Message: Logged In: YES user_id=843814 See this patch: 931938 prefix and exec_prefix as root dir bug ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 09:01 Message: Logged In: YES user_id=843814 Just ran into the same problem when I configure with --prefix=/ The problem is in getpath.c. Before trying to find your lib/python dir based on what you submitted in configure, it performs a search based on the python execution path (probably /bin). It keeps chopping the path down with the reduce() function and then adds "/lib/python" and sees if a landmark file is there. The problem is that reduce() will freely chop away the last / leaving your prefix as a null string. I'm going to try tweaking reduce() so it doesn't hack off the last / if its the last one. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-08 15:54 Message: Logged In: YES user_id=357491 Why is sys.prefix == '' if it is set to '/' as the command-line argument? Checking Modules/getpath.c there appears a few places where things could go awry if an enviroment variable is set that causes the code to think it has already found the location before it reaches what the Makefile set PREFIX and EXEC_PREFIX to. The steps used are in the initial comment of the file. Any of those a possible reason for your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 From noreply at sourceforge.net Sat Aug 7 22:01:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 22:01:37 2004 Subject: [ python-Bugs-1005248 ] new.code() not cleanly checking its arguments Message-ID: Bugs item #1005248, was opened at 2004-08-07 20:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: new.code() not cleanly checking its arguments Initial Comment: new.code() does not check its arguments properly: >>> new.code(1,1,1,0,"123",(None,),(5,),(5,),"123","321",2,"") Fatal Python error: non-string found in code slot Here the tuple (5,) is used for co_names and co_varnames. More generally it looks like this part of compile.c could do with quite some cleaning up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 From noreply at sourceforge.net Sat Aug 7 22:14:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 22:14:27 2004 Subject: [ python-Bugs-914375 ] modulefinder is not documented Message-ID: Bugs item #914375, was opened at 2004-03-11 14:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: A.M. Kuchling (akuchling) Summary: modulefinder is not documented Initial Comment: The "modulefinder" module has not been documented. Now that it is a module, it needs to be documented. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 16:14 Message: Logged In: YES user_id=11375 I've written a crude first cut at this, but the module's code is very hard to read and it's not clear which bits are public and which aren't. The module's author should do this task (and use some docstrings in the code, too) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 From noreply at sourceforge.net Sat Aug 7 22:49:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 22:50:08 2004 Subject: [ python-Bugs-592441 ] Webchecker error on http://www.naleo.org Message-ID: Bugs item #592441, was opened at 2002-08-08 05:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470 Category: Demos and Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Carlos Conti (mcsolrac) Assigned to: Jeremy Hylton (jhylton) Summary: Webchecker error on http://www.naleo.org Initial Comment: Webchecker version 1.25.6.1 on Windows 2000 Professional. Run webchecker with this argument http://www.naleo.org/WSJArticle002.htm Webchecker will return this traceback: Traceback (most recent call last): File "C:\Python22\Tools\webchecker\webchecker.py", line 858, in ? main() File "C:\Python22\Tools\webchecker\webchecker.py", line 222, in main c.run() File "C:\Python22\Tools\webchecker\webchecker.py", line 349, in run self.dopage(url) File "C:\Python22\Tools\webchecker\webchecker.py", line 403, in dopage page = self.getpage(url_pair) File "C:\Python22\Tools\webchecker\webchecker.py", line 507, in getpage return Page(text, url, maxpage=self.maxpage, checker=self) File "C:\Python22\Tools\webchecker\webchecker.py", line 671, in __init__ self.parser.feed(self.text) File "C:\Python22\lib\sgmllib.py", line 95, in feed self.goahead(0) File "C:\Python22\lib\sgmllib.py", line 161, in goahead k = self.parse_declaration(i) File "C:\Python22\lib\markupbase.py", line 66, in parse_declaration decltype, j = self._scan_name(j, i) File "C:\Python22\lib\markupbase.py", line 313, in _scan_name self.error("expected name token") File "C:\Python22\lib\sgmllib.py", line 102, in error raise SGMLParseError(message) sgmllib.SGMLParseError: expected name token I believe this is because of the xml in the source code (see WSJArticle002_source.txt attached to this bug report). Even if the code in this page is poorly formatted, webchecker should be able continue checking other links in this domain (rather than stopping). For example webchecker could report ?unable to check http://www.naleo.org/WSJArticle002.htm? and return traceback like the above, and then continue with the rest of the domain. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:49 Message: Logged In: YES user_id=6656 jlgijsbers reports this as fixed by revision 1.30 of webchecker.py on #python-dev IRC. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-13 14:36 Message: Logged In: YES user_id=31392 No need to apologize. Everyone is welcome to submit bug reports here. There are, however, lots of programmers who submit bugs, so I find it helpful to ask :-). I'll look into this, but it's not the highest priority. ---------------------------------------------------------------------- Comment By: Carlos Conti (mcsolrac) Date: 2002-08-08 23:06 Message: Logged In: YES user_id=591396 I'd love to submit a patch, but I am a newbie to both Python and programming. I apologize if this space is only intended for programmers; I am a QA engineer just getting acquainted to the wonderful world of Python. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-08 20:20 Message: Logged In: YES user_id=31392 I've seen a variety of parsing problems kill webchecker. I agree that these exceptions should be caught somewhere so that they are not fatal. Care to submit a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592441&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:01:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:01:22 2004 Subject: [ python-Bugs-914375 ] modulefinder is not documented Message-ID: Bugs item #914375, was opened at 2004-03-11 14:33 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Just van Rossum (jvr) Summary: modulefinder is not documented Initial Comment: The "modulefinder" module has not been documented. Now that it is a module, it needs to be documented. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 16:14 Message: Logged In: YES user_id=11375 I've written a crude first cut at this, but the module's code is very hard to read and it's not clear which bits are public and which aren't. The module's author should do this task (and use some docstrings in the code, too) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:14:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:14:37 2004 Subject: [ python-Bugs-777659 ] Uninitialized variable used in Tools/faqwiz/faqwiz.py Message-ID: Bugs item #777659, was opened at 2003-07-25 17:39 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777659&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Smith (johnjsmith) Assigned to: Skip Montanaro (montanaro) Summary: Uninitialized variable used in Tools/faqwiz/faqwiz.py Initial Comment: Python: 2.3rc2 The uninitialized variable tfn is used in Tools/faqwiz/faqwiz.py (lines 811, 833). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:14 Message: Logged In: YES user_id=6656 Fixed in revision 1.31 of Tools/faqwiz/faqwiz.py with help from jlgijsbers on #python-dev IRC. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-28 12:58 Message: Logged In: YES user_id=44345 The fix appears trivial. I'll check in the change after the 2.3 release. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-27 06:12 Message: Logged In: YES user_id=80475 Guido, these lines were from your patch in 2002. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777659&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:19:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:19:34 2004 Subject: [ python-Bugs-980092 ] tp_subclasses grow without bounds Message-ID: Bugs item #980092, was opened at 2004-06-26 01:54 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980092&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: tp_subclasses grow without bounds Initial Comment: Python 2.3.4 When heap allocated type objects are created, they will be added to their base class's tp_subclasses list as a weak reference. If, for example, your base type is PyBaseObject_Type, then the tp_subclasses list for the base object type will grow for each new object. Unfortunately remove_subclass is never called. If your newly create type objects are deleted, then you will end up with a bunch of weak reference objects in the tp_subclasses list that do not reference anything. Perhaps remove_subclass should be called inside type_dealloc? Or, better yet, tp_subclasses should be a Weak Set. I'm not certain what's the best solution. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:19 Message: Logged In: YES user_id=6656 Do you still think this is a problem? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-29 19:55 Message: Logged In: YES user_id=6656 It's not quite as bad as you might think, because add_subclass will stomp on a dead reference if it finds one. So the length of tp_subclasses is bounded by the number of bases that exist at any one time, which doesn't seem too bad to me. Still, it would seem cleaner to do the removal at type_dealloc time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=980092&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:21:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:21:13 2004 Subject: [ python-Bugs-979872 ] On HPUX 11i universal newlines seems to cause readline(s) to Message-ID: Bugs item #979872, was opened at 2004-06-25 18:23 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979872&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: dmcisaac (dmcisaac) >Assigned to: Michael Hudson (mwh) Summary: On HPUX 11i universal newlines seems to cause readline(s) to Initial Comment: I compiled version 2.3.4 on hp-ux 11i, with shared and threads enabled, using Gnu c 3.3.3. 'make test' fails on all tests that use readline() and/or readlines() and test_univnewlines fails with a memory fault and core dump. All other tests pass that I expect to pass. If I hand modify pyconfig.h to comment out with universal newline support and recompile (after a make clean) then the readline(s) failures go away. I have also compiled without thread support and got the same failures as with using universal newlines. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:21 Message: Logged In: YES user_id=6656 Closing. Hope that's what you wanted. Sometimes bugs that go away when you turn off optimization are real problems in Python code. But not very often -- and even less often on HP-UX :-/ ---------------------------------------------------------------------- Comment By: dmcisaac (dmcisaac) Date: 2004-06-28 20:31 Message: Logged In: YES user_id=1071078 On further investigation I got everything to compile the way I think it should if I ommit optimization. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979872&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:22:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:23:24 2004 Subject: [ python-Bugs-777659 ] Uninitialized variable used in Tools/faqwiz/faqwiz.py Message-ID: Bugs item #777659, was opened at 2003-07-25 17:39 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777659&group_id=5470 Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John J Smith (johnjsmith) Assigned to: Skip Montanaro (montanaro) Summary: Uninitialized variable used in Tools/faqwiz/faqwiz.py Initial Comment: Python: 2.3rc2 The uninitialized variable tfn is used in Tools/faqwiz/faqwiz.py (lines 811, 833). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:14 Message: Logged In: YES user_id=6656 Fixed in revision 1.31 of Tools/faqwiz/faqwiz.py with help from jlgijsbers on #python-dev IRC. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-28 12:58 Message: Logged In: YES user_id=44345 The fix appears trivial. I'll check in the change after the 2.3 release. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-27 06:12 Message: Logged In: YES user_id=80475 Guido, these lines were from your patch in 2002. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777659&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:33:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:33:26 2004 Subject: [ python-Bugs-979739 ] compile of code with incorrect encoding yields MemoryError Message-ID: Bugs item #979739, was opened at 2004-06-25 14:45 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979739&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: compile of code with incorrect encoding yields MemoryError Initial Comment: The following code will fail in both Python 2.3 and Python 2.4, raising a MemoryError exception, when run on any platform except Windows: compile("# -*- coding: mbcs -*-", "test.py", "exec") This has been reproduced on the following platforms: Linux x86 HP-UX Solaris Tru64 Unix I realize this is an invalid encoding but it would be nice if something other than MemoryError was raised! ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:33 Message: Logged In: YES user_id=6656 Here's a simple and seemingly effective patch. I'm not sure it's "the right thing", though. The whole issue of whether the parser should or should not set exceptions is a frightful mess. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-06-25 20:09 Message: Logged In: YES user_id=11105 I assume the behaviour occurrs when an unknown encoding is specified. It can be reproduced on Windows: compile("# -*- coding: xxx -*-", "test.py", "exec") It should probably raise a SyntaxError, as trying to import a module containing this encoding does. The problem seems that when PyParser_ParseStringFlagsFilename() calls PyTokenizer_FromString(), and when the latter fails the error is set to E_NOMEM. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979739&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:39:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:39:55 2004 Subject: [ python-Bugs-713601 ] site.py breaks if prefix is empty Message-ID: Bugs item #713601, was opened at 2003-04-01 15:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 Category: Python Library >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lalo Martins (lalo) >Assigned to: Brett Cannon (bcannon) Summary: site.py breaks if prefix is empty Initial Comment: verified in 2.3a1 and 2.2.2: prefixes = [sys.prefix] if sys.exec_prefix != sys.prefix: prefixes.append(sys.exec_prefix) for prefix in prefixes: if prefix: # do stuff - in particular, define the "sitedir" variable # and add site-packages to the path del prefix, sitedir if sys.prefix == sys.exec_prefix and both are empty (which is the case if you compile with --prefix=/ as for the Gnu OS for example), this will have two unfortunate results: 1. site-packages will not be added to the path. 2. site.py will abort with a NameError (it tries to del sitedir which isn't defined) The fix seems to be as simple as removing the "if prefix" line. From mailing list archives, it seems to have been added to cope with unusual loading environments related to windows and COM - in this case, there is probably a safer way to check for this condition. If the prefix is empty, this just means it's the root, and no further assumptions should be made. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=357491 I just tried compiling on the 2.3 maintenance branch with --prefix=/ and I had sys.prefix be set to '/'. Can you check to see if you are still having sys.prefix set to an empty string? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:58 Message: Logged In: YES user_id=357491 The NameError problem has been fixed. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 12:09 Message: Logged In: YES user_id=843814 See this patch: 931938 prefix and exec_prefix as root dir bug ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 09:01 Message: Logged In: YES user_id=843814 Just ran into the same problem when I configure with --prefix=/ The problem is in getpath.c. Before trying to find your lib/python dir based on what you submitted in configure, it performs a search based on the python execution path (probably /bin). It keeps chopping the path down with the reduce() function and then adds "/lib/python" and sees if a landmark file is there. The problem is that reduce() will freely chop away the last / leaving your prefix as a null string. I'm going to try tweaking reduce() so it doesn't hack off the last / if its the last one. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-08 15:54 Message: Logged In: YES user_id=357491 Why is sys.prefix == '' if it is set to '/' as the command-line argument? Checking Modules/getpath.c there appears a few places where things could go awry if an enviroment variable is set that causes the code to think it has already found the location before it reaches what the Makefile set PREFIX and EXEC_PREFIX to. The steps used are in the initial comment of the file. Any of those a possible reason for your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:41:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:41:51 2004 Subject: [ python-Bugs-971213 ] another threads+readline+signals nasty Message-ID: Bugs item #971213, was opened at 2004-06-11 16:30 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: another threads+readline+signals nasty Initial Comment: python -c "import time, readline, thread; thread.start_new_thread(raw_input, ()); time.sleep(2)" Segfaults on ^C Fails on Linux, freebsd. On linux (FC - using kernel 2.6.1, glibc 2.3.3, gcc-3.3.3) (gdb) where #0 0x002627a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x008172b1 in ___newselect_nocancel () from /lib/tls/libc.so.6 #2 0x0011280b in time_sleep (self=0x0, args=0xb7fe17ac) at Modules/timemodule.c:815 on FreeBSD 5.2.1-RC, a different error. Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line 72 in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = 2) Abort (core dumped) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:41 Message: Logged In: YES user_id=6656 Bah, this still segfaults with CVS head. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-21 11:45 Message: Logged In: YES user_id=6656 Can you try the patch that's *now* in 960406? It seems to help for me (but I really would rather not think too hard about this!). ---------------------------------------------------------------------- Comment By: Michal Pasternak (mpasternak) Date: 2004-06-11 16:43 Message: Logged In: YES user_id=799039 readline used on FreeBSD was readline-4.3pl5; everything else: gcc 3.3.3, ncurses, libc were standard from 5.2.1. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:39 Message: Logged In: YES user_id=29957 The patch in #960406 doesn't help here. The FC test system also has readline-4.3, if it helps, as does the FreeBSD box. It apparently doesn't crash on OSX. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 16:38 Message: Logged In: YES user_id=6656 Hmm. Doesn't crash on OS X. Messes the terminal up good and proper, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:43:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:43:17 2004 Subject: [ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c Message-ID: Bugs item #970334, was opened at 2004-06-10 13:46 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) >Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-10 16:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:44:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:44:47 2004 Subject: [ python-Bugs-992017 ] code that generates a segfault on Python 2.1-2.3 Message-ID: Bugs item #992017, was opened at 2004-07-15 23:56 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ted Bach (bachtor) Assigned to: Nobody/Anonymous (nobody) Summary: code that generates a segfault on Python 2.1-2.3 Initial Comment: On a Redhat Linux 9 based system, the following causes a segfault: """ In python, you can call any expression. """ class foo: def __init__(s,times=1): s.times = times def __call__(s): print s.times def __mul__(s,o): return foo(o) def __coerce__(s,o): if isinstance(o,int): return o,s (foo(3)*10)() # no segfault (10*foo(3))() # segfaults # prints 10 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-08-07 21:44 Message: Logged In: YES user_id=4771 Here is a shorter example: class foo: def __coerce__(self, other): return other, self foo()+1 # segfault: infinite recursion in C classobject.c seems hopelessly prone to infinite recursion in C: whenever an operation needs coercion, __coerce__ is called and the operator PyNumber_Xxx() is called again on the result. The most obvious cases of recursion are taken care of, but there are and will always be more convoluted ways to create this recursion. There might be a way to solve the problem cleanly but currently I only see the solution of adding a C recursion check (Py_EnterRecursiveCall / Py_LeaveRecursiveCall). ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-07-22 14:18 Message: Logged In: YES user_id=908995 This is not the same problem as bug #980352; this one is an infinite recusion in the instance code (deriving foo from object makes the example work). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-16 13:45 Message: Logged In: YES user_id=6656 Isn't this likely to be a dup of bug [ 980352 ] coercion results used dangerously ? I haven't thought about either very hard, but both involve __coerce__ and core dumps... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:45:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:45:29 2004 Subject: [ python-Bugs-967334 ] Cmd in thread segfaults after Ctrl-C Message-ID: Bugs item #967334, was opened at 2004-06-06 00:11 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967334&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Kevin M. Turner (acapnotic) >Assigned to: Michael Hudson (mwh) Summary: Cmd in thread segfaults after Ctrl-C Initial Comment: With Cmd.cmdloop running in a thread, saying Ctrl-C will make Python segfault. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:45 Message: Logged In: YES user_id=6656 Usual deal; two months of inactivity. Two more weeks and this will be closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 22:15 Message: Logged In: YES user_id=33168 This works for me on Linux. What OS are you using? Are you using any non-standard extension modules? What version of Python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967334&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:48:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:48:14 2004 Subject: [ python-Bugs-952953 ] execve rejects empty argument list Message-ID: Bugs item #952953, was opened at 2004-05-13 01:54 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=952953&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: newsham (newsham) Assigned to: Nobody/Anonymous (nobody) Summary: execve rejects empty argument list Initial Comment: The exec* family of calls in the os package does not allow an empty list of arguments to be passed in. Passing is an empty list (ie. allow argv[0] to be NULL and argc to be zero) is rarely desired, but perfectly legal. Verify by: import os os.execve("/bin/ls", [], {}) Tim N. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:48 Message: Logged In: YES user_id=6656 I think you'll need to supply a patch to have any hope of this changing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=952953&group_id=5470 From noreply at sourceforge.net Sat Aug 7 23:59:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 7 23:59:42 2004 Subject: [ python-Bugs-991196 ] An inconsistency with nested scopes Message-ID: Bugs item #991196, was opened at 2004-07-14 21:30 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991196&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Jacobson (nickjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: An inconsistency with nested scopes Initial Comment: There's an inconsistency with nested scopes. >From the Python Ref. Manual: "If [a local variable] definition occurs in a function block, the scope extends to any blocks contained within the defining one..." i.e. So as long as code is not on the module level, scopes are extended. Therefore this works: def main(): y = 3 def execfunc(): print y execfunc() if __name__ == '__main__': main() In addition, if code IS on the module level, its variables go in globals(). So this works too: y = 3 def execfunc(): print y execfunc() However, (here's the inconsistency) the following code fails, saying that y is undefined: def main(): s = """ y = 3 def execfunc(): print y execfunc() """ d = {} e = {} exec s in d, e if __name__ == '__main__': main() In this case, the code in s is treated like it's on the module level, and the nested scope treatment of y doesn't occur. BUT, unlike normal code on the module level, y doesn't go in globals(). I think globals() is locked or something? Conclusion: The latter piece of code should work; that is, y should be nested and therefore recognized by execfunc(). ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-08-07 21:59 Message: Logged In: YES user_id=4771 The behavior you get can be explained quite easy, but it seems nevertheless inconsistent with the documentation: in my opinion it is a serious bug. The reason the "exec"ed code doesn't work like the same code put at the global module level is that code that runs at the module level always runs with the same dictionary for its globals and locals, whereas in your example you use two different dictionaries. Assignments always go to the locals; that's why 'y' goes into the dictionary 'e'. Now a function can only see its own locals and the surrounding globals; that's why execfunc() misses the value of 'y'. This is the old way Python worked. In recent versions, a special trick was added so that functions defined inside another function find variable bindings from the enclosing function. I think you found a case where this trick fails to apply. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-07-22 16:55 Message: Logged In: YES user_id=341410 >>> def f(): ... y = 5 ... print 'y' in globals(), 'y' in locals() ... def i(): ... print 'y' in globals(), 'y' in locals() ... i() ... >>> f() False True False False >>> >>> def g(): ... gl = {};lo={} ... exec '''y = 5 ... print 'y' in globals(), 'y' in locals() ... def i(): ... print 'y' in globals(), 'y' in locals() ... i() ... ''' in gl, lo ... >>> g() False True False False That looks constant...but what if we print out 'y'? >>> def s(): ... y = 5 ... print 'y' in globals(), 'y' in locals(), y ... def i(): ... print 'y' in globals(), 'y' in locals(), y ... i() ... >>> s() False True 5 False True 5 >>> >>> def t(): ... gl = {};lo = {} ... exec '''y = 5 ... print 'y' in globals(), 'y' in locals(), y ... def i(): ... print 'y' in globals(), 'y' in locals(), y ... i() ... ''' in gl, lo ... >>> t() False True 5 False False Traceback (most recent call last): File "", line 1, in ? File "", line 3, in t File "", line 5, in ? File "", line 4, in i NameError: global name 'y' is not defined Now why did 'y' stick itself into the locals() of i() in s()? Is this another bug? What if we remove the namespaces gl and lo? >>> def u(): ... exec '''y = 5 ... print 'y' in globals(), 'y' in locals(), y ... def i(): ... print 'y' in globals(), 'y' in locals(), y ... i() ... ''' ... >>> u() False True 5 False False Traceback (most recent call last): File "", line 1, in ? File "", line 2, in u File "", line 5, in ? File "", line 4, in i NameError: global name 'y' is not defined Nope, still dies. It does seem to be a bug in exec. I'm still curious why 'y' was placed into i()'s local namespace in s(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991196&group_id=5470 From noreply at sourceforge.net Sun Aug 8 00:17:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 00:17:40 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-31 02:08 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2004-08-08 00:17 Message: Logged In: YES user_id=34209 The point of the original bugreport is not that some operations return strings instead of subtypes. The point is that *one* operation *sometimes* returns subtypes. It's inconsistent and unexpected behaviour, and since you clearly don't write 'sep.join(seq)' for a common case of 'seq' being a single item, something you will only occasionally trigger. I don't have an emotional investment in this bug, it's just something that came up on #python. I also don't care which way it's fixed -- but treating the single-element-sequence case the same as the multiple-element-sequence seems logical to me. Regardless of how the multiple-element-sequence is handled exactly :) As for why I didn't write a patch myself, Michael, if I had time for that, I would've spent it writing a good decorator proposal >:-) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-08-07 17:48 Message: Logged In: YES user_id=7887 If this was considered a bug: >>> type(ms("a")+ms("b")) >>> type(ms("a")[:]) Are these bugs as well? I belive this is how the implementation was intended to be, even if not optimal for subclasses. I suggest closing this bug as invalid, and writing a PEP about the possible new subclass support change (for all classes), if there's enough interest. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-05 18:10 Message: Logged In: YES user_id=593130 Duh, my turn to forget. For any beginners reading this ... >>> class ms(str): pass ... >>> a=ms('a') >>> type(''.join((a,))) Expanding mhw's second point: >>> e=ms() >>> type(e) >>> import copy >>> e2=copy.copy(e) >>> type(e2) >>> e3=e[:] >>> type(e3) >>> id(e),id(e2),id(e3) (9494608, 9009936, 8577440) so [:] is not exactly an abbreviated synonym for copy(). Is this a butg? (I haven't rechecked the respective docs yet.) One reason I hesitate to call the OP's original observation a bug is that the whole sujbect of operations on subtype instances seems not completely baked. Knowing the result types in all cases may require experiments as well as doc reading. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 14:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-04 22:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 21:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 16:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Sun Aug 8 00:19:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 00:19:42 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability still present in 2.3.4 Message-ID: Bugs item #1003471, was opened at 2004-08-04 11:42 Message generated for change (Comment added) made by vacuum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) >Summary: Python 1.5.2 security vulnerability still present in 2.3.4 Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 15:19 Message: Logged In: YES user_id=116409 As tim_one poin ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:15 Message: Logged In: YES user_id=31435 Unassigned myself, since I did all I can here. Someone on Linux should test the patch I attached. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:13 Message: Logged In: YES user_id=31435 I checked in the change to PC/getpathp.c, which is used on Windows. I'm attaching a patch to Modules/getpath.c, which isn't used on Windows (so I can't test it). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 11:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 11:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 11:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 09:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 08:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sun Aug 8 01:10:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 01:10:12 2004 Subject: [ python-Bugs-1005308 ] _XOPEN_SOURCE issue on IRIX 5.3 Message-ID: Bugs item #1005308, was opened at 2004-08-08 01:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: _XOPEN_SOURCE issue on IRIX 5.3 Initial Comment: On IRIX 5.3 /usr/include/sys/types.h contains: #if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /* * Nested include for BSD/sockets source compatibility. * (The select macros used to be defined here). */ #include #endif sys/bsd_types.h however defines u_int. If _XOPEN_SOURCE is defined (in pyconfig.h) this results in u_int not being known and the compilation to fail. One way to get around this is to change configure as follows (similarly as it is already being done for some other OSes, it seems...): --- configure.orig 2004-08-08 00:18:33.000000000 + 0200 +++ configure 2004-08-08 00:18:59.000000000 +0200 @@ -1466,6 +1466,8 @@ # has another value. By not (re)defining it, the defaults come in place. AIX/4) define_xopen_source=no;; + IRIX/5.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes I am not sure if this is the best way to solve that problem though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 From noreply at sourceforge.net Sun Aug 8 01:55:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 01:55:14 2004 Subject: [ python-Bugs-1004698 ] Int Type Documentation incomplete Message-ID: Bugs item #1004698, was opened at 2004-08-06 12:01 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Michael Hudson (mwh) Summary: Int Type Documentation incomplete Initial Comment: __new__ and __newargs__ don't appear to be documented c.mro() seems to show a circular definition. Please see the examples below: >>> c >>> c.mro() [, ] >>> c.__getnewargs__() >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: descriptor '__getnewargs__' of 'int' object needs an argument >>> c.__getnewargs__(21) (21,) >>> c= 1+1j >>> c (1+1j) >>> c.__getnewargs__(21) Traceback (most recent call last): File "", line 1, in ? TypeError: __getnewargs__() takes no arguments (1 given) >>> c.__getnewargs__() ((1+1j),) >>> c.__new__ >>> c.__new__(ComplexType) 0j >>> Colin W. ---------------------------------------------------------------------- >Comment By: Colin J. Williams (cjwhrh) Date: 2004-08-07 19:55 Message: Logged In: YES user_id=285587 Thanks Michael, mro is defined in the Simionato paper. The key is " including the class itself". The __new__ is not exactly defined, but is clear enough in the GVD paper. I'm afraid I found the material on __getnewargs__ incomprehesible. Could I suggest that a note be put in the main docs that these terms will be defined? Colin W. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 14:30 Message: Logged In: YES user_id=6656 __getnewargs__ is documented in http://docs.python.org/lib/pickle-inst.html#l2h-642 __new__ is documented in http://www.python.org/2.2.2/descrintro.html (that the documentation of new-style classes needs to be integrated into the main documentation is not news). The same page will hopefully explain __mro__ and mro() too. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2004-08-07 14:14 Message: Logged In: YES user_id=285587 The first two seem to be missing from the Reference Doc. This third is more a matter of puzzlement. c is of TypeInt c.mro() returns as the first item in its list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:42 Message: Logged In: YES user_id=6656 It's hard to make out which specific bug you are reporting, or even if you are reporting a specific bug. Can you please clarify? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004698&group_id=5470 From noreply at sourceforge.net Sun Aug 8 02:13:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 02:13:33 2004 Subject: [ python-Bugs-1005325 ] inconsistent acceptance of floats for range() Message-ID: Bugs item #1005325, was opened at 2004-08-07 17:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005325&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistent acceptance of floats for range() Initial Comment: ``range(1.0)`` will raise a DeprecationWarning (thanks to PyArg_ParseTuple() warning when a float is passed when an integer is expected), but if you do ``range(1e100)`` it raises a TypeError saying that an "integer end argument expected, got float". Obviously not consistent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005325&group_id=5470 From noreply at sourceforge.net Sun Aug 8 03:01:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 03:03:10 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability still present in 2.3.4 Message-ID: Bugs item #1003471, was opened at 2004-08-04 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability still present in 2.3.4 Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 21:01 Message: Logged In: YES user_id=31435 I checked in the attached patch too. If there's ever another release in the 2.3 line, these patches would make decent backport candidates. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 18:19 Message: Logged In: YES user_id=116409 As tim_one poin ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:15 Message: Logged In: YES user_id=31435 Unassigned myself, since I did all I can here. Someone on Linux should test the patch I attached. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:13 Message: Logged In: YES user_id=31435 I checked in the change to PC/getpathp.c, which is used on Windows. I'm attaching a patch to Modules/getpath.c, which isn't used on Windows (so I can't test it). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 14:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Sun Aug 8 05:06:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 05:06:32 2004 Subject: [ python-Bugs-764504 ] doctest fails with TypeError Message-ID: Bugs item #764504, was opened at 2003-07-02 06:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764504&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Mark J (average) >Assigned to: Tim Peters (tim_one) Summary: doctest fails with TypeError Initial Comment: #mymod.py: class base(dict): myupdate = dict.update #FINE def myfunc(self): pass class derive(base): myname = base.myfunc #FAILS import doctest, mymod doctest.testmod(mymod) ****** $ python2.3b2 mymod.py Traceback (most recent call last): File "mymod.py", line 8, in ? import doctest, mymod File "/home/me/mymod.py", line 9, in ? doctest.testmod(mymod) File "/usr/local/lib/python2.3/doctest.py", line 1137, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/local/lib/python2.3/doctest.py", line 900, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/local/lib/python2.3/doctest.py", line 1061, in __runone return self.rundoc(target, name) File "/usr/local/lib/python2.3/doctest.py", line 820, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/local/lib/python2.3/doctest.py", line 929, in run__test__ raise TypeError("Tester.run__test__: values in " TypeError: Tester.run__test__: values in dict must be strings, functions or classes; <unbound method base.myfunc> ****** Does not appear to be specific to Python v2.3. Thanks! Mark ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 23:06 Message: Logged In: YES user_id=31435 The example no longer complains in 2.4 doctest.py, so closing as Fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-17 02:27 Message: Logged In: YES user_id=80475 Agreed. There is no compelling use case for changing this in Py2.3. Marking as postponed. For Py2.4, there will be plenty of time for merging/improving the underlying search behaviors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-16 17:08 Message: Logged In: YES user_id=31435 If it has to be fixed <wink>, the only principle I can conjure up is that redundant testing is a waste of time and surprising. On that ground, in the specific example I'd rather skip it, since if the thing had a doctest, it would be most natural to run it from base.myfunc.__doc__. If you're feeling more ambitious, I recently slammed in some useful doctest extensions from Jim Fulton. As I know you've already discovered, there are some warts. The deepest wart isn't obvious: Jim's extensions use their own ways of finding doctests to run. It would be good if everthing used the same ways of finding doctests to run. This bug report shows that doctest's old ways don't always work. It's unknown in how many situations the new ways don't work, and/or deliver different results. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 01:48 Message: Logged In: YES user_id=80475 Tim, would you like me to fix this one by searching the unbound method or by skipping the unbound method? Since classes are searched recursively, it may be reasonable to search the unbound method. However, imports are not searched, so there is a precedent for skipping it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764504&group_id=5470 From noreply at sourceforge.net Sun Aug 8 05:25:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 05:25:22 2004 Subject: [ python-Bugs-864944 ] doctest chokes on recursive members Message-ID: Bugs item #864944, was opened at 2003-12-23 06:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gintautas Miliauskas (gintautasm) >Assigned to: Tim Peters (tim_one) Summary: doctest chokes on recursive members Initial Comment: doctests recurse infinitely when they find a recursive member in a class. A simple example: --b0rk.py-- class Crash: pass Crash.c = Crash ----- --test.py-- import doctest import b0rk doctest.testmod(b0rk) ----- --output of test.py-- Traceback (most recent call last): File "test.py", line 5, in ? doctest.testmod(b0rk) File "/usr/lib/python2.3/doctest.py", line 1148, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/lib/python2.3/doctest.py", line 908, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/lib/python2.3/doctest.py", line 1069, in __runone return self.rundoc(target, name) File "/usr/lib/python2.3/doctest.py", line 828, in rundoc f2, t2 = self.run__test__(d, name) <.............................> File "/usr/lib/python2.3/doctest.py", line 935, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.3/doctest.py", line 790, in rundoc for tag, kind, homecls, value in _classify_class_attrs(object): File "/usr/lib/python2.3/inspect.py", line 201, in classify_class_attrs mro = getmro(cls) RuntimeError: maximum recursion depth exceeded ----- ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 23:25 Message: Logged In: YES user_id=31435 This is fixed in Python 2.4's doctest.py, which does keep a set of already-seen objects. But, since this was done as part of a massive refactoring of doctest.py, I have no plan to backport any part of it to the 2.3 line. ---------------------------------------------------------------------- Comment By: Marius Gedminas (mgedmin) Date: 2003-12-29 05:52 Message: Logged In: YES user_id=44660 The fact that the traceback ends in getmro is just an accident. There is an infinite recursion between run__test__ and rundoc when a class attribute references the class itself. The problem was originally noticed by playing with Zope 3. Apparently Zope 3 interfaces add a class attribute that references the class itself (perhaps indirectly) and causes this problem to appear whenever a class declares that it implements some interface, e.g. from zope.interface import implements class SomeClass(object): """docstring >>> x = SomeClass() ... """ implements(ISomeInterface) Since Zope 3 component architecture requires that virtually all classes declare what interfaces they implement, it makes class doctests unusable with Zope 3. A possible solution is to keep a set of "seen" objects and check near the beginning of Tester.rundoc whether an object was already processed. ---------------------------------------------------------------------- Comment By: Gintautas Miliauskas (gintautasm) Date: 2003-12-29 05:46 Message: Logged In: YES user_id=936754 I guess I snipped a little too much traceback... Here is a part of traceback (reproduced with python 2.2.) that illustrates the idea: <...> File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) <...> It's definitely not a fault of getmro(). Besides, I've tested and the crash occurs on Python 2.1, 2.2 and 2.3. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-12-28 17:05 Message: Logged In: YES user_id=593130 Traceback says crash happens in inspect.getmro and not in doctest itself. In 2.2.1, I get >>> class C: pass ... >>> C.c=C >>> import inspect as i >>> i.getmro(C) (<class __main__.C at 0x00867510>,) However, mro resolution was changed for 2.3. See if above changes in 2.3. Or if calling on class inside imported module makes a difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 From noreply at sourceforge.net Sun Aug 8 05:29:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 05:29:59 2004 Subject: [ python-Bugs-864944 ] doctest chokes on recursive members Message-ID: Bugs item #864944, was opened at 2003-12-23 06:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Gintautas Miliauskas (gintautasm) Assigned to: Tim Peters (tim_one) Summary: doctest chokes on recursive members Initial Comment: doctests recurse infinitely when they find a recursive member in a class. A simple example: --b0rk.py-- class Crash: pass Crash.c = Crash ----- --test.py-- import doctest import b0rk doctest.testmod(b0rk) ----- --output of test.py-- Traceback (most recent call last): File "test.py", line 5, in ? doctest.testmod(b0rk) File "/usr/lib/python2.3/doctest.py", line 1148, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/lib/python2.3/doctest.py", line 908, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/lib/python2.3/doctest.py", line 1069, in __runone return self.rundoc(target, name) File "/usr/lib/python2.3/doctest.py", line 828, in rundoc f2, t2 = self.run__test__(d, name) <.............................> File "/usr/lib/python2.3/doctest.py", line 935, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.3/doctest.py", line 790, in rundoc for tag, kind, homecls, value in _classify_class_attrs(object): File "/usr/lib/python2.3/inspect.py", line 201, in classify_class_attrs mro = getmro(cls) RuntimeError: maximum recursion depth exceeded ----- ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-07 23:29 Message: Logged In: YES user_id=31435 BTW, since you mentioned Zope3, Zope3 will use its own copy of 2.4's doctest.py until 2.4 becomes the minimum version. So there's no need to backport anything for Zope3's benefit. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 23:25 Message: Logged In: YES user_id=31435 This is fixed in Python 2.4's doctest.py, which does keep a set of already-seen objects. But, since this was done as part of a massive refactoring of doctest.py, I have no plan to backport any part of it to the 2.3 line. ---------------------------------------------------------------------- Comment By: Marius Gedminas (mgedmin) Date: 2003-12-29 05:52 Message: Logged In: YES user_id=44660 The fact that the traceback ends in getmro is just an accident. There is an infinite recursion between run__test__ and rundoc when a class attribute references the class itself. The problem was originally noticed by playing with Zope 3. Apparently Zope 3 interfaces add a class attribute that references the class itself (perhaps indirectly) and causes this problem to appear whenever a class declares that it implements some interface, e.g. from zope.interface import implements class SomeClass(object): """docstring >>> x = SomeClass() ... """ implements(ISomeInterface) Since Zope 3 component architecture requires that virtually all classes declare what interfaces they implement, it makes class doctests unusable with Zope 3. A possible solution is to keep a set of "seen" objects and check near the beginning of Tester.rundoc whether an object was already processed. ---------------------------------------------------------------------- Comment By: Gintautas Miliauskas (gintautasm) Date: 2003-12-29 05:46 Message: Logged In: YES user_id=936754 I guess I snipped a little too much traceback... Here is a part of traceback (reproduced with python 2.2.) that illustrates the idea: <...> File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/lib/python2.2/doctest.py", line 905, in run__test__ f, t = self.rundoc(v, thisname) File "/usr/lib/python2.2/doctest.py", line 798, in rundoc f2, t2 = self.run__test__(d, name) <...> It's definitely not a fault of getmro(). Besides, I've tested and the crash occurs on Python 2.1, 2.2 and 2.3. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-12-28 17:05 Message: Logged In: YES user_id=593130 Traceback says crash happens in inspect.getmro and not in doctest itself. In 2.2.1, I get >>> class C: pass ... >>> C.c=C >>> import inspect as i >>> i.getmro(C) (<class __main__.C at 0x00867510>,) However, mro resolution was changed for 2.3. See if above changes in 2.3. Or if calling on class inside imported module makes a difference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864944&group_id=5470 From noreply at sourceforge.net Sun Aug 8 08:14:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 08:14:29 2004 Subject: [ python-Bugs-902628 ] doctest confused by super-instances in class-dicts Message-ID: Bugs item #902628, was opened at 2004-02-23 07:10 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902628&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christian Tanzer (tanzer) >Assigned to: Tim Peters (tim_one) Summary: doctest confused by super-instances in class-dicts Initial Comment: In Python 2.3.3, doctest chokes on classes which contain an attribute of type super: Traceback (most recent call last): File "/ttt/private/tanzer/temp/confuse_doctest.py", line 14, in ? import doctest, confuse_doctest File "/Node/tttprime/ttt/private/tanzer/temp/confuse_doctest.py", line 15, in ? doctest.testmod(confuse_doctest) File "/usr/lib/python2.3/doctest.py", line 1148, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/lib/python2.3/doctest.py", line 908, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/lib/python2.3/doctest.py", line 1069, in __runone return self.rundoc(target, name) File "/usr/lib/python2.3/doctest.py", line 828, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/lib/python2.3/doctest.py", line 937, in run__test__ raise TypeError("Tester.run__test__: values in " TypeError: Tester.run__test__: values in dict must be strings, functions, methods, or classes; , NULL> A simple example triggering the bug is attached. Python 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-08 02:14 Message: Logged In: YES user_id=31435 This got fixed as part of the massive doctest refactoring for 2.4. I have no plan to backport any of that to the 2.3 line. ---------------------------------------------------------------------- Comment By: Edward Loper (edloper) Date: 2004-07-16 11:12 Message: Logged In: YES user_id=195958 The problem is that inspect.get_class_attrs()'s "method" classification is a bit hetergeneous: it contains methods, and any method descriptors *except* classmethod and staticmethod. The proposed patch will fix behavior for super(), but not for any other method descriptors. So perhaps it would be better to explicitly test "_isfunction(v) or _ismethod(v)" rather than "not isinstance(value, super)". ---------------------------------------------------------------------- Comment By: Christian Tanzer (tanzer) Date: 2004-02-23 07:15 Message: Logged In: YES user_id=2402 I patched doctest.py to avoid the traceback (see attached patch-file). I'm not sure if this is the right place to fix the bug, though. Maybe inspect.classify_class_attrs should be changed instead? The second chunk of the patch improves the traceback given by doctest by giving the name of the offending dict-item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902628&group_id=5470 From noreply at sourceforge.net Sun Aug 8 09:14:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 09:14:42 2004 Subject: [ python-Bugs-1003195 ] segfault when running smtplib example Message-ID: Bugs item #1003195, was opened at 2004-08-04 13:43 Message generated for change (Comment added) made by bertramscharpf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bertram Scharpf (bertramscharpf) Assigned to: Nobody/Anonymous (nobody) Summary: segfault when running smtplib example Initial Comment: On my system, running the simple smtplib Example from the Documentation results in a segmentation fault. Execution stops and no mail is submitted. I debugged into the Python source code, but my understanding of the inner mechanisms doesn't suffice to fix the problem. I update my system periodically using "apt-get update ; apt-get upgrade". I don't remember, when it was the last time Python was upgraded. I made the files availabe: http://www.bertram-scharpf.de/tmp/smtpex.py.txt http://www.bertram-scharpf.de/tmp/smtpex.desc.txt ---------------------------------------------------------------------- >Comment By: Bertram Scharpf (bertramscharpf) Date: 2004-08-08 09:14 Message: Logged In: YES user_id=1097255 Indeed, I did compile python 2.2.1 with Gcc versions 2.95, 3.0 and 3.3. The segfault only occurs in the 2.95 compiled code. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 16:30 Message: Logged In: YES user_id=580910 I cannot reproduce this. I've tested: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. Python 2.3.4 (#2, Jul 5 2004, 09:15:05) [GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2 Python 2.2.3+ (#1, Jun 20 2004, 13:32:48) [GCC 3.3.4 (Debian)] on linux2 The first is the system python on MacOS X, the other two are current Debian packages (python2.3 and python2.2) on Debian stable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003195&group_id=5470 From noreply at sourceforge.net Sun Aug 8 09:20:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 09:20:58 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 09:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) >Assigned to: Tim Peters (tim_one) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-08 03:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised. Doc/lib/libfuncs.tex; new revision: 1.171 Lib/test/test_xrange.py; new revision: 1.2 Objects/rangeobject.c; new revision: 2.53 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-06 01:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 12:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 11:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 11:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 09:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Sun Aug 8 09:58:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 09:59:02 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 11:41 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-08-08 10:58 Message: Logged In: YES user_id=358087 Hangs means the window content does not refresh. I can move it, resize it ... It is killable and task manager show it as "active". ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 23:17 Message: Logged In: YES user_id=593130 By 'hangs' do you mean when viewing the TasKManager Applications list, and killable with its End Task button? or something more evil, like locks the computer and prevents rebooting? Even Outlook Express and Internet Explore, with MS's billions, still do the former. With Win95, 98, and XP home and pro, I have had several problems, often intermittent, and maybe hardware specific, with bad interactions between programs, screen savers, and stand-by. On LCDs (and, I believe, modern CRTs) 'screen savers' save nothing except the boredom of a constant picture. I would turn it off and also check screen properites/screensaver/power button and the bios to see if anything is scheduled to happen at 2 hours. The timing, if consistent, is definitely suspicious. A major change for Windows between 2.3.4 and 2.4 is the compiler 'upgrade' which could change a program's interaction with Windows and its vulnerability to bugs within. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 11:11 Message: Logged In: YES user_id=358087 1. "Pure" Python (without IDLE) don't hang after 2 hours 2. I didn't try this time but I'm pretty sure it hanged without screen saver as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-04 04:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 12:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 11:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Sun Aug 8 11:45:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 11:45:36 2004 Subject: [ python-Bugs-948881 ] texi2html.py not working Message-ID: Bugs item #948881, was opened at 2004-05-06 01:42 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=948881&group_id=5470 Category: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: texi2html.py not working Initial Comment: Tools/scripts/texi2html.py have several syntactic problems(inproper indent level, unclosed brace, etc) and raises a SyntaxError. For example, at line 809 self.write(self.FN_SOURCE_PATTERN % {'id': repr(id)) should read self.write(self.FN_SOURCE_PATTERN % {'id': repr(id)}) Looks like Revision 1.14 to 1.16 introduced these bugs. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-08 11:45 Message: Logged In: YES user_id=469548 Revision 1.17 fixed the SyntaxErrors. It's still not the most robust script but it's basically working again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=948881&group_id=5470 From noreply at sourceforge.net Sun Aug 8 12:23:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 12:23:28 2004 Subject: [ python-Bugs-891637 ] pydoc crashes on a class property Message-ID: Bugs item #891637, was opened at 2004-02-06 09:44 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891637&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc crashes on a class property Initial Comment: [forwarded from http://bugs.debian.org/231202] --- class foo(object): __slots__ = ['_bar'] bar = property(lambda (self): self._bar) def __init__(self, bar): self._bar = bar f = foo(1) assert(f.bar == 1) --- removing the parenthesis around the lambda's parameter avoids the pydoc crash. Python itself doesn't seem to care about the parenthesis. $ python tmp.py # no errors $ pydoc tmp Traceback (most recent call last): File "/usr/bin/pydoc", line 4, in ? pydoc.cli() File "/usr/lib/python2.3/pydoc.py", line 2123, in cli help.help(arg) File "/usr/lib/python2.3/pydoc.py", line 1582, in help elif request: doc(request, 'Help on %s:') File "/usr/lib/python2.3/pydoc.py", line 1375, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/usr/lib/python2.3/pydoc.py", line 283, in document if inspect.ismodule(object): return self.docmodule(*args) File "/usr/lib/python2.3/pydoc.py", line 990, in docmodule contents.append(self.document(value, key, name)) File "/usr/lib/python2.3/pydoc.py", line 284, in document if inspect.isclass(object): return self.docclass(*args) File "/usr/lib/python2.3/pydoc.py", line 1135, in docclass lambda t: t[1] == 'property') File "/usr/lib/python2.3/pydoc.py", line 1087, in spillproperties base = self.document(func, tag, mod) File "/usr/lib/python2.3/pydoc.py", line 285, in document if inspect.isroutine(object): return self.docroutine(*args) File "/usr/lib/python2.3/pydoc.py", line 1177, in docroutine args, varargs, varkw, defaults = inspect.getargspec(object) File "/usr/lib/python2.3/inspect.py", line 656, in getargspec args, varargs, varkw = getargs(func.func_code) File "/usr/lib/python2.3/inspect.py", line 624, in getargs remain[-1] = remain[-1] - 1 IndexError: list index out of range ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-08 12:23 Message: Logged In: YES user_id=469548 First, note that the problem doesn't lie in properties. This crashes as well: foo = lambda (bar): 1 second, Python does care about the parentheses. It just doesn't matter when the lambda has only one argument. Using parentheses creates a sublist instead of a parameter list, as in the following example with normal functions: def foo((bar, baz)): return bar assert(foo((1, 2)) == 1) pydoc (or rather, inspect) should still be fixed though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891637&group_id=5470 From noreply at sourceforge.net Sun Aug 8 13:31:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 13:31:09 2004 Subject: [ python-Bugs-891637 ] pydoc crashes on a class property Message-ID: Bugs item #891637, was opened at 2004-02-06 09:44 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891637&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc crashes on a class property Initial Comment: [forwarded from http://bugs.debian.org/231202] --- class foo(object): __slots__ = ['_bar'] bar = property(lambda (self): self._bar) def __init__(self, bar): self._bar = bar f = foo(1) assert(f.bar == 1) --- removing the parenthesis around the lambda's parameter avoids the pydoc crash. Python itself doesn't seem to care about the parenthesis. $ python tmp.py # no errors $ pydoc tmp Traceback (most recent call last): File "/usr/bin/pydoc", line 4, in ? pydoc.cli() File "/usr/lib/python2.3/pydoc.py", line 2123, in cli help.help(arg) File "/usr/lib/python2.3/pydoc.py", line 1582, in help elif request: doc(request, 'Help on %s:') File "/usr/lib/python2.3/pydoc.py", line 1375, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/usr/lib/python2.3/pydoc.py", line 283, in document if inspect.ismodule(object): return self.docmodule(*args) File "/usr/lib/python2.3/pydoc.py", line 990, in docmodule contents.append(self.document(value, key, name)) File "/usr/lib/python2.3/pydoc.py", line 284, in document if inspect.isclass(object): return self.docclass(*args) File "/usr/lib/python2.3/pydoc.py", line 1135, in docclass lambda t: t[1] == 'property') File "/usr/lib/python2.3/pydoc.py", line 1087, in spillproperties base = self.document(func, tag, mod) File "/usr/lib/python2.3/pydoc.py", line 285, in document if inspect.isroutine(object): return self.docroutine(*args) File "/usr/lib/python2.3/pydoc.py", line 1177, in docroutine args, varargs, varkw, defaults = inspect.getargspec(object) File "/usr/lib/python2.3/inspect.py", line 656, in getargspec args, varargs, varkw = getargs(func.func_code) File "/usr/lib/python2.3/inspect.py", line 624, in getargs remain[-1] = remain[-1] - 1 IndexError: list index out of range ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-08 13:31 Message: Logged In: YES user_id=469548 This crashes as well: def foo((bar)): return 1 A patch is available at http://python.org/sf/1005466. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-08 12:23 Message: Logged In: YES user_id=469548 First, note that the problem doesn't lie in properties. This crashes as well: foo = lambda (bar): 1 second, Python does care about the parentheses. It just doesn't matter when the lambda has only one argument. Using parentheses creates a sublist instead of a parameter list, as in the following example with normal functions: def foo((bar, baz)): return bar assert(foo((1, 2)) == 1) pydoc (or rather, inspect) should still be fixed though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891637&group_id=5470 From noreply at sourceforge.net Sun Aug 8 13:49:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 13:49:41 2004 Subject: [ python-Bugs-1005078 ] iso-2022-jp crashes Message-ID: Bugs item #1005078, was opened at 2004-08-07 20:10 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005078&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Hye-Shik Chang (perky) Summary: iso-2022-jp crashes Initial Comment: I get Python 2.4a2 (#88, Aug 7 2004, 12:37:23) [GCC 3.3.4 (Debian 1:3.3.4-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> u"a\u9808".encode("iso-2022-jp") Segmentation fault The gdb backtrace is #0 0x4047f45f in jisx0208_encoder (data=0x98080061, length=0xbfffde1c) at /home/martin/work/py2.4/Modules/cjkcodecs/_codecs_iso2022.c:632 #1 0x4047e915 in iso2022_encode (state=0xbfffdec8, config=0x40481964, inbuf=0xbfffde60, inleft=2, outbuf=0xbfffde6c, outleft=20, flags=3) at /home/martin/work/py2.4/Modules/cjkcodecs/_codecs_iso2022.c:187 #2 0x404835f9 in multibytecodec_encode (codec=0x40481be4, state=0xbfffdec8, data=0xbfffdec4, datalen=2550661217, errors=0x1, flags=3) at /home/martin/work/py2.4/Modules/cjkcodecs/multibytecodec.c:432 #3 0x40483e24 in MultibyteCodec_Encode (self=0x4029d070, args=0x98080061, kwargs=0x98080061) at /home/martin/work/py2.4/Modules/cjkcodecs/multibytecodec.c:512 #4 0x081041fe in PyCFunction_Call (func=0x402ce24c, arg=0x402ce12c, kw=0x4052a2a0) at Objects/methodobject.c:77 It crashes on line 632: 632 else TRYMAP_ENC(jisxcommon, coded, *data) { because data does not point to valid memory. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-08 20:49 Message: Logged In: YES user_id=55188 I failed to reproduce the problem on the exactly same compiler and environment. Can you please try a clean build for it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005078&group_id=5470 From noreply at sourceforge.net Sun Aug 8 15:18:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 15:18:17 2004 Subject: [ python-Bugs-1005078 ] iso-2022-jp crashes Message-ID: Bugs item #1005078, was opened at 2004-08-07 13:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005078&group_id=5470 Category: Unicode Group: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Hye-Shik Chang (perky) Summary: iso-2022-jp crashes Initial Comment: I get Python 2.4a2 (#88, Aug 7 2004, 12:37:23) [GCC 3.3.4 (Debian 1:3.3.4-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> u"a\u9808".encode("iso-2022-jp") Segmentation fault The gdb backtrace is #0 0x4047f45f in jisx0208_encoder (data=0x98080061, length=0xbfffde1c) at /home/martin/work/py2.4/Modules/cjkcodecs/_codecs_iso2022.c:632 #1 0x4047e915 in iso2022_encode (state=0xbfffdec8, config=0x40481964, inbuf=0xbfffde60, inleft=2, outbuf=0xbfffde6c, outleft=20, flags=3) at /home/martin/work/py2.4/Modules/cjkcodecs/_codecs_iso2022.c:187 #2 0x404835f9 in multibytecodec_encode (codec=0x40481be4, state=0xbfffdec8, data=0xbfffdec4, datalen=2550661217, errors=0x1, flags=3) at /home/martin/work/py2.4/Modules/cjkcodecs/multibytecodec.c:432 #3 0x40483e24 in MultibyteCodec_Encode (self=0x4029d070, args=0x98080061, kwargs=0x98080061) at /home/martin/work/py2.4/Modules/cjkcodecs/multibytecodec.c:512 #4 0x081041fe in PyCFunction_Call (func=0x402ce24c, arg=0x402ce12c, kw=0x4052a2a0) at Objects/methodobject.c:77 It crashes on line 632: 632 else TRYMAP_ENC(jisxcommon, coded, *data) { because data does not point to valid memory. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-08 15:18 Message: Logged In: YES user_id=21627 I can't reproduce it either now ... closing it. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-08 13:49 Message: Logged In: YES user_id=55188 I failed to reproduce the problem on the exactly same compiler and environment. Can you please try a clean build for it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005078&group_id=5470 From noreply at sourceforge.net Sun Aug 8 15:22:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 15:22:32 2004 Subject: [ python-Bugs-1005308 ] _XOPEN_SOURCE issue on IRIX 5.3 Message-ID: Bugs item #1005308, was opened at 2004-08-08 01:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: _XOPEN_SOURCE issue on IRIX 5.3 Initial Comment: On IRIX 5.3 /usr/include/sys/types.h contains: #if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /* * Nested include for BSD/sockets source compatibility. * (The select macros used to be defined here). */ #include #endif sys/bsd_types.h however defines u_int. If _XOPEN_SOURCE is defined (in pyconfig.h) this results in u_int not being known and the compilation to fail. One way to get around this is to change configure as follows (similarly as it is already being done for some other OSes, it seems...): --- configure.orig 2004-08-08 00:18:33.000000000 + 0200 +++ configure 2004-08-08 00:18:59.000000000 +0200 @@ -1466,6 +1466,8 @@ # has another value. By not (re)defining it, the defaults come in place. AIX/4) define_xopen_source=no;; + IRIX/5.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes I am not sure if this is the best way to solve that problem though. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-08 15:22 Message: Logged In: YES user_id=21627 Will it build correctly if you define _BSD_TYPES or _BSD_COMPAT? What is the difference between these two (i.e. which one is less intrusive)? Get these defined directly, or would we have to define something else which in turn causes _BSD_TYPES (say) to be defined? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 From noreply at sourceforge.net Sun Aug 8 15:56:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 15:57:03 2004 Subject: [ python-Bugs-948881 ] texi2html.py not working Message-ID: Bugs item #948881, was opened at 2004-05-06 09:42 Message generated for change (Settings changed) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=948881&group_id=5470 Category: Demos and Tools Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: texi2html.py not working Initial Comment: Tools/scripts/texi2html.py have several syntactic problems(inproper indent level, unclosed brace, etc) and raises a SyntaxError. For example, at line 809 self.write(self.FN_SOURCE_PATTERN % {'id': repr(id)) should read self.write(self.FN_SOURCE_PATTERN % {'id': repr(id)}) Looks like Revision 1.14 to 1.16 introduced these bugs. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-08 19:45 Message: Logged In: YES user_id=469548 Revision 1.17 fixed the SyntaxErrors. It's still not the most robust script but it's basically working again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=948881&group_id=5470 From noreply at sourceforge.net Sun Aug 8 15:58:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 15:58:51 2004 Subject: [ python-Bugs-1005248 ] new.code() not cleanly checking its arguments Message-ID: Bugs item #1005248, was opened at 2004-08-08 06:01 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: new.code() not cleanly checking its arguments Initial Comment: new.code() does not check its arguments properly: >>> new.code(1,1,1,0,"123",(None,),(5,),(5,),"123","321",2,"") Fatal Python error: non-string found in code slot Here the tuple (5,) is used for co_names and co_varnames. More generally it looks like this part of compile.c could do with quite some cleaning up. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-08 23:58 Message: Logged In: YES user_id=29957 I thought there was a general concensus that many things in the 'new' module could be used to make a mess, and that trying to fix them all was a pretty much open-ended task? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 From noreply at sourceforge.net Sun Aug 8 19:32:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 19:32:43 2004 Subject: [ python-Bugs-1005308 ] _XOPEN_SOURCE issue on IRIX 5.3 Message-ID: Bugs item #1005308, was opened at 2004-08-08 01:10 Message generated for change (Comment added) made by gschwarz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: _XOPEN_SOURCE issue on IRIX 5.3 Initial Comment: On IRIX 5.3 /usr/include/sys/types.h contains: #if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /* * Nested include for BSD/sockets source compatibility. * (The select macros used to be defined here). */ #include #endif sys/bsd_types.h however defines u_int. If _XOPEN_SOURCE is defined (in pyconfig.h) this results in u_int not being known and the compilation to fail. One way to get around this is to change configure as follows (similarly as it is already being done for some other OSes, it seems...): --- configure.orig 2004-08-08 00:18:33.000000000 + 0200 +++ configure 2004-08-08 00:18:59.000000000 +0200 @@ -1466,6 +1466,8 @@ # has another value. By not (re)defining it, the defaults come in place. AIX/4) define_xopen_source=no;; + IRIX/5.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes I am not sure if this is the best way to solve that problem though. ---------------------------------------------------------------------- >Comment By: Georg Schwarz (gschwarz) Date: 2004-08-08 19:32 Message: Logged In: YES user_id=951222 On IRIX 5.3 unter /usr/include _BSD_TYPES occurs as follows: /usr/include/sys/time.h:#if !defined(_POSIX_SOURCE) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/sys/types.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/unistd.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) Therefore it seems pretty harmless to define _BSD_TYPEs. I manually did so by adding -D_BSD_TYPES to OPT= in the toplevel Makefile. With this modification python 2.3.4 compiles even with _XOPEN_SOURCE defined. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-08 15:22 Message: Logged In: YES user_id=21627 Will it build correctly if you define _BSD_TYPES or _BSD_COMPAT? What is the difference between these two (i.e. which one is less intrusive)? Get these defined directly, or would we have to define something else which in turn causes _BSD_TYPES (say) to be defined? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 From noreply at sourceforge.net Sun Aug 8 19:58:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 19:58:51 2004 Subject: [ python-Bugs-1005568 ] _SC_PAGE_SIZE unknown on IRIX 5.3 Message-ID: Bugs item #1005568, was opened at 2004-08-08 19:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005568&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: _SC_PAGE_SIZE unknown on IRIX 5.3 Initial Comment: Modules/resource.c expects _SC_PAGE_SIZE to be known if HAVE_SYSCONF is defined. IRIX 5.3 however knows only _SC_PAGESIZE (defined in unistd.h), not _SC_PAGE_SIZE, so compilation (as part of make test) fails. I would assume that some file in Lib/plat-irix5 should get a similar definition as in the case of Lib/plat- unixware7 or Lib/plat-sunos5, maybe. Alternatively adding the following to Modules/resource.c might help: #ifndef _SC_PAGE_SIZE #define _SC_PAGE_SIZE _SC_PAGESIZE #endif (this assumes of course that at least _SC_PAGESIZE is defined) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005568&group_id=5470 From noreply at sourceforge.net Sun Aug 8 20:09:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 8 20:09:42 2004 Subject: [ python-Bugs-1003935 ] xrange overflows Message-ID: Bugs item #1003935, was opened at 2004-08-05 15:16 Message generated for change (Comment added) made by hfuru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 >Category: Python Interpreter Core Group: Python 2.3 >Status: Open >Resolution: None Priority: 5 Submitted By: Hallvard B Furuseth (hfuru) Assigned to: Tim Peters (tim_one) Summary: xrange overflows Initial Comment: These restrictions are undocumented both in the xrange doc string and in the reference manual (Info node 'XRange Type'): >>> xrange(maxint, maxint + 10) Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to int >>> xrange(-100, maxint) Traceback (most recent call last): File "", line 1, in ? OverflowError: xrange() result has too many items I hope the overflows below are bugs and not features. It works if 3/-3 is replaced with 1/-1: >>> xrange(0, maxint, 3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(0, -maxint, -3) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition Python installation: Python 2.3.3 (#1, May 25 2004, 20:22:36) [GCC 3.2.3] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from sys import maxint >>> "%x" % maxint '7fffffff' ---------------------------------------------------------------------- >Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-08 20:09 Message: Logged In: YES user_id=726647 Here is why repr() is relevant - though the error message was certainly weird. With the latest CVS version: >>> xrange(maxint-1, maxint, 2) xrange(2147483646, -2147483648, 2) Which is why I suggested to return last+step/abs(step) as the 2nd argument. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-08 09:20 Message: Logged In: YES user_id=31435 Changed range_new() to stop using PyRange_New(). This fixes a variety of bogus errors. Documented that xrange() is intended to be simple and fast, and that CPython restricts its arguments, and length of its result sequence, to native C longs. Added some tests that failed before the patch, and repaired a test that relied on a bogus OverflowError getting raised. Doc/lib/libfuncs.tex; new revision: 1.171 Lib/test/test_xrange.py; new revision: 1.2 Objects/rangeobject.c; new revision: 2.53 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-06 07:10 Message: Logged In: YES user_id=31435 It looks like there are two bugs here. One is that the "integer addition" detail doesn't make sense, since the user isn't doing any integer addition here (sorry, no, repr() is irrelevant to this). Second, it shouldn't be complaining in the last two cases at alll. If the numbers truly were out of range, then rangeobject.c's range_new() would have raised a "too many items" exception. Note: >>> from sys import maxint as m >>> xrange(0, m, 2) Traceback (most recent call last): File "", line 1, in ? OverflowError: integer addition >>> xrange(-m, m, 2) xrange(-2147483647, 2147483647, 2) >>> The second xrange() there contains twice as many items as the first one, but doesn't complain. It's code in PyRange_New () that's making the bogus complaint, and I can't figure out what it thinks it's doing. The code in get_len_of_range() is correct. The code in PyRange_New() is both overly permissive (e.g., it silently lets "(len - 1) * step" overflow), and overly restrictive (e.g, I can't see why it should matter if "last > (PyInt_GetMax () - step))" -- the only thing in that specific branch that *should* matter is whether the integer addition "start + (len - 1) * step" overflowed (which it isn't checking for correctly, even assuming the multiplication didn't overflow). The obvious fix for xrange() is to speed range_new() by throwing away its call to the broken PyRange_New(). range_new() is already doing a precise job of checking for "too big", and already knows everything it needs to construct the right rangeobject. That would leave the PyRange_New() API call with broken overflow checking, but it's not called from anywhere else in the core. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 18:42 Message: Logged In: YES user_id=726647 The only reason I can see that xrange(0, maxint, 3) gives integer overflow is that repr() returns 'xrange(first, last + step, step)', where last + step would be too large. I suggest repr() is changed to return 'xrange(first, last + step/abs(step), step)'. ---------------------------------------------------------------------- Comment By: Hallvard B Furuseth (hfuru) Date: 2004-08-05 17:14 Message: Logged In: YES user_id=726647 > Do you have a real use case for this? For the 'hopefully bugs' variants, yes: #1: Loop forever: for i in xrange(x, sys.maxint, y) That's a lot faster than i = x while True: ... i += y #2: 'loop until optional upper bound': def some_loop(start, end = sys.maxint): for i in xrange(start, end, whatever()) > Do any real apps need to loop over more than > sys.maxint integers? The answer may be yes nowadays. Even my old Solaris can find primes up to maxint/2 in just 2 hours. That's a loop over maxint/4 integers. Though the remaining 3/4 come slower:-) Still, I expect variants of the above code would be less uncommon, like some_loop(-100). > It would be ashamed to muckup the high > performance implementation for something that > does not arise in practice. I hope you do not mean xrange(0, maxint, 3). If you mean xrange(-100, maxint): Maybe xrange could be split in several types (fast and slower) and the xrange() operator would return one of these, similar to how int() now can return long? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-05 17:12 Message: Logged In: YES user_id=21627 The OverflowErrors are definitely intentional, and by design. xrange() is documented as working the same way as range(), so any error in the documentation is an error in the range() documentation. Reclassifying this as a documentation bug. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-05 15:49 Message: Logged In: YES user_id=80475 Do you have a real use case for this? Do any real apps need to loop over more than sys.maxint integers? It would be ashamed to muckup the high performance implementation for something that does not arise in practice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003935&group_id=5470 From noreply at sourceforge.net Mon Aug 9 04:36:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 04:36:35 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 14:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: roadkill (dharma_roadkill) Assigned to: Nobody/Anonymous (nobody) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Mon Aug 9 06:05:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 06:05:59 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 11:36 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: roadkill (dharma_roadkill) >Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Mon Aug 9 07:10:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 07:10:19 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 11:36 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 14:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Mon Aug 9 10:15:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 10:16:05 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 03:36 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-09 09:15 Message: Logged In: YES user_id=200117 I am getting slightly different errors on HP-UX 11i using the native C compiler 'cc'. building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 120: error 1578: Size of struct or union member is unknown. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1058: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1064: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1070: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1078: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1085: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1091: error 1523: Too many initializers. uname -a HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 06:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Mon Aug 9 10:31:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 10:31:11 2004 Subject: [ python-Bugs-1004271 ] imaplib.IMAP4.select doesn't return critical data Message-ID: Bugs item #1004271, was opened at 2004-08-06 09:53 Message generated for change (Comment added) made by pierslauder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004271&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Piers Lauder (pierslauder) Summary: imaplib.IMAP4.select doesn't return critical data Initial Comment: The .select() method of IMAP4 objects returns the EXISTS data, but not the more-critical UIDVALIDITY data. Without UIDVALIDITY, the UID command is useless. I have a patch, but it changes the API of the .select() method, so it's unlikely to go into mainline -- and select() also fails to return two other data items from the SELECT command (FLAGS and RECENT). ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2004-08-09 18:31 Message: Logged In: YES user_id=196212 I think it unwise to change the API at this stage. Also, there is a reasonable process to obtain the values you need after the `select' call: which is to use the `response' method, as in: typ, EXISTS = instance.select(...) if typ == 'OK': FLAGS = instance.response('FLAGS') UIDVALIDITY = instance.response('UIDVALIDITY') RECENT = instance.response('RECENT') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004271&group_id=5470 From noreply at sourceforge.net Mon Aug 9 11:58:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 11:59:10 2004 Subject: [ python-Feature Requests-974019 ] ConfigParser non-string defaults broken with .getboolean() Message-ID: Feature Requests item #974019, was opened at 2004-06-17 02:36 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=974019&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser non-string defaults broken with .getboolean() Initial Comment: ConfigParser.getboolean() fails if it falls back to a default value, and the value passed in was a boolean object (instead of a string) because it unconditionally does v.lower(). This should be fixed; there's something un-Pythonic about expecting a boolean value but not being able to actually provide a boolean as the default. I've attached a patch (against 2.3.4c1; should apply to 2.3.4, I think) which makes the v.lower() conditional on v being a string, and adds bool(True), bool(False), int(1), and int(0) to _boolean_states. Alternative resolution: change the documentation to specify that /only/ strings should be passed in the defaults dictionary. Less Pythonic. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-09 19:58 Message: Logged In: YES user_id=29957 I don't see any reason to not allow a boolean as a default. Raymond's solution seems like a good one to me. Anyone object? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-17 22:37 Message: Logged In: YES user_id=80475 The method is functioning exactly as documented. Changing this to a feature request. FWIW, it seems reasonable to allow a boolean to be passed in a default; however, calling it unpythonic is a bit extreme since the whole API is designed to work with text arguments. My solution would be to just add two lines after the self.get: if isinstance(v, bool): return v ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=974019&group_id=5470 From noreply at sourceforge.net Mon Aug 9 12:01:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 12:01:43 2004 Subject: [ python-Feature Requests-984242 ] Support "hybrid" framework/unix style Message-ID: Feature Requests item #984242, was opened at 2004-07-03 04:24 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=984242&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Support "hybrid" framework/unix style Initial Comment: In the Darwin 8 prerelease sources, Apple decided to actually build Python to /usr/lib and have /System/Library/Frameworks/ Python.framework/Versions/2.3/Python be a symlink to that. /usr/ include/python2.3/ is a symlink to inside the framework. We should probably support this build style. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-09 20:01 Message: Logged In: YES user_id=29957 If you have access to this version, care to work up a patch? Without access to the particular version, it's hard to test... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=984242&group_id=5470 From noreply at sourceforge.net Mon Aug 9 12:05:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 12:05:29 2004 Subject: [ python-Feature Requests-984242 ] Support "hybrid" framework/unix style Message-ID: Feature Requests item #984242, was opened at 2004-07-02 14:24 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=984242&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Support "hybrid" framework/unix style Initial Comment: In the Darwin 8 prerelease sources, Apple decided to actually build Python to /usr/lib and have /System/Library/Frameworks/ Python.framework/Versions/2.3/Python be a symlink to that. /usr/ include/python2.3/ is a symlink to inside the framework. We should probably support this build style. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2004-08-09 06:05 Message: Logged In: YES user_id=139309 Their modifications are open source. The changes should be done by someone more familiar than myself with autoconf. It's python-11 on http://www.opensource.apple.com/darwinsource/ WWDC2004/ ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-09 06:01 Message: Logged In: YES user_id=29957 If you have access to this version, care to work up a patch? Without access to the particular version, it's hard to test... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=984242&group_id=5470 From noreply at sourceforge.net Mon Aug 9 12:40:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 12:40:36 2004 Subject: [ python-Bugs-1005248 ] new.code() not cleanly checking its arguments Message-ID: Bugs item #1005248, was opened at 2004-08-07 21:01 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: new.code() not cleanly checking its arguments Initial Comment: new.code() does not check its arguments properly: >>> new.code(1,1,1,0,"123",(None,),(5,),(5,),"123","321",2,"") Fatal Python error: non-string found in code slot Here the tuple (5,) is used for co_names and co_varnames. More generally it looks like this part of compile.c could do with quite some cleaning up. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-09 11:40 Message: Logged In: YES user_id=6656 Maybe new is meant to be scary, but current behaviour is going well above and beyond the effort required. new.code can mutate a tuple containing string subclasses into a tuple containing exact strings! Armin, what do you think of the attached? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-08 14:58 Message: Logged In: YES user_id=29957 I thought there was a general concensus that many things in the 'new' module could be used to make a mess, and that trying to fix them all was a pretty much open-ended task? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 From noreply at sourceforge.net Mon Aug 9 12:54:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 12:54:48 2004 Subject: [ python-Bugs-1005248 ] new.code() not cleanly checking its arguments Message-ID: Bugs item #1005248, was opened at 2004-08-07 20:01 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: new.code() not cleanly checking its arguments Initial Comment: new.code() does not check its arguments properly: >>> new.code(1,1,1,0,"123",(None,),(5,),(5,),"123","321",2,"") Fatal Python error: non-string found in code slot Here the tuple (5,) is used for co_names and co_varnames. More generally it looks like this part of compile.c could do with quite some cleaning up. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-08-09 10:54 Message: Logged In: YES user_id=4771 Why do you check for argcount<0 but not nlocals<0, which also raises a SystemError? More to the point, why on earth does PyCode_New() check for negative values of argcount and nlocals and not the other values? A negative stacksize, for example, is likely to crash the interpreter too. On the other hand, validating these numbers more precisely is much more complex, and not something we're trying to do here. So I don't understand why these two values in particular are checked for < 0. We should as well drop the check altogether. My position here is that calling new.code() shouldn't do anything bad to the interpreter; but actually executing the resulting code object is allowed to destroy the sun (provided, of course, that CPython runs in an environment that allows that). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 10:40 Message: Logged In: YES user_id=6656 Maybe new is meant to be scary, but current behaviour is going well above and beyond the effort required. new.code can mutate a tuple containing string subclasses into a tuple containing exact strings! Armin, what do you think of the attached? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-08 13:58 Message: Logged In: YES user_id=29957 I thought there was a general concensus that many things in the 'new' module could be used to make a mess, and that trying to fix them all was a pretty much open-ended task? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 From noreply at sourceforge.net Mon Aug 9 13:23:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 13:24:00 2004 Subject: [ python-Bugs-1005248 ] new.code() not cleanly checking its arguments Message-ID: Bugs item #1005248, was opened at 2004-08-07 21:01 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: new.code() not cleanly checking its arguments Initial Comment: new.code() does not check its arguments properly: >>> new.code(1,1,1,0,"123",(None,),(5,),(5,),"123","321",2,"") Fatal Python error: non-string found in code slot Here the tuple (5,) is used for co_names and co_varnames. More generally it looks like this part of compile.c could do with quite some cleaning up. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-09 12:23 Message: Logged In: YES user_id=6656 > Why do you check for argcount<0 but not nlocals<0, which > also raises a SystemError? Because I didn't read that far... Obvious extension of patch added. Agree that current behaviour of PyCode_New is a bit crazy. OTOH, not changing PyCode_New itself seems a principle no worse than any other for the moment. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-09 11:54 Message: Logged In: YES user_id=4771 Why do you check for argcount<0 but not nlocals<0, which also raises a SystemError? More to the point, why on earth does PyCode_New() check for negative values of argcount and nlocals and not the other values? A negative stacksize, for example, is likely to crash the interpreter too. On the other hand, validating these numbers more precisely is much more complex, and not something we're trying to do here. So I don't understand why these two values in particular are checked for < 0. We should as well drop the check altogether. My position here is that calling new.code() shouldn't do anything bad to the interpreter; but actually executing the resulting code object is allowed to destroy the sun (provided, of course, that CPython runs in an environment that allows that). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 11:40 Message: Logged In: YES user_id=6656 Maybe new is meant to be scary, but current behaviour is going well above and beyond the effort required. new.code can mutate a tuple containing string subclasses into a tuple containing exact strings! Armin, what do you think of the attached? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-08 14:58 Message: Logged In: YES user_id=29957 I thought there was a general concensus that many things in the 'new' module could be used to make a mess, and that trying to fix them all was a pretty much open-ended task? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 From noreply at sourceforge.net Mon Aug 9 13:55:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 13:55:09 2004 Subject: [ python-Bugs-1000841 ] "make pdf" failure w/ 2.4 docs Message-ID: Bugs item #1000841, was opened at 2004-07-30 13:01 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mat Martineau (martineau) Assigned to: Nobody/Anonymous (nobody) Summary: "make pdf" failure w/ 2.4 docs Initial Comment: When attempting to build the pdf version of the documentation from CVS, I get the following error: (/.../python/dist/src/Doc/lib/libxmlrpclib.tex ... ! TeX capacity exceeded, sorry [input stack size=1500]. \font@name -> \OT1/phv/m/n/10 l.259 ...//www.xmlrpc.com/discuss/msgReader\208} , an approach ! ==> Fatal error occurred, the output PDF file is not finished! The '$' in line 259 of libxmlrpclib.tex seems to trip up pdflatex. If '%24' is substituted for '$', the link still works, and lib.pdf will build. Info about my version of pdflatex & linux: $ pdflatex --version pdfTeX (Web2C 7.4.5) 3.14159-1.10b kpathsea version 3.4.5 ... $ cat /proc/version Linux version 2.6.5-7.95-default (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 Thu Jul 1 15:23:45 UTC 2004 ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-09 06:55 Message: Logged In: YES user_id=2772 mwh: for a fix for the "dist" problem, see python.org/sf/1005913 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 12:41 Message: Logged In: YES user_id=6656 Confirmed, and fixed in the suggested way in Doc/lib/ libxmlrpclib.tex revision 1.17. "make pdf" still chokes, but on dist now. Haven't had a look to see why. aisaac0: you should *really* file another bug for that. ---------------------------------------------------------------------- Comment By: Alan (aisaac0) Date: 2004-07-31 10:02 Message: Logged In: YES user_id=1025672 Hopefully a bug from the 2.3 docs can be fixed at the same time. The PDF production tries to set the vertical bar '|' in textmode rather than math mode. An example of this problem is the documentation for set union, which looks like s--t instead of s|t. Should I submit this as a separate bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470 From noreply at sourceforge.net Mon Aug 9 14:31:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 14:31:56 2004 Subject: [ python-Bugs-1005933 ] imaplib.IMAP4.getquotaroot error Message-ID: Bugs item #1005933, was opened at 2004-08-09 14:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005933&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thierry FLORAC (tflorac) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib.IMAP4.getquotaroot error Initial Comment: I think there is an error in the imaplib.IMAP4.getquotaroot method available in Python 2.3.3 (as actually available in Debian GNU/Linux). In line 446 of file "imaplib.py", we can find : typ, dat = self._simple_command('GETQUOTA', mailbox) Instead and according to RFCs, I think we should have : typ, dat = self._simple_command('GETQUOTAROOT', mailbox) Using Netscape Messaging Server , the first version replies with a "Permission denied" error (while logged in as a common user) ; the second version works correctly : >>> cn.getquotaroot('INBOX') ('OK', [['INBOX user/tflorac'], ['user/tflorac (STORAGE 981 51200)']]) Thanks for your work, Thierry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005933&group_id=5470 From noreply at sourceforge.net Mon Aug 9 14:41:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 14:41:32 2004 Subject: [ python-Bugs-1005936 ] Index entries with "_" are wrong in pdf file Message-ID: Bugs item #1005936, was opened at 2004-08-09 07:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005936&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Index entries with "_" are wrong in pdf file Initial Comment: "make pdf". Open lib.pdf in acrobat reader, or another pdf viewer with the "bookmarks" feature. Open the "Python Language Services" item. Section 18.8 (in CVS) will read "pyprotect unhbox voidb@x kern 0.6emvbox {hrule width.55em}compile --- Compile Python source files" It should read simply "py_compile --- Compile Python source files"---If you visit that section, that's the title shown. I only know enough LaTeX to get myself hurt, but it looks like "_" was converted into a special sequence, and the step that produces the index used the expanded version. It's a fix that would feel icky, but if this sequence "protect ....55em}" was the same everywhere, simply replacing that string with "_" when generating the index would probably get the right results. I first noticed this problem in dist.pdf where many of the module names contained underscores. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005936&group_id=5470 From noreply at sourceforge.net Mon Aug 9 14:45:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 14:45:32 2004 Subject: [ python-Bugs-1005936 ] Index entries with "_" are wrong in pdf file Message-ID: Bugs item #1005936, was opened at 2004-08-09 07:41 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005936&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Index entries with "_" are wrong in pdf file Initial Comment: "make pdf". Open lib.pdf in acrobat reader, or another pdf viewer with the "bookmarks" feature. Open the "Python Language Services" item. Section 18.8 (in CVS) will read "pyprotect unhbox voidb@x kern 0.6emvbox {hrule width.55em}compile --- Compile Python source files" It should read simply "py_compile --- Compile Python source files"---If you visit that section, that's the title shown. I only know enough LaTeX to get myself hurt, but it looks like "_" was converted into a special sequence, and the step that produces the index used the expanded version. It's a fix that would feel icky, but if this sequence "protect ....55em}" was the same everywhere, simply replacing that string with "_" when generating the index would probably get the right results. I first noticed this problem in dist.pdf where many of the module names contained underscores. ---------------------------------------------------------------------- >Comment By: Jeff Epler (jepler) Date: 2004-08-09 07:45 Message: Logged In: YES user_id=2772 This also affects older versions of the documentation, for instance the entries for __builtin__, __main__ and __future__ in Python-letter-2.3.4.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005936&group_id=5470 From noreply at sourceforge.net Mon Aug 9 15:00:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 15:01:05 2004 Subject: [ python-Bugs-995458 ] Does not build selected SGI specific modules Message-ID: Bugs item #995458, was opened at 2004-07-21 13:55 Message generated for change (Comment added) made by brucedray You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bruce D. Ray (brucedray) Assigned to: Nobody/Anonymous (nobody) Summary: Does not build selected SGI specific modules Initial Comment: System is SGI R10K running Irix 6.5.15 Compiler is MIPSpro 7.3 Default configuration build sequence works and installs a python 2.3.4 that does not support GL, audio, etc. because the SGI specific modules for those are not built in the default configuration. To quote the README: On SGI IRIX, there are modules that interface to many SGI specific system libraries, e.g. the GL library and the audio hardware. These modules will not be built by the setup.py script. Therefore, after the default configuration build and install, I uncommented the lines in Modules/Setup that read: gl glmodule.c cgensupport.c -I$(srcdir) $(GLHACK) -lgl -lX11 fm fmmodule.c $(GLHACK) -lfm -lgl sgi sgimodule.c al almodule.c -laudio cd cdmodule.c -lcdaudio -lds -lmediad cl clmodule.c -lcl -lawareaudio fpectl fpectlmodule.c -lfpe fpetest fpetestmodule.c I then did a make clean followed by make Errors returned were: cc -o python Modules/python.o libpython2.3.a -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/mips4/libmpc.a is not used for resolving any symbol. ld32: ERROR 33 : Unresolved text symbol "initgl" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initfm" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initsgi" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "inital" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initcd" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initcl" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initfpectl" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initfpetest" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: INFO 152: Output file removed because of error. *** Error code 2 (bu21) A previous message on the build said that I would have to rerun make Therefore, I again did a make clean followed by make and got the error message: don't know how to make glmodule.c How is this build to be done? ---------------------------------------------------------------------- >Comment By: Bruce D. Ray (brucedray) Date: 2004-08-09 08:00 Message: Logged In: YES user_id=1063363 I believe I have listed a bug in the build and what would appear to be a problem in documentation as well. These are: 1. When the lines listed previously in Modules/Setup for SGI specific modules are uncommented, there appears to be a problem in the construction of the Makefile that points the build away from the SGI specific modules to be built. The result of this is a total failure to build python 2.3.4 with SGI specific modules with error messages as given previously. 2. Documentation on the general issue of use of Modules/Setup to build modules not otherwise built is not adequate. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 12:55 Message: Logged In: YES user_id=11375 So what exactly is the bug? ---------------------------------------------------------------------- Comment By: Bruce D. Ray (brucedray) Date: 2004-07-30 09:00 Message: Logged In: YES user_id=1063363 Would that be something like the message () I posted to comp.lang.python 15 Jul. 2004? I posted that back before I managed to tease out of the various convolutions of the build hints that there might be a problem in the construction of a Makefile that points the build to the wrong directory. As hinted at in that article, I had already done a search of the publicly available documentation on python (actually several searches including a download and grep of these). I also did searches of comp.lang.python for anything related to SGI, Silicon Graphics, or Irix; and of comp.sys.sgi.* for anything related to python (if you wish to reproduce this, you might want to exclude the strings "dat" and "tape" because of the many queries there on how to use a Python brand drive for archiving). By 21 Jul. 2004, when I opened this, I was persuaded that I have found a bug in the build, or at least a deficiency in the documentation for build and install. I believe that I have found a bug in the distribution with respect to building on SGI with MIPSpro 7.3 compilers a python with support for available SGI functionality. Thank-you kindly for your reply, but I really am reporting what appears to be a bug. Accordingly, I will leave this open. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-07-29 18:14 Message: Logged In: YES user_id=593130 The appropriate place for how-to questions is comp.lang.python and the corresponding mailing list. Please consider closing this until you are fairly sure you have found a bug in the distribution itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470 From noreply at sourceforge.net Mon Aug 9 15:31:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 15:31:38 2004 Subject: [ python-Bugs-1001857 ] socketmodule does not build under cygwin Message-ID: Bugs item #1001857, was opened at 2004-08-02 00:26 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Jason Tishler (jlt63) Summary: socketmodule does not build under cygwin Initial Comment: There are latest sources from CVS ./configure disables socket module When adding it manually in Modules/Setup the following error occures: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c:134: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c:134: warning: its scope is only this definition or declaration, which is probably not what you want Modules/getaddrinfo.c:136: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_gai_strerror': Modules/getaddrinfo.c:204: error: `EAI_MAX' undeclared (first use in this function) Modules/getaddrinfo.c:204: error: (Each undeclared identifier is reported only once Modules/getaddrinfo.c:204: error: for each function it appears in.) Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:210: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_freeaddrinfo': Modules/getaddrinfo.c:215: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:216: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:217: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c: At top level: Modules/getaddrinfo.c:237: warning: `struct addrinfo' declared inside parameter list Modules/getaddrinfo.c: In function `fake_getaddrinfo': Modules/getaddrinfo.c:239: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:244: error: storage size of `ai' isn't known Modules/getaddrinfo.c:266: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:267: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:268: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:269: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:270: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:271: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:272: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:273: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:277: error: `EAI_NONAME' undeclared (first use in this function) Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:280: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:281: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:282: error: `EAI_BADHINTS' undeclared (first use in this function) Modules/getaddrinfo.c:283: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:283: error: `AI_MASK' undeclared (first use in this function) Modules/getaddrinfo.c:284: error: `EAI_BADFLAGS' undeclared (first use in this function) Modules/getaddrinfo.c:285: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:293: error: `EAI_FAMILY' undeclared (first use in this function) Modules/getaddrinfo.c:295: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:296: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:298: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:302: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:305: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:308: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:315: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:316: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:318: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:321: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:322: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:324: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:327: error: `EAI_SOCKTYPE' undeclared (first use in this function) Modules/getaddrinfo.c:337: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:339: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:340: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:348: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:363: error: `EAI_SERVICE' undeclared (first use in this function) Modules/getaddrinfo.c:365: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:367: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:368: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:370: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:371: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:373: error: `EAI_PROTOCOL' undeclared (first use in this function) Modules/getaddrinfo.c:387: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:388: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:392: error: `AI_PASSIVE' undeclared (first use in this function) Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:393: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:399: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:404: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:426: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:429: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:440: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:441: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:442: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:443: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:455: warning: passing arg 3 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:455: warning: passing arg 5 of `get_name' from incompatible pointer type Modules/getaddrinfo.c:462: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:462: error: `AI_NUMERICHOST' undeclared (first use in this function) Modules/getaddrinfo.c:466: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:466: warning: passing arg 3 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:466: warning: passing arg 4 of `get_addr' from incompatible pointer type Modules/getaddrinfo.c:473: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:477: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:239: warning: unused variable `sentinel' Modules/getaddrinfo.c:244: warning: unused variable `ai' In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_name': Modules/getaddrinfo.c:491: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:491: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:134: error: prototype declaration Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:506: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:507: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: invalid use of undefined type `struct addrinfo' Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:509: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:519: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type In file included from Modules/socketmodule.c:312: Modules/getaddrinfo.c: In function `get_addr': Modules/getaddrinfo.c:536: error: argument `res' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:536: error: argument `pai' doesn't match prototype Modules/getaddrinfo.c:136: error: prototype declaration Modules/getaddrinfo.c:538: error: storage size of `sentinel' isn't known Modules/getaddrinfo.c:562: error: `EAI_NODATA' undeclared (first use in this function) Modules/getaddrinfo.c:565: error: `EAI_AGAIN' undeclared (first use in this function) Modules/getaddrinfo.c:569: error: `EAI_FAIL' undeclared (first use in this function) Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: invalid application of `sizeof' to an incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:616: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:618: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `AI_CANONNAME' undeclared (first use in this function) Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:619: error: `EAI_MEMORY' undeclared (first use in this function) Modules/getaddrinfo.c:621: error: dereferencing pointer to incomplete type Modules/getaddrinfo.c:630: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/getaddrinfo.c:538: warning: unused variable `sentinel' In file included from Modules/socketmodule.c:316: Modules/getnameinfo.c: In function `fake_getnameinfo': Modules/getnameinfo.c:138: error: `NI_NUMERICSERV' undeclared (first use in this function) Modules/getnameinfo.c:144: error: `NI_DGRAM' undeclared (first use in this function) Modules/getnameinfo.c:157: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/getnameinfo.c:188: error: `NI_NOFQDN' undeclared (first use in this function) Modules/getnameinfo.c:203: error: `NI_NAMEREQD' undeclared (first use in this function) Modules/socketmodule.c: In function `setipaddr': Modules/socketmodule.c:725: error: storage size of `hints' isn't known Modules/socketmodule.c:736: error: `AI_PASSIVE' undeclared (first use in this function) Modules/socketmodule.c:739: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:750: error: dereferencing pointer to incomplete type Modules/socketmodule.c:760: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:765: error: dereferencing pointer to incomplete type Modules/socketmodule.c:766: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:771: error: dereferencing pointer to incomplete type Modules/socketmodule.c:772: error: dereferencing pointer to incomplete type Modules/socketmodule.c:773: error: dereferencing pointer to incomplete type Modules/socketmodule.c:774: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:811: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:826: error: dereferencing pointer to incomplete type Modules/socketmodule.c:827: error: dereferencing pointer to incomplete type Modules/socketmodule.c:828: error: dereferencing pointer to incomplete type Modules/socketmodule.c:829: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:725: warning: unused variable `hints' Modules/socketmodule.c: In function `makeipaddr': Modules/socketmodule.c:855: error: `NI_NUMERICHOST' undeclared (first use in this function) Modules/socketmodule.c: In function `socket_getaddrinfo': Modules/socketmodule.c:3335: error: storage size of `hints' isn't known Modules/socketmodule.c:3386: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3396: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3398: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3401: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3402: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3403: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3415: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3422: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3335: warning: unused variable `hints' Modules/socketmodule.c: In function `socket_getnameinfo': Modules/socketmodule.c:3443: error: storage size of `hints' isn't known Modules/socketmodule.c:3459: warning: passing arg 4 of `fake_getaddrinfo' from incompatible pointer type Modules/socketmodule.c:3466: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3471: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3494: error: dereferencing pointer to incomplete type Modules/socketmodule.c:3504: warning: passing arg 1 of `fake_freeaddrinfo' from incompatible pointer type Modules/socketmodule.c:3443: warning: unused variable `hints' make: *** [Modules/socketmodule.o] Error 1 ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2004-08-09 05:31 Message: Logged In: YES user_id=86216 Fixed compilation errors with the attached patch. BTW, the socket module builds automatically for me -- there was no need to manually edit Modules/Setup. ---------------------------------------------------------------------- Comment By: Paul D. Lusk (plusk) Date: 2004-08-04 04:36 Message: Logged In: YES user_id=1083789 The getaddrinfo.c errors seem to be similar to those I reported in #991125. (A required header file which resides in the same directory as getaddrinfo.c is in an #if 0 block. Fix that and getaddrinfo.c builds correctly). ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-08-03 23:41 Message: Logged In: YES user_id=552329 I get exactly the same results as tebeka, FWIW. (make works fine, but doesn't build the module, then uncommenting the line gives the above error). ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 22:40 Message: Logged In: YES user_id=358087 When running "./configure --prefix=/usr" python is built OK, but socketmodule (_socket.dll) is not build. There is no message on that. By "adding manually" I mean uncommeting the socketmodule line in Modules/Setup and then running "make". Then the build system tries to build socketmodule and fails with the above error. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 11:21 Message: Logged In: YES user_id=21627 Got the file in email now; 290k is too large for an SF attachment. However, I still cannot find out what you mean by "./configure disables socket module". What message that you got are you referring to, and what specifically did you do to "add it manually"? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 09:56 Message: Logged In: YES user_id=358087 Sorry. Hope it's OK now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 08:57 Message: Logged In: YES user_id=21627 Please retry, checking the checkbox. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-03 08:19 Message: Logged In: YES user_id=358087 Attaching the whole log just in case :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-03 05:14 Message: Logged In: YES user_id=21627 Can you report the relevant section from config.log where configure disables sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001857&group_id=5470 From noreply at sourceforge.net Mon Aug 9 15:46:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 15:47:04 2004 Subject: [ python-Bugs-808596 ] leaking snippet Message-ID: Bugs item #808596, was opened at 2003-09-18 15:48 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 Category: None Group: Python 2.3 >Status: Open >Resolution: Later >Priority: 2 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: leaking snippet Initial Comment: Raymond Hettinger found that the following: fd, fname = tempfile.mkstemp() execfile(fname) leaks a reference. TrackRefs sez it's a string. Haven't dug any further. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-09 14:46 Message: Logged In: YES user_id=6656 Reopening, as it turned out interning filenames did do some good. Lowering priority as it isn't a real leak. It's still kinda annoying, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-03 11:25 Message: Logged In: YES user_id=6656 Done, in Python/compile.c revision 2.312. test_pkgimport turned out to be something else (sys.path_importer_cache), so I feel no need to try and be clever with dummy's refcounting today. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 16:11 Message: Logged In: YES user_id=80475 Not interning the filename seems cleanest. Like you, I do not expect that interning provided any real benefit here. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 13:56 Message: Logged In: YES user_id=6656 I've finally worked out what's going on here. It's because compiling the file interns the name of the file being compiled. Now that interned strings are mortal, this isn't a big deal, but it still results in a string being added to and removed from the interned strings dictionary with net result (almost all of the time) of incrementing the refcount on 'dummy' by one. Once in every thousand or so iterations this results in the interned string dictionary being resized and throwing all the references to dummy away, so this isn't a 'real' leak. OTOH, I'd still like to do something about this (as is, test_pkg appears to leak 10 references per run because of this). The simplest thing would be to just plain not intern the filename during compilation (I find it hard to believe that it's of any real benefit). The more invasive solution would be to not do refcounting on dummy (assuming that's even possible) which is a scarier change, but would stop similar problems with other tests (I have a feeling that test_pkgimport appears to be leaking references because of a different incarnation of the same problem). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808596&group_id=5470 From noreply at sourceforge.net Mon Aug 9 16:56:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 16:57:54 2004 Subject: [ python-Bugs-1006001 ] FutureWarning when running regression tests Message-ID: Bugs item #1006001, was opened at 2004-08-09 16:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006001&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: FutureWarning when running regression tests Initial Comment: Python: 2.4a2, windows installer (MSI) OS: WinXP Prog ENG Warning is raised when running regrtest.py: C:\Python23\lib\test\test_format.py:19: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up result = formatstr % args Traceback (most recent call last): File "C:\Python24\Lib\test\regrtest.py", line 1130, in ? main() File "C:\Python24\Lib\test\regrtest.py", line 359, in main e = _ExpectedSkips() File "C:\Python24\Lib\test\regrtest.py", line 1063, in __init__ from test import test_codecmaps_cn, test_codecmaps_jp ImportError: cannot import name test_codecmaps_cn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006001&group_id=5470 From noreply at sourceforge.net Mon Aug 9 17:03:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 17:05:21 2004 Subject: [ python-Bugs-713601 ] site.py breaks if prefix is empty Message-ID: Bugs item #713601, was opened at 2003-04-01 17:40 Message generated for change (Comment added) made by goertzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lalo Martins (lalo) Assigned to: Brett Cannon (bcannon) Summary: site.py breaks if prefix is empty Initial Comment: verified in 2.3a1 and 2.2.2: prefixes = [sys.prefix] if sys.exec_prefix != sys.prefix: prefixes.append(sys.exec_prefix) for prefix in prefixes: if prefix: # do stuff - in particular, define the "sitedir" variable # and add site-packages to the path del prefix, sitedir if sys.prefix == sys.exec_prefix and both are empty (which is the case if you compile with --prefix=/ as for the Gnu OS for example), this will have two unfortunate results: 1. site-packages will not be added to the path. 2. site.py will abort with a NameError (it tries to del sitedir which isn't defined) The fix seems to be as simple as removing the "if prefix" line. From mailing list archives, it seems to have been added to cope with unusual loading environments related to windows and COM - in this case, there is probably a safer way to check for this condition. If the prefix is empty, this just means it's the root, and no further assumptions should be made. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-08-09 10:03 Message: Logged In: YES user_id=843814 Not too sure what you mean by maintenance branch, but 2.3.4 and today's CVS python/dist/src tree still produced an empty string for sys.prefix when configured with --prefix=/ FYI, I install my root pefix python into a separate directory by running "make install prefix=mydir". "mydir" is the root filesystem for an embedded device that we make. For testing, I chroot to mydir and can run python. The overall procedure is: ./configure --prefix=/ make make install prefix=mydir chroot mydir python I don't think the install and chroot shenanigans make any difference, but I thought I'd mention it in case I'm doing something dumb. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 16:39 Message: Logged In: YES user_id=357491 I just tried compiling on the 2.3 maintenance branch with --prefix=/ and I had sys.prefix be set to '/'. Can you check to see if you are still having sys.prefix set to an empty string? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 14:58 Message: Logged In: YES user_id=357491 The NameError problem has been fixed. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 14:09 Message: Logged In: YES user_id=843814 See this patch: 931938 prefix and exec_prefix as root dir bug ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 11:01 Message: Logged In: YES user_id=843814 Just ran into the same problem when I configure with --prefix=/ The problem is in getpath.c. Before trying to find your lib/python dir based on what you submitted in configure, it performs a search based on the python execution path (probably /bin). It keeps chopping the path down with the reduce() function and then adds "/lib/python" and sees if a landmark file is there. The problem is that reduce() will freely chop away the last / leaving your prefix as a null string. I'm going to try tweaking reduce() so it doesn't hack off the last / if its the last one. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-08 17:54 Message: Logged In: YES user_id=357491 Why is sys.prefix == '' if it is set to '/' as the command-line argument? Checking Modules/getpath.c there appears a few places where things could go awry if an enviroment variable is set that causes the code to think it has already found the location before it reaches what the Makefile set PREFIX and EXEC_PREFIX to. The steps used are in the initial comment of the file. Any of those a possible reason for your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 From noreply at sourceforge.net Mon Aug 9 18:17:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 18:17:47 2004 Subject: [ python-Bugs-1006056 ] odbc queries with very long strings fail with no exceptions Message-ID: Bugs item #1006056, was opened at 2004-08-09 16:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006056&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) Summary: odbc queries with very long strings fail with no exceptions Initial Comment: #W2K MSSQL 2000 #CREATE TABLE [dbo].[Table1] ( # [Id] [int] NULL , # [Data] [int] NULL #) import dbi, odbc import time myconn = odbc.odbc('DSN=ctbase2; UID=sa; PWD=') mycursor = myconn.cursor() updatelst = [] start = time.time() for i in range(10000): updatelst.append("update table1 set id = %d, data = %d " % (i, i)) stri = " ".join(updatelst) rc = mycursor.execute(stri) myconn.commit() #time.sleep(100) mycursor.close() myconn.close() # When running this script, a very long string is passed to execute. # Only a few first update commands are executed. # (I checked it by reading the data back). # Somehow this is timing dependant. # If sleep is commented out - 480 commands are executed. # If sleep is for 10 sec. - 1600 - 1800 commands are executed. # If sleep is for 100 sec. - 3800 commands are executed. # In all cases no exception is thrown and rc = 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006056&group_id=5470 From noreply at sourceforge.net Mon Aug 9 18:43:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 18:43:33 2004 Subject: [ python-Bugs-985154 ] HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin Message-ID: Bugs item #985154, was opened at 2004-07-04 18:38 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Jason Tishler (jlt63) Summary: HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin Initial Comment: Building 2.3.4 from the tarball, #define HAVE_FDATASYNC 1 appears in the pyconfig.h file, and the build of 'posixmodule' fails with undefined symbol _fdatasync Workaround is to delete the line and proceed, of course, but I've never seen this before when building under cygwin. There is no 'fdatasync' mentioned in any /usr/include/*.h or /usr/local/include/*.h The cygwin installation is kind of a mongrel (4 or 5 upgrades since install, some selective) This is the ID string from the built python: Python 2.3.4 (#2, Jul 4 2004, 22:10:22) [GCC 3.3.1 (cygming special)] on cygwin Let me know of any details of the cygwin install which might be useful. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2004-08-09 08:43 Message: Logged In: YES user_id=86216 There has been no follow-up from Greg in a month. OK to close? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2004-07-08 03:10 Message: Logged In: YES user_id=86216 nnorwitz> Jason, do you know what the deal is with cygwin? AFAICT, Greg's Cygwin setup seems suspect. Actually, he alluded to this fact in the following: gregsmith> The cygwin installation is kind of a mongrel... On my Cygwin setup (i.e., 1.5.10-3), I have the following: /usr/include/sys/unistd.h: #ifndef __CYGWIN__ int _EXFUN(fdatasync, (int __fd)); #endif pyconfig.h: /* Define if you have the 'fdatasync' function. */ /* #undef HAVE_FDATASYNC */ Additionally, the official Cygwin Python package built cleanly. Greg, what version of Cygwin are you using? If not 1.5.10-3, then please upgrade and try again. If so, then your setup seems to be corrupted. Try reinstalling. Does it work any better now? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-07 17:32 Message: Logged In: YES user_id=33168 Jason, do you know what the deal is with cygwin? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-07 03:12 Message: Logged In: YES user_id=6656 Well, I guess that's an arguable bug in cygwin, but if you want to supply a patch that modifies configure to do the linking test too, I'll at least think about applying it :-) ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2004-07-05 17:58 Message: Logged In: YES user_id=292741 looked into config.log and 'configure' itself.. the compile for fdatasync succeeded, but the script does not attempt to link it. gcc -E led me to the following chunk of /usr/include/sys/unistd.h: (not inside any #ifdefs, as far as I can tell) int _EXFUN(fdatasync, (int __fd)); So it's declared in the header, but it's not in the library. This symbol is defined in libc.a on a RH8.0 system, I can't find it anywhere on the cygwin system. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-05 05:40 Message: Logged In: YES user_id=6656 That's odd. Why does configure think you have fdatasync? Maybe config.log will help... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470 From noreply at sourceforge.net Mon Aug 9 19:32:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 19:32:29 2004 Subject: [ python-Bugs-624893 ] pydoc shows tools/scripts but blows up Message-ID: Bugs item #624893, was opened at 2002-10-17 17:17 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624893&group_id=5470 Category: Demos and Tools Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc shows tools/scripts but blows up Initial Comment: pydoc (at least on win32 2.2.2) offers the tools/scripts files, but it blows up on several that are not prepared to be used as modules (including, I think, pydocgui, which may well be a special case). I suggest changing the scripts to use the "if __name__ == '__main__':" magic on those that blow up. Sorry I don't have a full list at the moment, I'll remedy that this weekend. Less vital, but still desirable, would be to do the same for those scripts, like byteyears, that perform some action and simply yield an error message. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-09 13:32 Message: Logged In: YES user_id=11375 Fixed by committing patch #1005491 ; thanks for your bug report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624893&group_id=5470 From noreply at sourceforge.net Mon Aug 9 19:32:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 19:32:54 2004 Subject: [ python-Bugs-624893 ] pydoc shows tools/scripts but blows up Message-ID: Bugs item #624893, was opened at 2002-10-17 17:17 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624893&group_id=5470 Category: Demos and Tools Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott David Daniels (scott_daniels) >Assigned to: A.M. Kuchling (akuchling) Summary: pydoc shows tools/scripts but blows up Initial Comment: pydoc (at least on win32 2.2.2) offers the tools/scripts files, but it blows up on several that are not prepared to be used as modules (including, I think, pydocgui, which may well be a special case). I suggest changing the scripts to use the "if __name__ == '__main__':" magic on those that blow up. Sorry I don't have a full list at the moment, I'll remedy that this weekend. Less vital, but still desirable, would be to do the same for those scripts, like byteyears, that perform some action and simply yield an error message. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-09 13:32 Message: Logged In: YES user_id=11375 Fixed by committing patch #1005491 ; thanks for your bug report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=624893&group_id=5470 From noreply at sourceforge.net Mon Aug 9 19:33:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 19:33:24 2004 Subject: [ python-Bugs-1005933 ] imaplib.IMAP4.getquotaroot error Message-ID: Bugs item #1005933, was opened at 2004-08-09 08:31 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005933&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thierry FLORAC (tflorac) >Assigned to: Piers Lauder (pierslauder) Summary: imaplib.IMAP4.getquotaroot error Initial Comment: I think there is an error in the imaplib.IMAP4.getquotaroot method available in Python 2.3.3 (as actually available in Debian GNU/Linux). In line 446 of file "imaplib.py", we can find : typ, dat = self._simple_command('GETQUOTA', mailbox) Instead and according to RFCs, I think we should have : typ, dat = self._simple_command('GETQUOTAROOT', mailbox) Using Netscape Messaging Server , the first version replies with a "Permission denied" error (while logged in as a common user) ; the second version works correctly : >>> cn.getquotaroot('INBOX') ('OK', [['INBOX user/tflorac'], ['user/tflorac (STORAGE 981 51200)']]) Thanks for your work, Thierry ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005933&group_id=5470 From noreply at sourceforge.net Mon Aug 9 19:39:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 19:39:34 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability still present in 2.3.4 Message-ID: Bugs item #1003471, was opened at 2004-08-04 14:42 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability still present in 2.3.4 Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-09 13:39 Message: Logged In: YES user_id=11375 How would I go about testing the patch? Where can I find code that tickles the bug? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 21:01 Message: Logged In: YES user_id=31435 I checked in the attached patch too. If there's ever another release in the 2.3 line, these patches would make decent backport candidates. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 18:19 Message: Logged In: YES user_id=116409 As tim_one poin ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:15 Message: Logged In: YES user_id=31435 Unassigned myself, since I did all I can here. Someone on Linux should test the patch I attached. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:13 Message: Logged In: YES user_id=31435 I checked in the change to PC/getpathp.c, which is used on Windows. I'm attaching a patch to Modules/getpath.c, which isn't used on Windows (so I can't test it). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 14:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Mon Aug 9 19:56:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 19:56:10 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability still present in 2.3.4 Message-ID: Bugs item #1003471, was opened at 2004-08-04 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability still present in 2.3.4 Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-09 13:56 Message: Logged In: YES user_id=31435 The patch didn't intend to fix a bug that's known to exist. Python 2.0 presumably fixed the bugs here, but in a shaky way, relying on dozens of distinct call sites to establish an undocumented precondition. joinpath() suffers a buffer overrun if the precondition isn't met. The patch verifies that the precondition *is* met, killing the Python process if it's not. That should never happen, but joinpath() is called on so many distinct code paths that "eyeball analysis" is inadequate. To test the patch, change any of joinpath's call sites to violate the precondition, and see that Python dies then. The OP suggested a driver to provoke an envar attack, in the 2004-08-07 14:15 comment. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-09 13:39 Message: Logged In: YES user_id=11375 How would I go about testing the patch? Where can I find code that tickles the bug? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 21:01 Message: Logged In: YES user_id=31435 I checked in the attached patch too. If there's ever another release in the 2.3 line, these patches would make decent backport candidates. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 18:19 Message: Logged In: YES user_id=116409 As tim_one poin ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:15 Message: Logged In: YES user_id=31435 Unassigned myself, since I did all I can here. Someone on Linux should test the patch I attached. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:13 Message: Logged In: YES user_id=31435 I checked in the change to PC/getpathp.c, which is used on Windows. I'm attaching a patch to Modules/getpath.c, which isn't used on Windows (so I can't test it). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 14:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Mon Aug 9 20:26:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 20:26:16 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability still present in 2.3.4 Message-ID: Bugs item #1003471, was opened at 2004-08-04 11:42 Message generated for change (Comment added) made by vacuum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability still present in 2.3.4 Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Kirby Kuehl (vacuum) Date: 2004-08-09 11:26 Message: Logged In: YES user_id=116409 Use the sharefuzz utility that I referenced in another comment. Then call any function that will invoke the joinpath function call. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-09 10:56 Message: Logged In: YES user_id=31435 The patch didn't intend to fix a bug that's known to exist. Python 2.0 presumably fixed the bugs here, but in a shaky way, relying on dozens of distinct call sites to establish an undocumented precondition. joinpath() suffers a buffer overrun if the precondition isn't met. The patch verifies that the precondition *is* met, killing the Python process if it's not. That should never happen, but joinpath() is called on so many distinct code paths that "eyeball analysis" is inadequate. To test the patch, change any of joinpath's call sites to violate the precondition, and see that Python dies then. The OP suggested a driver to provoke an envar attack, in the 2004-08-07 14:15 comment. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-09 10:39 Message: Logged In: YES user_id=11375 How would I go about testing the patch? Where can I find code that tickles the bug? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 18:01 Message: Logged In: YES user_id=31435 I checked in the attached patch too. If there's ever another release in the 2.3 line, these patches would make decent backport candidates. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 15:19 Message: Logged In: YES user_id=116409 As tim_one poin ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:15 Message: Logged In: YES user_id=31435 Unassigned myself, since I did all I can here. Someone on Linux should test the patch I attached. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:13 Message: Logged In: YES user_id=31435 I checked in the change to PC/getpathp.c, which is used on Windows. I'm attaching a patch to Modules/getpath.c, which isn't used on Windows (so I can't test it). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 11:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 11:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 11:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 09:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 08:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Mon Aug 9 20:43:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 20:43:25 2004 Subject: [ python-Bugs-1003471 ] Python 1.5.2 security vulnerability still present in 2.3.4 Message-ID: Bugs item #1003471, was opened at 2004-08-04 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Kuehl (vacuum) Assigned to: Nobody/Anonymous (nobody) Summary: Python 1.5.2 security vulnerability still present in 2.3.4 Initial Comment: First off, I realize that Python 1.5.2 is old, I am just reporting it to be thorough. I was doing a security audit of an application that used this old version of python and found the following bug in the joinpath function. #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 (gdb) bt #0 0xff133bf0 in strncpy () from /usr/lib/libc.so.1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 #2 0x00030604 in search_for_prefix (argv0_path=0xffbff530 "/opt/OPSW/bin", home=0xff3a0840 'A' ...) at ./getpath.c:300 #3 0x00030a48 in calculate_path () at ./getpath.c:481 #4 0x00030e6c in Py_GetProgramFullPath () at ./getpath.c:634 #5 0x0002dcac in _PySys_Init () at sysmodule.c:413 #6 0x0002b414 in Py_Initialize () at pythonrun.c:142 #7 0x0001755c in Py_Main (argc=1, argv=0xffbffcdc) at main.c:245 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 #8 0x000171f0 in main (argc=1, argv=0xffbffcdc) at python.c:12 (gdb) frame 1 #1 0x000304e0 in joinpath (buffer=0x83528 'A' ..., stuff=0x84140 'A' ...) at ./getpath.c:255 255 ./getpath.c: No such file or directory. in ./getpath.c snippet from Python-1.5.2/Modules/getpath.c : static void joinpath(buffer, stuff) char *buffer; char *stuff; { int n, k; if (stuff[0] == SEP) n = 0; else { n = strlen(buffer); if (n > 0 && buffer[n-1] != SEP && n < MAXPATHLEN) buffer[n++] = SEP; } k = strlen(stuff); if (n + k > MAXPATHLEN) k = MAXPATHLEN - n; strncpy(buffer+n, stuff, k); buffer[n+k] = '\0'; } further examining the backtrace: (gdb) print n $1 = 4999 (gdb) print k $2 = -3975 (gdb) print buffer $4 = 0x83528 'A' ... (gdb) print stuff $5 = 0x84140 'A' ... if (n + k > MAXPATHLEN) /* NOTE: MAXPATHLEN is 1024 */ k = MAXPATHLEN - n; /* NOTE: here k is 1024 - 4999 which is the -3975 */ Which of course crashes in strncpy(buffer+n, stuff, k); Thanks, Kirby Kuehl ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-09 14:43 Message: Logged In: YES user_id=31435 vacuum, are you saying that sharefuzz provokes an actual bug in Python 2.4a2? In Python 2.3.4? ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-09 14:26 Message: Logged In: YES user_id=116409 Use the sharefuzz utility that I referenced in another comment. Then call any function that will invoke the joinpath function call. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-09 13:56 Message: Logged In: YES user_id=31435 The patch didn't intend to fix a bug that's known to exist. Python 2.0 presumably fixed the bugs here, but in a shaky way, relying on dozens of distinct call sites to establish an undocumented precondition. joinpath() suffers a buffer overrun if the precondition isn't met. The patch verifies that the precondition *is* met, killing the Python process if it's not. That should never happen, but joinpath() is called on so many distinct code paths that "eyeball analysis" is inadequate. To test the patch, change any of joinpath's call sites to violate the precondition, and see that Python dies then. The OP suggested a driver to provoke an envar attack, in the 2004-08-07 14:15 comment. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-09 13:39 Message: Logged In: YES user_id=11375 How would I go about testing the patch? Where can I find code that tickles the bug? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 21:01 Message: Logged In: YES user_id=31435 I checked in the attached patch too. If there's ever another release in the 2.3 line, these patches would make decent backport candidates. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 18:19 Message: Logged In: YES user_id=116409 As tim_one poin ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:15 Message: Logged In: YES user_id=31435 Unassigned myself, since I did all I can here. Someone on Linux should test the patch I attached. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 15:13 Message: Logged In: YES user_id=31435 I checked in the change to PC/getpathp.c, which is used on Windows. I'm attaching a patch to Modules/getpath.c, which isn't used on Windows (so I can't test it). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:44 Message: Logged In: YES user_id=31435 I'm going to add the panic-check I suggested -- this code is too complicated to have any confidence in "eyeball analysis" over time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=31435 Yup, and rev 1.32 intended to plug the envar attack. ---------------------------------------------------------------------- Comment By: Kirby Kuehl (vacuum) Date: 2004-08-07 14:15 Message: Logged In: YES user_id=116409 by exporting environment variables. Check sharefuzz which can be found here: http://www.atstake.com/research/tools/index.html#vulnerability_scanning ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-07 12:43 Message: Logged In: YES user_id=31435 Pretty compilcated internally. A very similar joinpath still exists. While it's not documented or checked, joinpath's code clearly *assumes* strlen(buffer) <= MAXPATHLEN on entry. But it's called from 25 places, and it's not immediately obvious that all call sites guarantee this on all paths. Rev 1.32 of getpath (for Python 2.0) *intended* to fix buffer overflow problems, mostly by changing unsafe strcpy() calls to strncpy() calls. This is delicate, though. I'd be a lot happier if joinpath verified that n <= MAXPATHLEN on entry, and called Py_FatalError() if not so (converting a buffer overrun into a bug report). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 11:55 Message: Logged In: YES user_id=6656 I'm not sure I understand. How do you get n to be so huge? At any rate, I don't think the bug is present in modern Python, but until I understand how this one was triggered, I'm not prepared to be sure... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1003471&group_id=5470 From noreply at sourceforge.net Mon Aug 9 21:07:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 21:07:44 2004 Subject: [ python-Bugs-1004271 ] imaplib.IMAP4.select doesn't return critical data Message-ID: Bugs item #1004271, was opened at 2004-08-05 17:53 Message generated for change (Comment added) made by melicertes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004271&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Piers Lauder (pierslauder) Summary: imaplib.IMAP4.select doesn't return critical data Initial Comment: The .select() method of IMAP4 objects returns the EXISTS data, but not the more-critical UIDVALIDITY data. Without UIDVALIDITY, the UID command is useless. I have a patch, but it changes the API of the .select() method, so it's unlikely to go into mainline -- and select() also fails to return two other data items from the SELECT command (FLAGS and RECENT). ---------------------------------------------------------------------- >Comment By: Charles (melicertes) Date: 2004-08-09 13:07 Message: Logged In: YES user_id=1064824 Okay, thanks. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2004-08-09 02:31 Message: Logged In: YES user_id=196212 I think it unwise to change the API at this stage. Also, there is a reasonable process to obtain the values you need after the `select' call: which is to use the `response' method, as in: typ, EXISTS = instance.select(...) if typ == 'OK': FLAGS = instance.response('FLAGS') UIDVALIDITY = instance.response('UIDVALIDITY') RECENT = instance.response('RECENT') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004271&group_id=5470 From noreply at sourceforge.net Mon Aug 9 22:19:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 22:19:30 2004 Subject: [ python-Bugs-773351 ] Dubious use of Unicode literals in tutorial Message-ID: Bugs item #773351, was opened at 2003-07-18 02:10 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773351&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gerhard H?ring (ghaering) Assigned to: Gerhard H?ring (ghaering) Summary: Dubious use of Unicode literals in tutorial Initial Comment: "3.1.3 Unicode Strings" contains: >>> u"???" u'\xe4\xf6\xfc' It looks like latin1 is used as encoding for this Unicode literal. This is, however, neither justified by the Python language specification nor by common sense ;-) I'd suggest that this be changed in the tutorial. Furthermore I'd suggest that such use of Unicode literals throw errors instead. I'm assigning it to Martin, because he's one of the Unicode gurus :) ---------------------------------------------------------------------- >Comment By: Gerhard H?ring (ghaering) Date: 2004-08-09 22:19 Message: Logged In: YES user_id=163326 I just read PEP 0263, which says: """ In Python 2.1, Unicode literals can only be written using the Latin-1 based encoding "unicode-escape". """ So the tutorial is correct and the things Martin suggested are only possible improvements to Python, there's no actual bug here. So I'll close this one. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-18 17:04 Message: Logged In: YES user_id=21627 The intended behaviour is that Unicode in the interactive mode "works", and assumes that the actual input is encoded according to the locale's encoding (i.e. sys.stdin.encoding). That isn't implemented, yet (and perhaps not even specified). However, it is most likely the case that this is a doc bug in ref manual, not in the tutorial. For this to work, the interactive mode needs to be able to pass the encoding to the parser, perhaps giving a Unicode object as the argument instead of a byte string (atleast IDLE might want to do that). Passing Unicode objects to eval/exec is for further study, though. ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2003-07-18 11:55 Message: Logged In: YES user_id=163326 Oh, I almost forgot about my original problem. Such behaviour shouldn't be encouraged in the tutorial any longer of course. Maybe I can find a better wording and submit a patch soonish. Now that I understand this better, assignnig this to myself :) ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2003-07-18 11:54 Message: Logged In: YES user_id=163326 I *do* get the warnings when executing scripts, but I do *not* get the warnings at the interactive prompt. Lowering priority accordingly. Feel free to close this if this is indeed the intended behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773351&group_id=5470 From noreply at sourceforge.net Mon Aug 9 22:47:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 22:48:14 2004 Subject: [ python-Bugs-713601 ] site.py breaks if prefix is empty Message-ID: Bugs item #713601, was opened at 2003-04-01 15:40 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lalo Martins (lalo) >Assigned to: Nobody/Anonymous (nobody) Summary: site.py breaks if prefix is empty Initial Comment: verified in 2.3a1 and 2.2.2: prefixes = [sys.prefix] if sys.exec_prefix != sys.prefix: prefixes.append(sys.exec_prefix) for prefix in prefixes: if prefix: # do stuff - in particular, define the "sitedir" variable # and add site-packages to the path del prefix, sitedir if sys.prefix == sys.exec_prefix and both are empty (which is the case if you compile with --prefix=/ as for the Gnu OS for example), this will have two unfortunate results: 1. site-packages will not be added to the path. 2. site.py will abort with a NameError (it tries to del sitedir which isn't defined) The fix seems to be as simple as removing the "if prefix" line. From mailing list archives, it seems to have been added to cope with unusual loading environments related to windows and COM - in this case, there is probably a safer way to check for this condition. If the prefix is empty, this just means it's the root, and no further assumptions should be made. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-09 13:47 Message: Logged In: YES user_id=357491 The 2.3 maintenance branch is the CVS version of the 2.3 tree. But if you tried this against 2.3.4 chances are that is close enough. Unfortunately under OS X I get '/' for sys.prefix and not an empty string so I can't debug this. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-08-09 08:03 Message: Logged In: YES user_id=843814 Not too sure what you mean by maintenance branch, but 2.3.4 and today's CVS python/dist/src tree still produced an empty string for sys.prefix when configured with --prefix=/ FYI, I install my root pefix python into a separate directory by running "make install prefix=mydir". "mydir" is the root filesystem for an embedded device that we make. For testing, I chroot to mydir and can run python. The overall procedure is: ./configure --prefix=/ make make install prefix=mydir chroot mydir python I don't think the install and chroot shenanigans make any difference, but I thought I'd mention it in case I'm doing something dumb. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 14:39 Message: Logged In: YES user_id=357491 I just tried compiling on the 2.3 maintenance branch with --prefix=/ and I had sys.prefix be set to '/'. Can you check to see if you are still having sys.prefix set to an empty string? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:58 Message: Logged In: YES user_id=357491 The NameError problem has been fixed. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 12:09 Message: Logged In: YES user_id=843814 See this patch: 931938 prefix and exec_prefix as root dir bug ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 09:01 Message: Logged In: YES user_id=843814 Just ran into the same problem when I configure with --prefix=/ The problem is in getpath.c. Before trying to find your lib/python dir based on what you submitted in configure, it performs a search based on the python execution path (probably /bin). It keeps chopping the path down with the reduce() function and then adds "/lib/python" and sees if a landmark file is there. The problem is that reduce() will freely chop away the last / leaving your prefix as a null string. I'm going to try tweaking reduce() so it doesn't hack off the last / if its the last one. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-08 15:54 Message: Logged In: YES user_id=357491 Why is sys.prefix == '' if it is set to '/' as the command-line argument? Checking Modules/getpath.c there appears a few places where things could go awry if an enviroment variable is set that causes the code to think it has already found the location before it reaches what the Makefile set PREFIX and EXEC_PREFIX to. The steps used are in the initial comment of the file. Any of those a possible reason for your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 From noreply at sourceforge.net Mon Aug 9 23:38:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 9 23:38:57 2004 Subject: [ python-Bugs-713601 ] site.py breaks if prefix is empty Message-ID: Bugs item #713601, was opened at 2003-04-01 17:40 Message generated for change (Comment added) made by goertzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lalo Martins (lalo) Assigned to: Nobody/Anonymous (nobody) Summary: site.py breaks if prefix is empty Initial Comment: verified in 2.3a1 and 2.2.2: prefixes = [sys.prefix] if sys.exec_prefix != sys.prefix: prefixes.append(sys.exec_prefix) for prefix in prefixes: if prefix: # do stuff - in particular, define the "sitedir" variable # and add site-packages to the path del prefix, sitedir if sys.prefix == sys.exec_prefix and both are empty (which is the case if you compile with --prefix=/ as for the Gnu OS for example), this will have two unfortunate results: 1. site-packages will not be added to the path. 2. site.py will abort with a NameError (it tries to del sitedir which isn't defined) The fix seems to be as simple as removing the "if prefix" line. From mailing list archives, it seems to have been added to cope with unusual loading environments related to windows and COM - in this case, there is probably a safer way to check for this condition. If the prefix is empty, this just means it's the root, and no further assumptions should be made. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-08-09 16:38 Message: Logged In: YES user_id=843814 Refer to patch 931938. Incidentally someone else just complained that I forgot to actually upload the file, so I just put it there today. The patch fixes the prefix search as described in step 3 in the comments of getpath.c. Looking at the code that the patch fixes, it should be pretty easy to see how the reduce() function can chop the path down to an empty string when prefix and exec_prefix are the root directory. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-09 15:47 Message: Logged In: YES user_id=357491 The 2.3 maintenance branch is the CVS version of the 2.3 tree. But if you tried this against 2.3.4 chances are that is close enough. Unfortunately under OS X I get '/' for sys.prefix and not an empty string so I can't debug this. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-08-09 10:03 Message: Logged In: YES user_id=843814 Not too sure what you mean by maintenance branch, but 2.3.4 and today's CVS python/dist/src tree still produced an empty string for sys.prefix when configured with --prefix=/ FYI, I install my root pefix python into a separate directory by running "make install prefix=mydir". "mydir" is the root filesystem for an embedded device that we make. For testing, I chroot to mydir and can run python. The overall procedure is: ./configure --prefix=/ make make install prefix=mydir chroot mydir python I don't think the install and chroot shenanigans make any difference, but I thought I'd mention it in case I'm doing something dumb. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 16:39 Message: Logged In: YES user_id=357491 I just tried compiling on the 2.3 maintenance branch with --prefix=/ and I had sys.prefix be set to '/'. Can you check to see if you are still having sys.prefix set to an empty string? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 14:58 Message: Logged In: YES user_id=357491 The NameError problem has been fixed. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 14:09 Message: Logged In: YES user_id=843814 See this patch: 931938 prefix and exec_prefix as root dir bug ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2004-04-08 11:01 Message: Logged In: YES user_id=843814 Just ran into the same problem when I configure with --prefix=/ The problem is in getpath.c. Before trying to find your lib/python dir based on what you submitted in configure, it performs a search based on the python execution path (probably /bin). It keeps chopping the path down with the reduce() function and then adds "/lib/python" and sees if a landmark file is there. The problem is that reduce() will freely chop away the last / leaving your prefix as a null string. I'm going to try tweaking reduce() so it doesn't hack off the last / if its the last one. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-08 17:54 Message: Logged In: YES user_id=357491 Why is sys.prefix == '' if it is set to '/' as the command-line argument? Checking Modules/getpath.c there appears a few places where things could go awry if an enviroment variable is set that causes the code to think it has already found the location before it reaches what the Makefile set PREFIX and EXEC_PREFIX to. The steps used are in the initial comment of the file. Any of those a possible reason for your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713601&group_id=5470 From noreply at sourceforge.net Tue Aug 10 02:59:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 03:00:03 2004 Subject: [ python-Bugs-1005933 ] imaplib.IMAP4.getquotaroot error Message-ID: Bugs item #1005933, was opened at 2004-08-09 22:31 Message generated for change (Comment added) made by pierslauder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005933&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Thierry FLORAC (tflorac) Assigned to: Piers Lauder (pierslauder) Summary: imaplib.IMAP4.getquotaroot error Initial Comment: I think there is an error in the imaplib.IMAP4.getquotaroot method available in Python 2.3.3 (as actually available in Debian GNU/Linux). In line 446 of file "imaplib.py", we can find : typ, dat = self._simple_command('GETQUOTA', mailbox) Instead and according to RFCs, I think we should have : typ, dat = self._simple_command('GETQUOTAROOT', mailbox) Using Netscape Messaging Server , the first version replies with a "Permission denied" error (while logged in as a common user) ; the second version works correctly : >>> cn.getquotaroot('INBOX') ('OK', [['INBOX user/tflorac'], ['user/tflorac (STORAGE 981 51200)']]) Thanks for your work, Thierry ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2004-08-10 10:59 Message: Logged In: YES user_id=196212 You are right - it looks as though the getquotaroot code was copied from the getquota code above it without being modified properly. Will fix. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005933&group_id=5470 From noreply at sourceforge.net Tue Aug 10 03:27:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 03:27:52 2004 Subject: [ python-Bugs-1005933 ] imaplib.IMAP4.getquotaroot error Message-ID: Bugs item #1005933, was opened at 2004-08-09 22:31 Message generated for change (Comment added) made by pierslauder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005933&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thierry FLORAC (tflorac) Assigned to: Piers Lauder (pierslauder) Summary: imaplib.IMAP4.getquotaroot error Initial Comment: I think there is an error in the imaplib.IMAP4.getquotaroot method available in Python 2.3.3 (as actually available in Debian GNU/Linux). In line 446 of file "imaplib.py", we can find : typ, dat = self._simple_command('GETQUOTA', mailbox) Instead and according to RFCs, I think we should have : typ, dat = self._simple_command('GETQUOTAROOT', mailbox) Using Netscape Messaging Server , the first version replies with a "Permission denied" error (while logged in as a common user) ; the second version works correctly : >>> cn.getquotaroot('INBOX') ('OK', [['INBOX user/tflorac'], ['user/tflorac (STORAGE 981 51200)']]) Thanks for your work, Thierry ---------------------------------------------------------------------- >Comment By: Piers Lauder (pierslauder) Date: 2004-08-10 11:27 Message: Logged In: YES user_id=196212 change checked into CVS ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2004-08-10 10:59 Message: Logged In: YES user_id=196212 You are right - it looks as though the getquotaroot code was copied from the getquota code above it without being modified properly. Will fix. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005933&group_id=5470 From noreply at sourceforge.net Tue Aug 10 09:34:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 09:34:29 2004 Subject: [ python-Bugs-1006056 ] odbc queries with very long strings fail with no exceptions Message-ID: Bugs item #1006056, was opened at 2004-08-09 18:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006056&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) Summary: odbc queries with very long strings fail with no exceptions Initial Comment: #W2K MSSQL 2000 #CREATE TABLE [dbo].[Table1] ( # [Id] [int] NULL , # [Data] [int] NULL #) import dbi, odbc import time myconn = odbc.odbc('DSN=ctbase2; UID=sa; PWD=') mycursor = myconn.cursor() updatelst = [] start = time.time() for i in range(10000): updatelst.append("update table1 set id = %d, data = %d " % (i, i)) stri = " ".join(updatelst) rc = mycursor.execute(stri) myconn.commit() #time.sleep(100) mycursor.close() myconn.close() # When running this script, a very long string is passed to execute. # Only a few first update commands are executed. # (I checked it by reading the data back). # Somehow this is timing dependant. # If sleep is commented out - 480 commands are executed. # If sleep is for 10 sec. - 1600 - 1800 commands are executed. # If sleep is for 100 sec. - 3800 commands are executed. # In all cases no exception is thrown and rc = 1 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-10 09:34 Message: Logged In: YES user_id=21627 Python does not provide an odbc module. Please report the bug to the author of the odbc module you are using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006056&group_id=5470 From noreply at sourceforge.net Tue Aug 10 16:23:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 16:23:56 2004 Subject: [ python-Bugs-1006607 ] distutils builds too many rpms Message-ID: Bugs item #1006607, was opened at 2004-08-10 10:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006607&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff MacDonald (jonez) Assigned to: Nobody/Anonymous (nobody) Summary: distutils builds too many rpms Initial Comment: I have a small extension module called 'getdate' which I am trying to build as an rpm using distutils. the module builds just fine, however at the very end, I get the following error: Traceback (most recent call last): File "./setup.py", line 83, in ? include_dirs = [get_python_inc(plat_specific=1),]), File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/core.py", line 149, in setup File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/dist.py", line 907, in run_commands File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/dist.py", line 927, in run_command File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/command/bdist_rpm.py", line 316, in run AssertionError: unexpected number of RPM files found: ['build/bdist.linux-i686/rpm/RPMS/i386/getdate-1.0.1-1.i386.rpm', 'build/bdist.linux-i686/rpm/RPMS/i386/getdate-debuginfo-1.0.1-1.i386.rpm'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006607&group_id=5470 From noreply at sourceforge.net Tue Aug 10 16:24:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 16:25:01 2004 Subject: [ python-Bugs-1006607 ] distutils builds too many rpms Message-ID: Bugs item #1006607, was opened at 2004-08-10 10:23 Message generated for change (Comment added) made by jonez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006607&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff MacDonald (jonez) Assigned to: Nobody/Anonymous (nobody) Summary: distutils builds too many rpms Initial Comment: I have a small extension module called 'getdate' which I am trying to build as an rpm using distutils. the module builds just fine, however at the very end, I get the following error: Traceback (most recent call last): File "./setup.py", line 83, in ? include_dirs = [get_python_inc(plat_specific=1),]), File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/core.py", line 149, in setup File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/dist.py", line 907, in run_commands File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/dist.py", line 927, in run_command File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/command/bdist_rpm.py", line 316, in run AssertionError: unexpected number of RPM files found: ['build/bdist.linux-i686/rpm/RPMS/i386/getdate-1.0.1-1.i386.rpm', 'build/bdist.linux-i686/rpm/RPMS/i386/getdate-debuginfo-1.0.1-1.i386.rpm'] ---------------------------------------------------------------------- >Comment By: Jeff MacDonald (jonez) Date: 2004-08-10 10:24 Message: Logged In: YES user_id=3547 if it's relevant, I am using Fedora Core 2 as the build machine. the python version I am using is: "python-2.3.3-6" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006607&group_id=5470 From noreply at sourceforge.net Tue Aug 10 18:32:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 18:32:45 2004 Subject: [ python-Bugs-1004837 ] Limited User gets error in 2.4a2 MSI Message-ID: Bugs item #1004837, was opened at 2004-08-06 21:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004837&group_id=5470 Category: Installation Group: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Martin v. L?wis (loewis) Assigned to: Martin v. L?wis (loewis) Summary: Limited User gets error in 2.4a2 MSI Initial Comment: An XP "Limited User" reportedly gets an error that it cannot write the HKEY_CURRENT_USER registry. This should be detected early on, aborting the installation. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-10 18:32 Message: Logged In: YES user_id=21627 This is not reproducable - closing it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004837&group_id=5470 From noreply at sourceforge.net Tue Aug 10 19:14:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 19:14:51 2004 Subject: [ python-Bugs-1006740 ] Possible memory leak in output console Message-ID: Bugs item #1006740, was opened at 2004-08-10 12:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006740&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirk Strauser (kstrauser) Assigned to: Nobody/Anonymous (nobody) Summary: Possible memory leak in output console Initial Comment: I've written a bridge adapter to connect my company's Unix servers to our Foxpro database, and it runs as a command line program under Python 2.3.4 (with Python for Windows Extensions build 202) on a Windows XP server. Basically, it listens for incoming SQL queries from the Unix servers (via the Python Web Services implementation of SOAP), executes them with ADODB, and returns the results via SOAP. The system works as desired, except that we've been triggering a memory leak with the program has been running for long periods of time, to the tune of about .5GB of memory per month. I've recently noticed that the rate of leak is proportional to the amount of console output that the program generates (the debugging level is remotely adjustable via a SOAP method), and that I can consistently reclaim the memory by the act of minimizing the console window. That is, at this very moment, the window is minimized and the task manager is reporting that the application is using 64,908KB of memory. If I restore the window to its normal size, the memory allocation stays about the same. If I then re-minimize the window, usage drops to 280KB. It will then gradually increase again until the server begins to bog down, at which point I can repeat the process of restoring and then minimizing the console window. In other words, leaving the window "open" does not help, nor does leaving it minimized; only the act of minimizing an "open" window is sufficient to reduce the eternally-growing memory footprint. This is completely reproducible, and I was having the same problem with Python 2.3.3 before upgrading it yesterday. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006740&group_id=5470 From noreply at sourceforge.net Tue Aug 10 20:59:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 20:59:08 2004 Subject: [ python-Feature Requests-1006786 ] extend strptime to understand logging timestamps Message-ID: Feature Requests item #1006786, was opened at 2004-08-10 13:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: extend strptime to understand logging timestamps Initial Comment: The default timestamp format used by the logging module appends a comma followed by a three-digit value representing milliseconds, e.g.: 2004-08-10 08:21:20,380 DEBUG log message here It would be nice if time.strptime() grokked this specification for the seconds in a timestamp so that applications which want to analyze log files can do so more easily. One possibility is to add a %s format specifier which recognizes NN,MMM as a floating point value containing fractional seconds with a comma as the "decimal point". Attached is a simple patch. I chose %s as the format sequence since it is related to %S. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 From noreply at sourceforge.net Tue Aug 10 23:07:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 23:07:11 2004 Subject: [ python-Bugs-1006607 ] distutils builds too many rpms Message-ID: Bugs item #1006607, was opened at 2004-08-10 10:23 Message generated for change (Comment added) made by jonez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006607&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff MacDonald (jonez) Assigned to: Nobody/Anonymous (nobody) Summary: distutils builds too many rpms Initial Comment: I have a small extension module called 'getdate' which I am trying to build as an rpm using distutils. the module builds just fine, however at the very end, I get the following error: Traceback (most recent call last): File "./setup.py", line 83, in ? include_dirs = [get_python_inc(plat_specific=1),]), File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/core.py", line 149, in setup File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/dist.py", line 907, in run_commands File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/dist.py", line 927, in run_command File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/command/bdist_rpm.py", line 316, in run AssertionError: unexpected number of RPM files found: ['build/bdist.linux-i686/rpm/RPMS/i386/getdate-1.0.1-1.i386.rpm', 'build/bdist.linux-i686/rpm/RPMS/i386/getdate-debuginfo-1.0.1-1.i386.rpm'] ---------------------------------------------------------------------- >Comment By: Jeff MacDonald (jonez) Date: 2004-08-10 17:07 Message: Logged In: YES user_id=3547 this is an issue caused by redhat which always builds 'debuginfo' rpms.. I am told it has been fixed upstream, and at the moment I have hacked my .rpmmacros file so that the build I am trying to finish works. I'm closing this ticket. ---------------------------------------------------------------------- Comment By: Jeff MacDonald (jonez) Date: 2004-08-10 10:24 Message: Logged In: YES user_id=3547 if it's relevant, I am using Fedora Core 2 as the build machine. the python version I am using is: "python-2.3.3-6" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006607&group_id=5470 From noreply at sourceforge.net Tue Aug 10 23:07:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 10 23:07:41 2004 Subject: [ python-Bugs-1006607 ] distutils builds too many rpms Message-ID: Bugs item #1006607, was opened at 2004-08-10 10:23 Message generated for change (Settings changed) made by jonez You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006607&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Jeff MacDonald (jonez) Assigned to: Nobody/Anonymous (nobody) Summary: distutils builds too many rpms Initial Comment: I have a small extension module called 'getdate' which I am trying to build as an rpm using distutils. the module builds just fine, however at the very end, I get the following error: Traceback (most recent call last): File "./setup.py", line 83, in ? include_dirs = [get_python_inc(plat_specific=1),]), File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/core.py", line 149, in setup File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/dist.py", line 907, in run_commands File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/dist.py", line 927, in run_command File "/usr/src/build/394694-i386/install/usr/lib/python2.3/distutils/command/bdist_rpm.py", line 316, in run AssertionError: unexpected number of RPM files found: ['build/bdist.linux-i686/rpm/RPMS/i386/getdate-1.0.1-1.i386.rpm', 'build/bdist.linux-i686/rpm/RPMS/i386/getdate-debuginfo-1.0.1-1.i386.rpm'] ---------------------------------------------------------------------- Comment By: Jeff MacDonald (jonez) Date: 2004-08-10 17:07 Message: Logged In: YES user_id=3547 this is an issue caused by redhat which always builds 'debuginfo' rpms.. I am told it has been fixed upstream, and at the moment I have hacked my .rpmmacros file so that the build I am trying to finish works. I'm closing this ticket. ---------------------------------------------------------------------- Comment By: Jeff MacDonald (jonez) Date: 2004-08-10 10:24 Message: Logged In: YES user_id=3547 if it's relevant, I am using Fedora Core 2 as the build machine. the python version I am using is: "python-2.3.3-6" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006607&group_id=5470 From noreply at sourceforge.net Wed Aug 11 03:39:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 03:39:37 2004 Subject: [ python-Bugs-1004217 ] Shortcut keys don't work when CAPS LOCK is on Message-ID: Bugs item #1004217, was opened at 2004-08-05 16:48 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004217&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: otto (ottoisi) Assigned to: Kurt B. Kaiser (kbk) Summary: Shortcut keys don't work when CAPS LOCK is on Initial Comment: IDLE for win32 does not execute keyboard shortcuts when CAPS LOCK is on or the SHIFT key is is pressed. e.g. ctrl-C doesn't work if it's a capital C. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:39 Message: Logged In: YES user_id=149084 That's correct. Don't do that :-) This is the way the keyboard and tcl/tk works. If you really want this, customize using the options menu. It's possible to have more than one keycode bound to an event. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-07 13:13 Message: Logged In: YES user_id=149084 Dup of 833957 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004217&group_id=5470 From noreply at sourceforge.net Wed Aug 11 03:43:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 03:43:23 2004 Subject: [ python-Feature Requests-1006786 ] extend strptime to understand logging timestamps Message-ID: Feature Requests item #1006786, was opened at 2004-08-10 11:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: extend strptime to understand logging timestamps Initial Comment: The default timestamp format used by the logging module appends a comma followed by a three-digit value representing milliseconds, e.g.: 2004-08-10 08:21:20,380 DEBUG log message here It would be nice if time.strptime() grokked this specification for the seconds in a timestamp so that applications which want to analyze log files can do so more easily. One possibility is to add a %s format specifier which recognizes NN,MMM as a floating point value containing fractional seconds with a comma as the "decimal point". Attached is a simple patch. I chose %s as the format sequence since it is related to %S. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-10 18:43 Message: Logged In: YES user_id=357491 Is this the best solution, or would it be better to just have a specific logging module directive (either in the logging package or in strptime) that recognized the whole string? If that format *never* changes, then we could just simplify it by having a single directive to make life easier for everyone involved. If we are going to compromise on adding a special directive for the logging module might as well go all the way, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 From noreply at sourceforge.net Wed Aug 11 03:48:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 03:48:19 2004 Subject: [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 19:27 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:48 Message: Logged In: YES user_id=149084 Although the Tk man pages state that extra modifiers are ignored if not in the binding, that's not true for Shift (or Caps Lock). I don't see a good way to program around this, there are many bindings native to tcl/tk like Ctrl-e which also don't work in conjunction with Shift. I'm going to say that that's the way it is, and it's a *feature* since you can assign different bindings for upper case letters. You can always use the Options menu to add the shifted bindings, since it's possible to have more than one keycode bound to a given event. Playing with the following tcl/tk program is instructive: wm title . BindTest frame .top pack .top -fill x button .top.ctrly -text Control-y -command printcy pack .top.ctrly -fill x button .top.ctrlshift2 -text Control-Shift-@ -command printcs2 pack .top.ctrlshift2 -fill x button .top.ctrlshift5 -text Control-Shift-% -command printcs5 pack .top.ctrlshift5 -fill x proc printcy {} { puts Control-y } proc printcs2 {} { puts Control-Shift-at } proc printcs5 {} { puts Control-Shift-percent } bind .top printcy bind .top printcs2 #bind .top printcs5 # The Shift is not needed (but does no harm): #bind .top printcs5 # But the 'percent' is required, the lc key cap doesn't work: bind .top printcs5 # space keysym is not the same for upper and lower case: bind .top {puts Shift-space} bind .top {puts space} # Print the key being pressed: bind .top {puts **%K} focus .tophydra /home/kbk/proj/tcl$ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-01 19:28 Message: Logged In: YES user_id=149084 Hrm? The way Tk is supposed to work, if there is no binding for a key + Shift, the Shift is ignored. Or was there a Shift binding in your case? Note that the Shift bindings had an error for which I recently checked in a fix. Latter due to be backported to 2.3.4. Don't know it this helps Kirby Urner. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 15:46 Message: Logged In: YES user_id=80475 Hey, hey! That was a good hint. It is the CAPS LOCK key that is that culprit. That is a bit weird because other windows applications like Excel and Word are not similarly affected by CAPS LOCK. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-01 13:44 Message: Logged In: YES user_id=149084 By any chance did NumLk get switched on? I've heard that can cause problems. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:30 Message: Logged In: YES user_id=80475 FWIW, I've had this happen also. Unfortunately, I usually have so much going on that I haven't been able to relate it to a specific cause. ---------------------------------------------------------------------- Comment By: Kirby Urner (urnerk) Date: 2003-11-17 11:04 Message: Logged In: YES user_id=191709 I'm using WinXP Pro. Given this has not previously been reported, I will do my best to gather data on your questions as I continue to use IDLE. Ideally, I will be able to duplicate it at will. We shall see. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-16 23:56 Message: Logged In: YES user_id=149084 I haven't observed this behavior, nor heard of it before. What version of Windows are you using? The keybindings are established in Tk just after IDLE starts and are subsequently intercepted and handled by the Tk library. Do all the Ctrl bindings fail? Even Tk defaults like Ctrl-E, which goes to end of line? What about Alt bindings? Do the Ctrl keys work in other applications after they stop working in IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Wed Aug 11 03:55:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 03:56:01 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 03:41 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:55 Message: Logged In: YES user_id=149084 If you just start IDLE (shell window only) and don't do anything, does it always hang in two hours? If so, /please/ try this without your screen saver. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-08 02:58 Message: Logged In: YES user_id=358087 Hangs means the window content does not refresh. I can move it, resize it ... It is killable and task manager show it as "active". ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 15:17 Message: Logged In: YES user_id=593130 By 'hangs' do you mean when viewing the TasKManager Applications list, and killable with its End Task button? or something more evil, like locks the computer and prevents rebooting? Even Outlook Express and Internet Explore, with MS's billions, still do the former. With Win95, 98, and XP home and pro, I have had several problems, often intermittent, and maybe hardware specific, with bad interactions between programs, screen savers, and stand-by. On LCDs (and, I believe, modern CRTs) 'screen savers' save nothing except the boredom of a constant picture. I would turn it off and also check screen properites/screensaver/power button and the bios to see if anything is scheduled to happen at 2 hours. The timing, if consistent, is definitely suspicious. A major change for Windows between 2.3.4 and 2.4 is the compiler 'upgrade' which could change a program's interaction with Windows and its vulnerability to bugs within. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 03:11 Message: Logged In: YES user_id=358087 1. "Pure" Python (without IDLE) don't hang after 2 hours 2. I didn't try this time but I'm pretty sure it hanged without screen saver as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-03 20:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 04:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 03:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Wed Aug 11 04:19:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 04:19:34 2004 Subject: [ python-Bugs-808719 ] IDLE and encodings Message-ID: Bugs item #808719, was opened at 2003-09-18 12:08 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) >Assigned to: Martin v. L?wis (loewis) Summary: IDLE and encodings Initial Comment: A person from Belgium reported this problem in IDLE to python-help: $ python idle Traceback (most recent call last): File "idle", line 10, in ? import PyShell File "PyShell.py", line 25, in ? from EditorWindow import EditorWindow, fixwordbreaks File "EditorWindow.py", line 39, in ? class EditorWindow: File "EditorWindow.py", line 43, in EditorWindow from IOBinding import IOBinding File "IOBinding.py", line 54, in ? codecs.lookup(encoding) File "/ap/tools/storage/python/v2.2.2.224_ap/lib/python2.2/ encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') ValueError: Empty module name It seems that checking for an encoding of "" as well as None in IOBinding.py fixes the problem. I'll attach his small patch. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 21:19 Message: Logged In: YES user_id=149084 Martin, do you see any problem if I apply this patch to IDLE? ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-09-19 12:22 Message: Logged In: YES user_id=198518 The original poster to python-help replies: SYSTEM: SunOS indsv07 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-2 ????????????????Python2.2??????????????????????????????????????? ???????????? >>> locale.getpreferredencoding Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'getpreferredencoding' >>> locale.getpreferredencoding() Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'getpreferredencoding' >>> ???????????????????????????????????????????????????????????????? ?????? ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#1, Nov 26 2002, 10:37:00) [GCC 2.95.2 19991024 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> >>> locale._print_locale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<< Locale defaults as determined by getdefaultlocale(): ------------------------------------------------------------------------ Language: (undefined) Encoding: (undefined) Locale settings on startup: ------------------------------------------------------------------------ LC_NUMERIC ... Language: (undefined) Encoding: (undefined) LC_MESSAGES ... Language: (undefined) Encoding: (undefined) LC_MONETARY ... Language: (undefined) Encoding: (undefined) LC_COLLATE ... Language: (undefined) Encoding: (undefined) LC_CTYPE ... Language: (undefined) Encoding: (undefined) LC_TIME ... Language: (undefined) Encoding: (undefined) Locale settings after calling resetlocale(): ------------------------------------------------------------------------ LC_NUMERIC ... Language: (undefined) Encoding: (undefined) LC_MESSAGES ... Language: (undefined) Encoding: (undefined) LC_MONETARY ... Language: (undefined) Encoding: (undefined) LC_COLLATE ... Language: (undefined) Encoding: (undefined) LC_CTYPE ... Language: (undefined) Encoding: (undefined) LC_TIME ... Language: (undefined) Encoding: (undefined) Locale settings after calling setlocale(LC_ALL, ""): ------------------------------------------------------------------------ C_NUMERIC ... Language: (undefined) Encoding: (undefined) LC_MESSAGES ... Language: (undefined) Encoding: (undefined) LC_MONETARY ... Language: (undefined) Encoding: (undefined) LC_COLLATE ... Language: (undefined) Encoding: (undefined) LC_CTYPE ... Language: (undefined) Encoding: (undefined) LC_TIME ... Language: (undefined) Encoding: (undefined) >>> >>> locale._test() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 123456789 is 123456789 3.14 is 3.14 >>> locale.getlocale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (None, None) >>> locale.getdefaultlocale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (None, None) >>> >>> locale.CODESET <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 49 >>> locale.localeconv() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< {'mon_decimal_point': '', 'int_frac_digits': 127, 'p_sep_by_space': 127, 'frac_digits': 127, 'thousands_sep': '', 'n_sign_posn': 127, 'decimal_point': '.', 'mon_thousands_sep': '', 'n_cs_precedes': 127, 'p_sign_posn': 127, 'int_curr_symbol': '', 'negative_sign': '', 'currency_symbol': '', 'n_sep_by_space': 127, 'mon_grouping': [], 'p_cs_precedes': 127, 'positive_sign': '', 'grouping': []} >>> >>> locale.getdefaultlocale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< < (None, None) ========================================= ========================================= ====== !!!!!!!!!!!!!!!!!!!!!! Unofficial install of 2.3 (same system) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ========================================= ========================================= ====== Python 2.3 (#1, Jul 31 2003, 09:16:42) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import locale >>> locale.getpreferredencoding() '' >>> ############# Here, I have done the same modifications in "idlelib...IObinding.py" but for Python 2.3 and I succeed in launching IDLE ###################### Python 2.3 (#1, Jul 31 2003, 09:16:42) [GCC 2.95.3 20010315 (release)] on sunos5 Type "copyright", "credits" or "license()" for more information. ******************************************************** ******** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ******************************************************** ******** IDLE 1.0 >>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> One last remark, last time I remenber that the problem of codec lookup also appeared in other circumstances than starting IDLE. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 13:05 Message: Logged In: YES user_id=21627 Can you report what operating system this was on, and what locale setting was in place? What is the value of locale.getpreferredencoding on that system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470 From noreply at sourceforge.net Wed Aug 11 05:22:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 05:22:53 2004 Subject: [ python-Feature Requests-1006786 ] extend strptime to understand logging timestamps Message-ID: Feature Requests item #1006786, was opened at 2004-08-10 13:59 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: extend strptime to understand logging timestamps Initial Comment: The default timestamp format used by the logging module appends a comma followed by a three-digit value representing milliseconds, e.g.: 2004-08-10 08:21:20,380 DEBUG log message here It would be nice if time.strptime() grokked this specification for the seconds in a timestamp so that applications which want to analyze log files can do so more easily. One possibility is to add a %s format specifier which recognizes NN,MMM as a floating point value containing fractional seconds with a comma as the "decimal point". Attached is a simple patch. I chose %s as the format sequence since it is related to %S. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-08-10 22:22 Message: Logged In: YES user_id=44345 Whatever works. I hope we don't need a PEP for this. One way or the other I think it would be great if strptime can grok the logging module's timestamp. I haven't looked carefully at it to see if its timestamp format is variable or fixed. I suppose that will have a lot to do with how the parsing problem is solved in _strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-10 20:43 Message: Logged In: YES user_id=357491 Is this the best solution, or would it be better to just have a specific logging module directive (either in the logging package or in strptime) that recognized the whole string? If that format *never* changes, then we could just simplify it by having a single directive to make life easier for everyone involved. If we are going to compromise on adding a special directive for the logging module might as well go all the way, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 From noreply at sourceforge.net Wed Aug 11 06:47:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 06:47:08 2004 Subject: [ python-Feature Requests-1004696 ] translate Windows cr-lf when installing scripts on Linux Message-ID: Feature Requests item #1004696, was opened at 2004-08-06 11:00 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004696&group_id=5470 >Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Tim Cera (timcera) >Assigned to: Kurt B. Kaiser (kbk) Summary: translate Windows cr-lf when installing scripts on Linux Initial Comment: PROBLEM If a file installed as a script has Window cr-lf endings, even if the '#!/usr/bin/env python' is included to support direct execution on Linux, it doesn't work because the shell is confused by the cr-lf. This problem has been addressed in the newsgroups, with the usual solution to manually change the line endings, or only develop with an editor that can maintain Linux line endings. SOLUTION Convert line endings on installed scripts to the line endings appropriate to the machine running the installation. Could be limited to Unix/Linux platform because Windows doesn't care about the line endings. kindest regards, tim ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 23:47 Message: Logged In: YES user_id=149084 "Universal New Lines" See PEP 278, implemented at Python 2.3. It is better not to automagically modify the script when running it. However, there is a script 'crlf.py' in Tools/scripts which will convert files with Windows line endings to Unix line endings, if you wish to do that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004696&group_id=5470 From noreply at sourceforge.net Wed Aug 11 07:03:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 07:03:49 2004 Subject: [ python-Bugs-808719 ] IDLE and encodings Message-ID: Bugs item #808719, was opened at 2003-09-18 19:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Martin v. L?wis (loewis) Summary: IDLE and encodings Initial Comment: A person from Belgium reported this problem in IDLE to python-help: $ python idle Traceback (most recent call last): File "idle", line 10, in ? import PyShell File "PyShell.py", line 25, in ? from EditorWindow import EditorWindow, fixwordbreaks File "EditorWindow.py", line 39, in ? class EditorWindow: File "EditorWindow.py", line 43, in EditorWindow from IOBinding import IOBinding File "IOBinding.py", line 54, in ? codecs.lookup(encoding) File "/ap/tools/storage/python/v2.2.2.224_ap/lib/python2.2/ encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') ValueError: Empty module name It seems that checking for an encoding of "" as well as None in IOBinding.py fixes the problem. I'll attach his small patch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-11 07:03 Message: Logged In: YES user_id=21627 Looks fine. One day, IDLE should switch to locale.getpreferredencoding, though. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-11 04:19 Message: Logged In: YES user_id=149084 Martin, do you see any problem if I apply this patch to IDLE? ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-09-19 19:22 Message: Logged In: YES user_id=198518 The original poster to python-help replies: SYSTEM: SunOS indsv07 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-2 ????????????????Python2.2??????????????????????????????????????? ???????????? >>> locale.getpreferredencoding Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'getpreferredencoding' >>> locale.getpreferredencoding() Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'getpreferredencoding' >>> ???????????????????????????????????????????????????????????????? ?????? ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#1, Nov 26 2002, 10:37:00) [GCC 2.95.2 19991024 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> >>> locale._print_locale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<< Locale defaults as determined by getdefaultlocale(): ------------------------------------------------------------------------ Language: (undefined) Encoding: (undefined) Locale settings on startup: ------------------------------------------------------------------------ LC_NUMERIC ... Language: (undefined) Encoding: (undefined) LC_MESSAGES ... Language: (undefined) Encoding: (undefined) LC_MONETARY ... Language: (undefined) Encoding: (undefined) LC_COLLATE ... Language: (undefined) Encoding: (undefined) LC_CTYPE ... Language: (undefined) Encoding: (undefined) LC_TIME ... Language: (undefined) Encoding: (undefined) Locale settings after calling resetlocale(): ------------------------------------------------------------------------ LC_NUMERIC ... Language: (undefined) Encoding: (undefined) LC_MESSAGES ... Language: (undefined) Encoding: (undefined) LC_MONETARY ... Language: (undefined) Encoding: (undefined) LC_COLLATE ... Language: (undefined) Encoding: (undefined) LC_CTYPE ... Language: (undefined) Encoding: (undefined) LC_TIME ... Language: (undefined) Encoding: (undefined) Locale settings after calling setlocale(LC_ALL, ""): ------------------------------------------------------------------------ C_NUMERIC ... Language: (undefined) Encoding: (undefined) LC_MESSAGES ... Language: (undefined) Encoding: (undefined) LC_MONETARY ... Language: (undefined) Encoding: (undefined) LC_COLLATE ... Language: (undefined) Encoding: (undefined) LC_CTYPE ... Language: (undefined) Encoding: (undefined) LC_TIME ... Language: (undefined) Encoding: (undefined) >>> >>> locale._test() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 123456789 is 123456789 3.14 is 3.14 >>> locale.getlocale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (None, None) >>> locale.getdefaultlocale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (None, None) >>> >>> locale.CODESET <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 49 >>> locale.localeconv() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< {'mon_decimal_point': '', 'int_frac_digits': 127, 'p_sep_by_space': 127, 'frac_digits': 127, 'thousands_sep': '', 'n_sign_posn': 127, 'decimal_point': '.', 'mon_thousands_sep': '', 'n_cs_precedes': 127, 'p_sign_posn': 127, 'int_curr_symbol': '', 'negative_sign': '', 'currency_symbol': '', 'n_sep_by_space': 127, 'mon_grouping': [], 'p_cs_precedes': 127, 'positive_sign': '', 'grouping': []} >>> >>> locale.getdefaultlocale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< < (None, None) ========================================= ========================================= ====== !!!!!!!!!!!!!!!!!!!!!! Unofficial install of 2.3 (same system) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ========================================= ========================================= ====== Python 2.3 (#1, Jul 31 2003, 09:16:42) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import locale >>> locale.getpreferredencoding() '' >>> ############# Here, I have done the same modifications in "idlelib...IObinding.py" but for Python 2.3 and I succeed in launching IDLE ###################### Python 2.3 (#1, Jul 31 2003, 09:16:42) [GCC 2.95.3 20010315 (release)] on sunos5 Type "copyright", "credits" or "license()" for more information. ******************************************************** ******** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ******************************************************** ******** IDLE 1.0 >>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> One last remark, last time I remenber that the problem of codec lookup also appeared in other circumstances than starting IDLE. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:05 Message: Logged In: YES user_id=21627 Can you report what operating system this was on, and what locale setting was in place? What is the value of locale.getpreferredencoding on that system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470 From noreply at sourceforge.net Wed Aug 11 07:54:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 07:54:20 2004 Subject: [ python-Feature Requests-964437 ] idle help is modal Message-ID: Feature Requests item #964437, was opened at 2004-06-01 13:05 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=964437&group_id=5470 >Category: IDLE Group: None Status: Open Resolution: None Priority: 4 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: idle help is modal Initial Comment: [forwarded from http://bugs.debian.org/252130] the idle online help is unfortunately modal so that one cannot have the help window open and read it, and at the same time work in idle. One must close the help window before continuing in idle which is a nuisance. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-06-17 18:58 Message: Logged In: YES user_id=149084 Raymond, I'm not planning on working on this now. Please don't assign it to me again. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-06-04 00:19 Message: Logged In: YES user_id=149084 Making this an RFE. If you have time to work up a patch, that would be a big help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=964437&group_id=5470 From noreply at sourceforge.net Wed Aug 11 08:33:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 08:33:22 2004 Subject: [ python-Bugs-1006740 ] Possible memory leak in output console Message-ID: Bugs item #1006740, was opened at 2004-08-11 03:14 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006740&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Kirk Strauser (kstrauser) Assigned to: Nobody/Anonymous (nobody) Summary: Possible memory leak in output console Initial Comment: I've written a bridge adapter to connect my company's Unix servers to our Foxpro database, and it runs as a command line program under Python 2.3.4 (with Python for Windows Extensions build 202) on a Windows XP server. Basically, it listens for incoming SQL queries from the Unix servers (via the Python Web Services implementation of SOAP), executes them with ADODB, and returns the results via SOAP. The system works as desired, except that we've been triggering a memory leak with the program has been running for long periods of time, to the tune of about .5GB of memory per month. I've recently noticed that the rate of leak is proportional to the amount of console output that the program generates (the debugging level is remotely adjustable via a SOAP method), and that I can consistently reclaim the memory by the act of minimizing the console window. That is, at this very moment, the window is minimized and the task manager is reporting that the application is using 64,908KB of memory. If I restore the window to its normal size, the memory allocation stays about the same. If I then re-minimize the window, usage drops to 280KB. It will then gradually increase again until the server begins to bog down, at which point I can repeat the process of restoring and then minimizing the console window. In other words, leaving the window "open" does not help, nor does leaving it minimized; only the act of minimizing an "open" window is sufficient to reduce the eternally-growing memory footprint. This is completely reproducible, and I was having the same problem with Python 2.3.3 before upgrading it yesterday. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 16:33 Message: Logged In: YES user_id=1038590 What are you using to measure your 'memory usage'? If you are looking at the 'Mem Usage' column in Windows, then that is completely meaningless. To get a meaningful number, you need to go to View->Select Columns and check 'Virtual Memory Size' The new column 'VM Size' will now show you how much memory your application has actually allocated, rather than how much it currently has paged into RAM. What you are seeing with the significant drop in 'Mem Usage' is Windows throwing most of your program's data set out of physical RAM when you minimise it. Now, as to where your 'leak' is coming from - that console display ain't free. Windows has to buffer that data somewhere - and that's in RAM. So if you want to eliminate your 'leak' start the app with stdout piped to a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006740&group_id=5470 From noreply at sourceforge.net Wed Aug 11 08:47:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 08:48:00 2004 Subject: [ python-Bugs-1007046 ] os.startfile() doesn't accept Unicode filenames Message-ID: Bugs item #1007046, was opened at 2004-08-11 06:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Huening (huening) Assigned to: Nobody/Anonymous (nobody) Summary: os.startfile() doesn't accept Unicode filenames Initial Comment: WinXP, Python 2.3.4 os.startfile() seems to have problems with Unicode filenames. Example: >>> import tkFileDialog >>> import os >>> f = tkFileDialog.askopenfilename() >>> type(f) >>> os.startfile(f) Traceback (most recent call last): File "", line 1, in -toplevel- os.startfile(f) UnicodeEncodeError: 'ascii' codec can't encode characters in position 14-16: ordinal not in range(128) >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007046&group_id=5470 From noreply at sourceforge.net Wed Aug 11 09:00:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 09:00:40 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-31 10:08 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 17:00 Message: Logged In: YES user_id=1038590 Don't know about anyone else, but the shortcut in str.join that returns a reference to the *original* string in the case of a single item sequence strikes me as very bad ju-ju: >>> class mystr(str): pass ... >>> s1 = mystr('fred') >>> s1 'fred' >>> s1.mutable = 42 >>> s1.mutable 42 >>> s2 = ''.join([s1]) >>> s2.mutable 42 When I call join, I expect to get a *new* object back, not a reference to an old one (this is safe for standard strings, but not for subclasses which may have mutable state). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2004-08-08 08:17 Message: Logged In: YES user_id=34209 The point of the original bugreport is not that some operations return strings instead of subtypes. The point is that *one* operation *sometimes* returns subtypes. It's inconsistent and unexpected behaviour, and since you clearly don't write 'sep.join(seq)' for a common case of 'seq' being a single item, something you will only occasionally trigger. I don't have an emotional investment in this bug, it's just something that came up on #python. I also don't care which way it's fixed -- but treating the single-element-sequence case the same as the multiple-element-sequence seems logical to me. Regardless of how the multiple-element-sequence is handled exactly :) As for why I didn't write a patch myself, Michael, if I had time for that, I would've spent it writing a good decorator proposal >:-) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-08-08 01:48 Message: Logged In: YES user_id=7887 If this was considered a bug: >>> type(ms("a")+ms("b")) >>> type(ms("a")[:]) Are these bugs as well? I belive this is how the implementation was intended to be, even if not optimal for subclasses. I suggest closing this bug as invalid, and writing a PEP about the possible new subclass support change (for all classes), if there's enough interest. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-06 02:10 Message: Logged In: YES user_id=593130 Duh, my turn to forget. For any beginners reading this ... >>> class ms(str): pass ... >>> a=ms('a') >>> type(''.join((a,))) Expanding mhw's second point: >>> e=ms() >>> type(e) >>> import copy >>> e2=copy.copy(e) >>> type(e2) >>> e3=e[:] >>> type(e3) >>> id(e),id(e2),id(e3) (9494608, 9009936, 8577440) so [:] is not exactly an abbreviated synonym for copy(). Is this a butg? (I haven't rechecked the respective docs yet.) One reason I hesitate to call the OP's original observation a bug is that the whole sujbect of operations on subtype instances seems not completely baked. Knowing the result types in all cases may require experiments as well as doc reading. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 22:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 06:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-05 05:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-03 00:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Wed Aug 11 10:04:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 10:07:20 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-31 10:08 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 18:04 Message: Logged In: YES user_id=1038590 New patch (#1007087) created with a test for this bug, as well as a fix for it (the fix simply removes the 'sequence of 1' shortcut). Checks for the unicode case as well, although unicode didn't have this bug (due to a different join implementation). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 17:00 Message: Logged In: YES user_id=1038590 Don't know about anyone else, but the shortcut in str.join that returns a reference to the *original* string in the case of a single item sequence strikes me as very bad ju-ju: >>> class mystr(str): pass ... >>> s1 = mystr('fred') >>> s1 'fred' >>> s1.mutable = 42 >>> s1.mutable 42 >>> s2 = ''.join([s1]) >>> s2.mutable 42 When I call join, I expect to get a *new* object back, not a reference to an old one (this is safe for standard strings, but not for subclasses which may have mutable state). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2004-08-08 08:17 Message: Logged In: YES user_id=34209 The point of the original bugreport is not that some operations return strings instead of subtypes. The point is that *one* operation *sometimes* returns subtypes. It's inconsistent and unexpected behaviour, and since you clearly don't write 'sep.join(seq)' for a common case of 'seq' being a single item, something you will only occasionally trigger. I don't have an emotional investment in this bug, it's just something that came up on #python. I also don't care which way it's fixed -- but treating the single-element-sequence case the same as the multiple-element-sequence seems logical to me. Regardless of how the multiple-element-sequence is handled exactly :) As for why I didn't write a patch myself, Michael, if I had time for that, I would've spent it writing a good decorator proposal >:-) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-08-08 01:48 Message: Logged In: YES user_id=7887 If this was considered a bug: >>> type(ms("a")+ms("b")) >>> type(ms("a")[:]) Are these bugs as well? I belive this is how the implementation was intended to be, even if not optimal for subclasses. I suggest closing this bug as invalid, and writing a PEP about the possible new subclass support change (for all classes), if there's enough interest. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-06 02:10 Message: Logged In: YES user_id=593130 Duh, my turn to forget. For any beginners reading this ... >>> class ms(str): pass ... >>> a=ms('a') >>> type(''.join((a,))) Expanding mhw's second point: >>> e=ms() >>> type(e) >>> import copy >>> e2=copy.copy(e) >>> type(e2) >>> e3=e[:] >>> type(e3) >>> id(e),id(e2),id(e3) (9494608, 9009936, 8577440) so [:] is not exactly an abbreviated synonym for copy(). Is this a butg? (I haven't rechecked the respective docs yet.) One reason I hesitate to call the OP's original observation a bug is that the whole sujbect of operations on subtype instances seems not completely baked. Knowing the result types in all cases may require experiments as well as doc reading. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 22:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 06:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-05 05:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-03 00:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Wed Aug 11 10:14:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 10:15:15 2004 Subject: [ python-Bugs-1006001 ] FutureWarning when running regression tests Message-ID: Bugs item #1006001, was opened at 2004-08-10 00:56 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006001&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: FutureWarning when running regression tests Initial Comment: Python: 2.4a2, windows installer (MSI) OS: WinXP Prog ENG Warning is raised when running regrtest.py: C:\Python23\lib\test\test_format.py:19: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up result = formatstr % args Traceback (most recent call last): File "C:\Python24\Lib\test\regrtest.py", line 1130, in ? main() File "C:\Python24\Lib\test\regrtest.py", line 359, in main e = _ExpectedSkips() File "C:\Python24\Lib\test\regrtest.py", line 1063, in __init__ from test import test_codecmaps_cn, test_codecmaps_jp ImportError: cannot import name test_codecmaps_cn ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 18:14 Message: Logged In: YES user_id=1038590 This is fixed in 2.4 CVS, as the test has been converted to look for the new signed strings, and future warning is gone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006001&group_id=5470 From noreply at sourceforge.net Wed Aug 11 10:21:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 10:21:25 2004 Subject: [ python-Bugs-1006001 ] FutureWarning when running regression tests Message-ID: Bugs item #1006001, was opened at 2004-08-10 00:56 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006001&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: FutureWarning when running regression tests Initial Comment: Python: 2.4a2, windows installer (MSI) OS: WinXP Prog ENG Warning is raised when running regrtest.py: C:\Python23\lib\test\test_format.py:19: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up result = formatstr % args Traceback (most recent call last): File "C:\Python24\Lib\test\regrtest.py", line 1130, in ? main() File "C:\Python24\Lib\test\regrtest.py", line 359, in main e = _ExpectedSkips() File "C:\Python24\Lib\test\regrtest.py", line 1063, in __init__ from test import test_codecmaps_cn, test_codecmaps_jp ImportError: cannot import name test_codecmaps_cn ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 18:21 Message: Logged In: YES user_id=1038590 However, the output does suggest that the test execution is picking up the old Python23 test files, instead of the Python24 ones. Are you sure you ran the correct version of the interpreter? (Windows PATH problems can easily confuse this issue - *not* putting Python on the path is a very good idea if you want to run multiple installs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 18:14 Message: Logged In: YES user_id=1038590 This is fixed in 2.4 CVS, as the test has been converted to look for the new signed strings, and future warning is gone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006001&group_id=5470 From noreply at sourceforge.net Wed Aug 11 14:03:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 14:03:40 2004 Subject: [ python-Bugs-1005308 ] _XOPEN_SOURCE issue on IRIX 5.3 Message-ID: Bugs item #1005308, was opened at 2004-08-08 01:10 Message generated for change (Comment added) made by mhertha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: _XOPEN_SOURCE issue on IRIX 5.3 Initial Comment: On IRIX 5.3 /usr/include/sys/types.h contains: #if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /* * Nested include for BSD/sockets source compatibility. * (The select macros used to be defined here). */ #include #endif sys/bsd_types.h however defines u_int. If _XOPEN_SOURCE is defined (in pyconfig.h) this results in u_int not being known and the compilation to fail. One way to get around this is to change configure as follows (similarly as it is already being done for some other OSes, it seems...): --- configure.orig 2004-08-08 00:18:33.000000000 + 0200 +++ configure 2004-08-08 00:18:59.000000000 +0200 @@ -1466,6 +1466,8 @@ # has another value. By not (re)defining it, the defaults come in place. AIX/4) define_xopen_source=no;; + IRIX/5.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes I am not sure if this is the best way to solve that problem though. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-08-11 14:03 Message: Logged In: YES user_id=768223 This item could be solved by adding -D_BSD_TYPES in the BASECFLAGS-line of the Makefile on Irix 6.5.xx and MIPSpro Compilers: Version 7.3.1.3m ---------------------------------------------------------------------- Comment By: Georg Schwarz (gschwarz) Date: 2004-08-08 19:32 Message: Logged In: YES user_id=951222 On IRIX 5.3 unter /usr/include _BSD_TYPES occurs as follows: /usr/include/sys/time.h:#if !defined(_POSIX_SOURCE) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/sys/types.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/unistd.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) Therefore it seems pretty harmless to define _BSD_TYPEs. I manually did so by adding -D_BSD_TYPES to OPT= in the toplevel Makefile. With this modification python 2.3.4 compiles even with _XOPEN_SOURCE defined. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-08 15:22 Message: Logged In: YES user_id=21627 Will it build correctly if you define _BSD_TYPES or _BSD_COMPAT? What is the difference between these two (i.e. which one is less intrusive)? Get these defined directly, or would we have to define something else which in turn causes _BSD_TYPES (say) to be defined? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 From noreply at sourceforge.net Wed Aug 11 14:31:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 14:31:27 2004 Subject: [ python-Bugs-1007223 ] SGI (IRIX6.5.24) Problems building nismodule.c Message-ID: Bugs item #1007223, was opened at 2004-08-11 14:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007223&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: SGI (IRIX6.5.24) Problems building nismodule.c Initial Comment: Building python on SGI Irix 6.5.24 with MIPSpro Compilers Version 7.3.1.3m with: ./configure gmake gmake test The test shows that the test_nis.py failed. Running python from the build location: ./python >>> import nis >>> nis.maps() raises a nis.error "No NIS master found for any map". The Makefile has a LIBS-line (#151): LIBS=-lsocket -lnsl -ldl -lpthread -lmpz This line could be shortened to: LIBS=-lpthread After gmake distclean ./configure -> cleaning up the LIBS-line in Makefile gmake gmake test The nismodule could be successfull used. Why? Library libmpz isn't already installed on Irix 6.5.xx Library libdl isn't used for anything. Libraries libsocket and libnsl can't access the NIS. See intro(3) man-page .... (3N) There are actually 3 types of networking in IRIX. 1) BSD sockets implemented in the kernel, along with SUN RPC and NIS (YP). The functions that implement these calls are in libc [see (3C) section above]. 2) SVR4-style STREAMS/TLI networking (not sockets), along with SVR4-style RPC. SVR4-style RPC doesn't work with sockets, only with the TLI. Also, SVR4-style networking does not support NIS [see intro(3N)]. The functions that implement these calls are in libnsl, and to use them, the code must be compiled with : cc -D_SVR4_TIRPC prog.c -lnsl 3) SVR4 emulation of sockets. This is an implementation of sockets entirely in a library (libsocket) that sits on top of libnsl. There are no header file differences for libsocket. The MIPS ABI-compliant programs that use sockets must (in order to be ABI-compliant) link with libsocket. There is no NIS support for programs linked with libsocket [see intro(3N)]. To compile such a program, use: cc prog.c -lsocket (3Y) Remote Procedure Call (RPC) and NIS support routines. These functions are in the standard C library libc, already mentioned. ... Unfortunately I'm not a configure expert so I could only report the problem and a solution. --maik./ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007223&group_id=5470 From noreply at sourceforge.net Wed Aug 11 15:11:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 15:11:11 2004 Subject: [ python-Bugs-1007249 ] SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Message-ID: Bugs item #1007249, was opened at 2004-08-11 15:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Initial Comment: This bug report is similar to #1005737 only a different platform. MIPSpro Compilers: Version 7.3.1.3m Error message: --- start cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1053 There are too many initializers for a declared aggregate. { REGISTRY_KSX1001, REGISTRY_SENTINEL }, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1058 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0201_R, REGISTRY_JISX0208_O, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1064 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1070 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_KSX1001, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1077 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2004_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1084 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2000_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1091 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ --- end The manpage for cc describes the differences between gcc and mipspro: .... * The gcc compiler is more lax about accepting non-static initializers, extra parentheses, and the use of non-compile-time constants. The MIPSpro compilers adhere more closely to the ANSI standard. .... I found no compiler-option to solve this for the MipsPro compiler. Seems to be a hard work to solve this :-(. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 From noreply at sourceforge.net Wed Aug 11 15:12:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 15:12:41 2004 Subject: [ python-Feature Requests-1004696 ] translate Windows cr-lf when installing scripts on Linux Message-ID: Feature Requests item #1004696, was opened at 2004-08-06 12:00 Message generated for change (Comment added) made by timcera You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004696&group_id=5470 >Category: Distutils Group: None >Status: Open >Resolution: None >Priority: 2 Submitted By: Tim Cera (timcera) Assigned to: Kurt B. Kaiser (kbk) Summary: translate Windows cr-lf when installing scripts on Linux Initial Comment: PROBLEM If a file installed as a script has Window cr-lf endings, even if the '#!/usr/bin/env python' is included to support direct execution on Linux, it doesn't work because the shell is confused by the cr-lf. This problem has been addressed in the newsgroups, with the usual solution to manually change the line endings, or only develop with an editor that can maintain Linux line endings. SOLUTION Convert line endings on installed scripts to the line endings appropriate to the machine running the installation. Could be limited to Unix/Linux platform because Windows doesn't care about the line endings. kindest regards, tim ---------------------------------------------------------------------- >Comment By: Tim Cera (timcera) Date: 2004-08-11 09:12 Message: Logged In: YES user_id=169213 I put this back in distutils category instead of Python core. I read over what I had written (and the response from kbk) and it is obvious that I wasn't clear. A Windows developer that uses distutils would be frustrated by their scripts not working on Unix/Linux because of the cr-lf endings, even if they had included the Unix/Linux '#!/usr/bin/env python' as the first line. I am asking that when _distutils_ installs an executable script that the line endings in each executable script are set to those appropriate for the target machine. In this way a Windows programer can ignore the line-ending formats of their scripts and distutils will quietly take care of the problem. sorry for the confusion and I hope that I have explained my idea better. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-11 00:47 Message: Logged In: YES user_id=149084 "Universal New Lines" See PEP 278, implemented at Python 2.3. It is better not to automagically modify the script when running it. However, there is a script 'crlf.py' in Tools/scripts which will convert files with Windows line endings to Unix line endings, if you wish to do that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1004696&group_id=5470 From noreply at sourceforge.net Wed Aug 11 16:38:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 16:38:21 2004 Subject: [ python-Bugs-1006001 ] FutureWarning when running regression tests Message-ID: Bugs item #1006001, was opened at 2004-08-09 10:56 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006001&group_id=5470 Category: None Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: FutureWarning when running regression tests Initial Comment: Python: 2.4a2, windows installer (MSI) OS: WinXP Prog ENG Warning is raised when running regrtest.py: C:\Python23\lib\test\test_format.py:19: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up result = formatstr % args Traceback (most recent call last): File "C:\Python24\Lib\test\regrtest.py", line 1130, in ? main() File "C:\Python24\Lib\test\regrtest.py", line 359, in main e = _ExpectedSkips() File "C:\Python24\Lib\test\regrtest.py", line 1063, in __init__ from test import test_codecmaps_cn, test_codecmaps_jp ImportError: cannot import name test_codecmaps_cn ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-11 10:38 Message: Logged In: YES user_id=11375 Closing as suggested by ncoghlan. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 04:21 Message: Logged In: YES user_id=1038590 However, the output does suggest that the test execution is picking up the old Python23 test files, instead of the Python24 ones. Are you sure you ran the correct version of the interpreter? (Windows PATH problems can easily confuse this issue - *not* putting Python on the path is a very good idea if you want to run multiple installs) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 04:14 Message: Logged In: YES user_id=1038590 This is fixed in 2.4 CVS, as the test has been converted to look for the new signed strings, and future warning is gone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006001&group_id=5470 From noreply at sourceforge.net Wed Aug 11 16:39:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 16:39:36 2004 Subject: [ python-Bugs-1006740 ] Possible memory leak in output console Message-ID: Bugs item #1006740, was opened at 2004-08-10 13:14 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006740&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Kirk Strauser (kstrauser) Assigned to: Nobody/Anonymous (nobody) Summary: Possible memory leak in output console Initial Comment: I've written a bridge adapter to connect my company's Unix servers to our Foxpro database, and it runs as a command line program under Python 2.3.4 (with Python for Windows Extensions build 202) on a Windows XP server. Basically, it listens for incoming SQL queries from the Unix servers (via the Python Web Services implementation of SOAP), executes them with ADODB, and returns the results via SOAP. The system works as desired, except that we've been triggering a memory leak with the program has been running for long periods of time, to the tune of about .5GB of memory per month. I've recently noticed that the rate of leak is proportional to the amount of console output that the program generates (the debugging level is remotely adjustable via a SOAP method), and that I can consistently reclaim the memory by the act of minimizing the console window. That is, at this very moment, the window is minimized and the task manager is reporting that the application is using 64,908KB of memory. If I restore the window to its normal size, the memory allocation stays about the same. If I then re-minimize the window, usage drops to 280KB. It will then gradually increase again until the server begins to bog down, at which point I can repeat the process of restoring and then minimizing the console window. In other words, leaving the window "open" does not help, nor does leaving it minimized; only the act of minimizing an "open" window is sufficient to reduce the eternally-growing memory footprint. This is completely reproducible, and I was having the same problem with Python 2.3.3 before upgrading it yesterday. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-11 10:39 Message: Logged In: YES user_id=11375 Closing as suggested by ncoghlan; this doesn't look like Python's problem, but rather the console's. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 02:33 Message: Logged In: YES user_id=1038590 What are you using to measure your 'memory usage'? If you are looking at the 'Mem Usage' column in Windows, then that is completely meaningless. To get a meaningful number, you need to go to View->Select Columns and check 'Virtual Memory Size' The new column 'VM Size' will now show you how much memory your application has actually allocated, rather than how much it currently has paged into RAM. What you are seeing with the significant drop in 'Mem Usage' is Windows throwing most of your program's data set out of physical RAM when you minimise it. Now, as to where your 'leak' is coming from - that console display ain't free. Windows has to buffer that data somewhere - and that's in RAM. So if you want to eliminate your 'leak' start the app with stdout piped to a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1006740&group_id=5470 From noreply at sourceforge.net Wed Aug 11 16:40:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 16:40:12 2004 Subject: [ python-Bugs-1002763 ] asynchat does not accept 'long' terminator Message-ID: Bugs item #1002763, was opened at 2004-08-03 13:35 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002763&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jey Kottalam (jeyk) >Assigned to: A.M. Kuchling (akuchling) Summary: asynchat does not accept 'long' terminator Initial Comment: I was browsing the asynchat source code and noticed that the asynchat module accepts ints but not longs for the set_terminator function. I'm attaching a patch that allows it to accept longs as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002763&group_id=5470 From noreply at sourceforge.net Wed Aug 11 17:59:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 17:59:24 2004 Subject: [ python-Feature Requests-1006786 ] extend strptime to understand logging timestamps Message-ID: Feature Requests item #1006786, was opened at 2004-08-10 14:59 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: extend strptime to understand logging timestamps Initial Comment: The default timestamp format used by the logging module appends a comma followed by a three-digit value representing milliseconds, e.g.: 2004-08-10 08:21:20,380 DEBUG log message here It would be nice if time.strptime() grokked this specification for the seconds in a timestamp so that applications which want to analyze log files can do so more easily. One possibility is to add a %s format specifier which recognizes NN,MMM as a floating point value containing fractional seconds with a comma as the "decimal point". Attached is a simple patch. I chose %s as the format sequence since it is related to %S. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-08-11 11:59 Message: Logged In: YES user_id=764593 The format changes; "##,###" is just the default. It is based on an ISO recommendation, including the use of "," rather than "." to indicate a decimal point. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-08-10 23:22 Message: Logged In: YES user_id=44345 Whatever works. I hope we don't need a PEP for this. One way or the other I think it would be great if strptime can grok the logging module's timestamp. I haven't looked carefully at it to see if its timestamp format is variable or fixed. I suppose that will have a lot to do with how the parsing problem is solved in _strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-10 21:43 Message: Logged In: YES user_id=357491 Is this the best solution, or would it be better to just have a specific logging module directive (either in the logging package or in strptime) that recognized the whole string? If that format *never* changes, then we could just simplify it by having a single directive to make life easier for everyone involved. If we are going to compromise on adding a special directive for the logging module might as well go all the way, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 From noreply at sourceforge.net Wed Aug 11 20:17:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 20:17:47 2004 Subject: [ python-Feature Requests-1006786 ] extend strptime to understand logging timestamps Message-ID: Feature Requests item #1006786, was opened at 2004-08-10 11:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: extend strptime to understand logging timestamps Initial Comment: The default timestamp format used by the logging module appends a comma followed by a three-digit value representing milliseconds, e.g.: 2004-08-10 08:21:20,380 DEBUG log message here It would be nice if time.strptime() grokked this specification for the seconds in a timestamp so that applications which want to analyze log files can do so more easily. One possibility is to add a %s format specifier which recognizes NN,MMM as a floating point value containing fractional seconds with a comma as the "decimal point". Attached is a simple patch. I chose %s as the format sequence since it is related to %S. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-11 11:17 Message: Logged In: YES user_id=357491 Jim is right; dateFormat() in the Formatter class in Lib/logging/ __init__.py seems to handle formatting of timestamps. Now looking at the code it seems to store the format in self.datefmt, but it is set to None by default. Then in dateFormat(), if self.datefmt is None it uses the default format. The problem is that the millisecond part of the timestamp is not supported by time tuples. strftime doesn't even support it (if you look at timeFormat(), it kind of cheats and passes everything *but* the millisecond time to strftime and then just tacks on the millisecond stamp) so it seems a little off to add support just in strptime. Kind of too bad since it means that there is no way to actually construct the default timestamp yourself; timeFormat, if given a value other than None just passes the format string through strftime. And look at datetime. It supports *microsecond* values in its time class and strftime can't support that either. So now we have two places in the stdlib where they use stuff that strftime (and thus strptime) can't support. And of course the logging module doesn't use datetime since it is keeping 1.5.2 compatibility, so we can't solve all our problems with just a fix for datetime or by subclassing stuff in _strptime and coming up with a custom strptime for the logging module. So honestly I don't know what a good solution would be since not having symmetry with strftime is not acceptable. I can only think of having a small wrapper function in the logging module that handles the millisecond part and passes the rest through strptime. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-08-11 08:59 Message: Logged In: YES user_id=764593 The format changes; "##,###" is just the default. It is based on an ISO recommendation, including the use of "," rather than "." to indicate a decimal point. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-08-10 20:22 Message: Logged In: YES user_id=44345 Whatever works. I hope we don't need a PEP for this. One way or the other I think it would be great if strptime can grok the logging module's timestamp. I haven't looked carefully at it to see if its timestamp format is variable or fixed. I suppose that will have a lot to do with how the parsing problem is solved in _strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-10 18:43 Message: Logged In: YES user_id=357491 Is this the best solution, or would it be better to just have a specific logging module directive (either in the logging package or in strptime) that recognized the whole string? If that format *never* changes, then we could just simplify it by having a single directive to make life easier for everyone involved. If we are going to compromise on adding a special directive for the logging module might as well go all the way, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 From noreply at sourceforge.net Wed Aug 11 23:22:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 11 23:22:40 2004 Subject: [ python-Bugs-992078 ] test_format fails 2.4a1 Message-ID: Bugs item #992078, was opened at 2004-07-15 21:17 Message generated for change (Comment added) made by msurface You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992078&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: roadkill (dharma_roadkill) Assigned to: Nobody/Anonymous (nobody) Summary: test_format fails 2.4a1 Initial Comment: uname -a OSF1 pikachu.****.com V5.1 2650 alpha (HP alpha box running Tru64 V5.1B) Python-2.4a1 make test: test test_format produced unexpected output: ****************************************** **************************** *** line 2 of actual output doesn't appear in expected output after line 1: + u'%f' % (1.0,) == u'1,000000' != '1.000000' ****************************************** **************************** no fancy configure options no locale env variables set ---------------------------------------------------------------------- Comment By: Mitchell Surface (msurface) Date: 2004-08-11 16:22 Message: Logged In: YES user_id=21257 I can confirm it's still failing in current CVS. It looks like test__locale.py is not restoring the locale when it it's finished. I've submitted patch #1007539. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-07-16 14:20 Message: Logged In: YES user_id=129426 I can confirm this. It is caused by test__locale that is executed before test_format (and also, test_unicode fails likewise). See: Not only test_format but also test_unicode fail on my Mandrake 10 box. My default locale is nl_NL. Behold: [irmen@atlantis Python-2.4a1]$ cat testcases.in test__locale test_format test_unicode [irmen@atlantis Python-2.4a1]$ ./python Lib/test/regrtest.py -f testcases.in test__locale test_format test test_format produced unexpected output: ********************************************************************** *** line 2 of actual output doesn't appear in expected output after line 1: + u'%f' % (1.0,) == u'1,000000' != '1.000000' ********************************************************************** test_unicode test test_unicode failed -- Traceback (most recent call last): File "/home/irmen/BUILD/Python-2.4a1/Lib/test/test_unicode.py", line 358, in test_formatt ing string_tests.MixinStrUnicodeUserStringTest.test_formatting(self) File "/home/irmen/BUILD/Python-2.4a1/Lib/test/string_tests.py", line 615, in test_formatt ing self.checkequal('0042.00', '%07.2f', '__mod__', 42) File "/home/irmen/BUILD/Python-2.4a1/Lib/test/string_tests.py", line 56, in checkequal realresult AssertionError: u'0042.00' != u'0042,00' 1 test OK. 2 tests failed: test_format test_unicode [irmen@atlantis Python-2.4a1]$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992078&group_id=5470 From noreply at sourceforge.net Thu Aug 12 00:14:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 00:14:29 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 11:36 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 07:14 Message: Logged In: YES user_id=55188 The attached patch converts C99 usages to plain legacy C. Can you please test it on HP-UX whether the problem is resolved? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-09 17:15 Message: Logged In: YES user_id=200117 I am getting slightly different errors on HP-UX 11i using the native C compiler 'cc'. building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 120: error 1578: Size of struct or union member is unknown. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1058: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1064: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1070: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1078: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1085: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1091: error 1523: Too many initializers. uname -a HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 14:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Thu Aug 12 07:05:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 07:05:47 2004 Subject: [ python-Bugs-1005308 ] _XOPEN_SOURCE issue on IRIX 5.3 Message-ID: Bugs item #1005308, was opened at 2004-08-08 01:10 Message generated for change (Comment added) made by mhertha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: _XOPEN_SOURCE issue on IRIX 5.3 Initial Comment: On IRIX 5.3 /usr/include/sys/types.h contains: #if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /* * Nested include for BSD/sockets source compatibility. * (The select macros used to be defined here). */ #include #endif sys/bsd_types.h however defines u_int. If _XOPEN_SOURCE is defined (in pyconfig.h) this results in u_int not being known and the compilation to fail. One way to get around this is to change configure as follows (similarly as it is already being done for some other OSes, it seems...): --- configure.orig 2004-08-08 00:18:33.000000000 + 0200 +++ configure 2004-08-08 00:18:59.000000000 +0200 @@ -1466,6 +1466,8 @@ # has another value. By not (re)defining it, the defaults come in place. AIX/4) define_xopen_source=no;; + IRIX/5.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes I am not sure if this is the best way to solve that problem though. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-08-12 07:05 Message: Logged In: YES user_id=768223 Undefining _XOPEN_SOURCE leads to unpredictable compiling errors on IRIX 6.5.xx even for python.main. As in the Irix Manpages for intro(3) mentioned, define _BSD_TYPES if you want BSD compatibility only partly. For IRIX 6.5.xx this is used only for the bsddbmodule. --maik./ ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-08-11 14:03 Message: Logged In: YES user_id=768223 This item could be solved by adding -D_BSD_TYPES in the BASECFLAGS-line of the Makefile on Irix 6.5.xx and MIPSpro Compilers: Version 7.3.1.3m ---------------------------------------------------------------------- Comment By: Georg Schwarz (gschwarz) Date: 2004-08-08 19:32 Message: Logged In: YES user_id=951222 On IRIX 5.3 unter /usr/include _BSD_TYPES occurs as follows: /usr/include/sys/time.h:#if !defined(_POSIX_SOURCE) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/sys/types.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/unistd.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) Therefore it seems pretty harmless to define _BSD_TYPEs. I manually did so by adding -D_BSD_TYPES to OPT= in the toplevel Makefile. With this modification python 2.3.4 compiles even with _XOPEN_SOURCE defined. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-08 15:22 Message: Logged In: YES user_id=21627 Will it build correctly if you define _BSD_TYPES or _BSD_COMPAT? What is the difference between these two (i.e. which one is less intrusive)? Get these defined directly, or would we have to define something else which in turn causes _BSD_TYPES (say) to be defined? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 From noreply at sourceforge.net Thu Aug 12 09:37:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 09:37:36 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 03:36 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 08:37 Message: Logged In: YES user_id=200117 After applying the patch I am still getting two comple errors on HP-UX 11i building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-11 23:14 Message: Logged In: YES user_id=55188 The attached patch converts C99 usages to plain legacy C. Can you please test it on HP-UX whether the problem is resolved? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-09 09:15 Message: Logged In: YES user_id=200117 I am getting slightly different errors on HP-UX 11i using the native C compiler 'cc'. building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 120: error 1578: Size of struct or union member is unknown. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1058: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1064: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1070: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1078: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1085: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1091: error 1523: Too many initializers. uname -a HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 06:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Thu Aug 12 15:03:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 15:04:01 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 11:36 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 22:03 Message: Logged In: YES user_id=55188 Thanks for testing! I uploaded new patch fixed the problem. Can you both test the patch whether it compiles? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 16:37 Message: Logged In: YES user_id=200117 After applying the patch I am still getting two comple errors on HP-UX 11i building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 07:14 Message: Logged In: YES user_id=55188 The attached patch converts C99 usages to plain legacy C. Can you please test it on HP-UX whether the problem is resolved? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-09 17:15 Message: Logged In: YES user_id=200117 I am getting slightly different errors on HP-UX 11i using the native C compiler 'cc'. building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 120: error 1578: Size of struct or union member is unknown. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1058: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1064: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1070: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1078: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1085: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1091: error 1523: Too many initializers. uname -a HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 14:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Thu Aug 12 15:05:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 15:05:22 2004 Subject: [ python-Bugs-1007249 ] SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Message-ID: Bugs item #1007249, was opened at 2004-08-11 22:11 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Initial Comment: This bug report is similar to #1005737 only a different platform. MIPSpro Compilers: Version 7.3.1.3m Error message: --- start cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1053 There are too many initializers for a declared aggregate. { REGISTRY_KSX1001, REGISTRY_SENTINEL }, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1058 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0201_R, REGISTRY_JISX0208_O, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1064 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1070 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_KSX1001, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1077 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2004_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1084 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2000_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1091 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ --- end The manpage for cc describes the differences between gcc and mipspro: .... * The gcc compiler is more lax about accepting non-static initializers, extra parentheses, and the use of non-compile-time constants. The MIPSpro compilers adhere more closely to the ANSI standard. .... I found no compiler-option to solve this for the MipsPro compiler. Seems to be a hard work to solve this :-(. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 22:05 Message: Logged In: YES user_id=55188 Would you test a patch attached in Bug #1005737? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 From noreply at sourceforge.net Thu Aug 12 15:28:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 15:28:22 2004 Subject: [ python-Bugs-1005568 ] _SC_PAGE_SIZE unknown on IRIX 5.3 Message-ID: Bugs item #1005568, was opened at 2004-08-08 19:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005568&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: _SC_PAGE_SIZE unknown on IRIX 5.3 Initial Comment: Modules/resource.c expects _SC_PAGE_SIZE to be known if HAVE_SYSCONF is defined. IRIX 5.3 however knows only _SC_PAGESIZE (defined in unistd.h), not _SC_PAGE_SIZE, so compilation (as part of make test) fails. I would assume that some file in Lib/plat-irix5 should get a similar definition as in the case of Lib/plat- unixware7 or Lib/plat-sunos5, maybe. Alternatively adding the following to Modules/resource.c might help: #ifndef _SC_PAGE_SIZE #define _SC_PAGE_SIZE _SC_PAGESIZE #endif (this assumes of course that at least _SC_PAGESIZE is defined) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-12 15:28 Message: Logged In: YES user_id=21627 This should be fixed now in resource.c 2.31.10.1 and 2.32, NEWS 1.831.4.138. The fix is similar to yours: I explicitly duplicate the sysconf call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005568&group_id=5470 From noreply at sourceforge.net Thu Aug 12 15:47:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 15:47:08 2004 Subject: [ python-Bugs-1005308 ] _XOPEN_SOURCE issue on IRIX 5.3 Message-ID: Bugs item #1005308, was opened at 2004-08-08 01:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: _XOPEN_SOURCE issue on IRIX 5.3 Initial Comment: On IRIX 5.3 /usr/include/sys/types.h contains: #if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /* * Nested include for BSD/sockets source compatibility. * (The select macros used to be defined here). */ #include #endif sys/bsd_types.h however defines u_int. If _XOPEN_SOURCE is defined (in pyconfig.h) this results in u_int not being known and the compilation to fail. One way to get around this is to change configure as follows (similarly as it is already being done for some other OSes, it seems...): --- configure.orig 2004-08-08 00:18:33.000000000 + 0200 +++ configure 2004-08-08 00:18:59.000000000 +0200 @@ -1466,6 +1466,8 @@ # has another value. By not (re)defining it, the defaults come in place. AIX/4) define_xopen_source=no;; + IRIX/5.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes I am not sure if this is the best way to solve that problem though. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-12 15:47 Message: Logged In: YES user_id=21627 This should be now fixed in configure 1.416.4.15 configure.in 1.427.4.14 pyconfig.h.in 1.83.4.5 NEWS 1.831.4.139 configure 1.452 configure.in 1.465 pyconfig.h.in 1.103 The path I took was to define _BSD_TYPES in pyconfig.h.in. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-08-12 07:05 Message: Logged In: YES user_id=768223 Undefining _XOPEN_SOURCE leads to unpredictable compiling errors on IRIX 6.5.xx even for python.main. As in the Irix Manpages for intro(3) mentioned, define _BSD_TYPES if you want BSD compatibility only partly. For IRIX 6.5.xx this is used only for the bsddbmodule. --maik./ ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-08-11 14:03 Message: Logged In: YES user_id=768223 This item could be solved by adding -D_BSD_TYPES in the BASECFLAGS-line of the Makefile on Irix 6.5.xx and MIPSpro Compilers: Version 7.3.1.3m ---------------------------------------------------------------------- Comment By: Georg Schwarz (gschwarz) Date: 2004-08-08 19:32 Message: Logged In: YES user_id=951222 On IRIX 5.3 unter /usr/include _BSD_TYPES occurs as follows: /usr/include/sys/time.h:#if !defined(_POSIX_SOURCE) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/sys/types.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/unistd.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) Therefore it seems pretty harmless to define _BSD_TYPEs. I manually did so by adding -D_BSD_TYPES to OPT= in the toplevel Makefile. With this modification python 2.3.4 compiles even with _XOPEN_SOURCE defined. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-08 15:22 Message: Logged In: YES user_id=21627 Will it build correctly if you define _BSD_TYPES or _BSD_COMPAT? What is the difference between these two (i.e. which one is less intrusive)? Get these defined directly, or would we have to define something else which in turn causes _BSD_TYPES (say) to be defined? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 From noreply at sourceforge.net Thu Aug 12 15:47:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 15:47:51 2004 Subject: [ python-Bugs-1005308 ] _XOPEN_SOURCE issue on IRIX 5.3 Message-ID: Bugs item #1005308, was opened at 2004-08-08 01:10 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Georg Schwarz (gschwarz) Assigned to: Nobody/Anonymous (nobody) Summary: _XOPEN_SOURCE issue on IRIX 5.3 Initial Comment: On IRIX 5.3 /usr/include/sys/types.h contains: #if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /* * Nested include for BSD/sockets source compatibility. * (The select macros used to be defined here). */ #include #endif sys/bsd_types.h however defines u_int. If _XOPEN_SOURCE is defined (in pyconfig.h) this results in u_int not being known and the compilation to fail. One way to get around this is to change configure as follows (similarly as it is already being done for some other OSes, it seems...): --- configure.orig 2004-08-08 00:18:33.000000000 + 0200 +++ configure 2004-08-08 00:18:59.000000000 +0200 @@ -1466,6 +1466,8 @@ # has another value. By not (re)defining it, the defaults come in place. AIX/4) define_xopen_source=no;; + IRIX/5.*) + define_xopen_source=no;; esac if test $define_xopen_source = yes I am not sure if this is the best way to solve that problem though. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-12 15:47 Message: Logged In: YES user_id=21627 This should be now fixed in configure 1.416.4.15 configure.in 1.427.4.14 pyconfig.h.in 1.83.4.5 NEWS 1.831.4.139 configure 1.452 configure.in 1.465 pyconfig.h.in 1.103 The path I took was to define _BSD_TYPES in pyconfig.h.in. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-08-12 07:05 Message: Logged In: YES user_id=768223 Undefining _XOPEN_SOURCE leads to unpredictable compiling errors on IRIX 6.5.xx even for python.main. As in the Irix Manpages for intro(3) mentioned, define _BSD_TYPES if you want BSD compatibility only partly. For IRIX 6.5.xx this is used only for the bsddbmodule. --maik./ ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-08-11 14:03 Message: Logged In: YES user_id=768223 This item could be solved by adding -D_BSD_TYPES in the BASECFLAGS-line of the Makefile on Irix 6.5.xx and MIPSpro Compilers: Version 7.3.1.3m ---------------------------------------------------------------------- Comment By: Georg Schwarz (gschwarz) Date: 2004-08-08 19:32 Message: Logged In: YES user_id=951222 On IRIX 5.3 unter /usr/include _BSD_TYPES occurs as follows: /usr/include/sys/time.h:#if !defined(_POSIX_SOURCE) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/sys/types.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) /usr/include/unistd.h:#if ( !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE) ) || defined(_BSD_TYPES) || defined(_BSD_COMPAT) Therefore it seems pretty harmless to define _BSD_TYPEs. I manually did so by adding -D_BSD_TYPES to OPT= in the toplevel Makefile. With this modification python 2.3.4 compiles even with _XOPEN_SOURCE defined. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-08 15:22 Message: Logged In: YES user_id=21627 Will it build correctly if you define _BSD_TYPES or _BSD_COMPAT? What is the difference between these two (i.e. which one is less intrusive)? Get these defined directly, or would we have to define something else which in turn causes _BSD_TYPES (say) to be defined? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005308&group_id=5470 From noreply at sourceforge.net Thu Aug 12 15:49:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 15:49:10 2004 Subject: [ python-Bugs-1007249 ] SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Message-ID: Bugs item #1007249, was opened at 2004-08-11 15:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) >Assigned to: Hye-Shik Chang (perky) Summary: SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Initial Comment: This bug report is similar to #1005737 only a different platform. MIPSpro Compilers: Version 7.3.1.3m Error message: --- start cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1053 There are too many initializers for a declared aggregate. { REGISTRY_KSX1001, REGISTRY_SENTINEL }, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1058 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0201_R, REGISTRY_JISX0208_O, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1064 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1070 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_KSX1001, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1077 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2004_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1084 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2000_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1091 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ --- end The manpage for cc describes the differences between gcc and mipspro: .... * The gcc compiler is more lax about accepting non-static initializers, extra parentheses, and the use of non-compile-time constants. The MIPSpro compilers adhere more closely to the ANSI standard. .... I found no compiler-option to solve this for the MipsPro compiler. Seems to be a hard work to solve this :-(. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 15:05 Message: Logged In: YES user_id=55188 Would you test a patch attached in Bug #1005737? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 From noreply at sourceforge.net Thu Aug 12 15:17:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 17:02:36 2004 Subject: [ python-Bugs-808719 ] IDLE and encodings Message-ID: Bugs item #808719, was opened at 2003-09-18 19:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Martin v. L?wis (loewis) Summary: IDLE and encodings Initial Comment: A person from Belgium reported this problem in IDLE to python-help: $ python idle Traceback (most recent call last): File "idle", line 10, in ? import PyShell File "PyShell.py", line 25, in ? from EditorWindow import EditorWindow, fixwordbreaks File "EditorWindow.py", line 39, in ? class EditorWindow: File "EditorWindow.py", line 43, in EditorWindow from IOBinding import IOBinding File "IOBinding.py", line 54, in ? codecs.lookup(encoding) File "/ap/tools/storage/python/v2.2.2.224_ap/lib/python2.2/ encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') ValueError: Empty module name It seems that checking for an encoding of "" as well as None in IOBinding.py fixes the problem. I'll attach his small patch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-12 15:17 Message: Logged In: YES user_id=21627 Committed as IOBinding.py 1.24 and 1.19.8.4, NEWS 1.831.4.137. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-11 07:03 Message: Logged In: YES user_id=21627 Looks fine. One day, IDLE should switch to locale.getpreferredencoding, though. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-11 04:19 Message: Logged In: YES user_id=149084 Martin, do you see any problem if I apply this patch to IDLE? ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-09-19 19:22 Message: Logged In: YES user_id=198518 The original poster to python-help replies: SYSTEM: SunOS indsv07 5.6 Generic_105181-19 sun4u sparc SUNW,Ultra-2 ????????????????Python2.2??????????????????????????????????????? ???????????? >>> locale.getpreferredencoding Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'getpreferredencoding' >>> locale.getpreferredencoding() Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'module' object has no attribute 'getpreferredencoding' >>> ???????????????????????????????????????????????????????????????? ?????? ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#1, Nov 26 2002, 10:37:00) [GCC 2.95.2 19991024 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> >>> locale._print_locale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<< Locale defaults as determined by getdefaultlocale(): ------------------------------------------------------------------------ Language: (undefined) Encoding: (undefined) Locale settings on startup: ------------------------------------------------------------------------ LC_NUMERIC ... Language: (undefined) Encoding: (undefined) LC_MESSAGES ... Language: (undefined) Encoding: (undefined) LC_MONETARY ... Language: (undefined) Encoding: (undefined) LC_COLLATE ... Language: (undefined) Encoding: (undefined) LC_CTYPE ... Language: (undefined) Encoding: (undefined) LC_TIME ... Language: (undefined) Encoding: (undefined) Locale settings after calling resetlocale(): ------------------------------------------------------------------------ LC_NUMERIC ... Language: (undefined) Encoding: (undefined) LC_MESSAGES ... Language: (undefined) Encoding: (undefined) LC_MONETARY ... Language: (undefined) Encoding: (undefined) LC_COLLATE ... Language: (undefined) Encoding: (undefined) LC_CTYPE ... Language: (undefined) Encoding: (undefined) LC_TIME ... Language: (undefined) Encoding: (undefined) Locale settings after calling setlocale(LC_ALL, ""): ------------------------------------------------------------------------ C_NUMERIC ... Language: (undefined) Encoding: (undefined) LC_MESSAGES ... Language: (undefined) Encoding: (undefined) LC_MONETARY ... Language: (undefined) Encoding: (undefined) LC_COLLATE ... Language: (undefined) Encoding: (undefined) LC_CTYPE ... Language: (undefined) Encoding: (undefined) LC_TIME ... Language: (undefined) Encoding: (undefined) >>> >>> locale._test() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 123456789 is 123456789 3.14 is 3.14 >>> locale.getlocale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (None, None) >>> locale.getdefaultlocale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< (None, None) >>> >>> locale.CODESET <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 49 >>> locale.localeconv() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< {'mon_decimal_point': '', 'int_frac_digits': 127, 'p_sep_by_space': 127, 'frac_digits': 127, 'thousands_sep': '', 'n_sign_posn': 127, 'decimal_point': '.', 'mon_thousands_sep': '', 'n_cs_precedes': 127, 'p_sign_posn': 127, 'int_curr_symbol': '', 'negative_sign': '', 'currency_symbol': '', 'n_sep_by_space': 127, 'mon_grouping': [], 'p_cs_precedes': 127, 'positive_sign': '', 'grouping': []} >>> >>> locale.getdefaultlocale() <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< < (None, None) ========================================= ========================================= ====== !!!!!!!!!!!!!!!!!!!!!! Unofficial install of 2.3 (same system) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ========================================= ========================================= ====== Python 2.3 (#1, Jul 31 2003, 09:16:42) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import locale >>> locale.getpreferredencoding() '' >>> ############# Here, I have done the same modifications in "idlelib...IObinding.py" but for Python 2.3 and I succeed in launching IDLE ###################### Python 2.3 (#1, Jul 31 2003, 09:16:42) [GCC 2.95.3 20010315 (release)] on sunos5 Type "copyright", "credits" or "license()" for more information. ******************************************************** ******** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ******************************************************** ******** IDLE 1.0 >>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> One last remark, last time I remenber that the problem of codec lookup also appeared in other circumstances than starting IDLE. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:05 Message: Logged In: YES user_id=21627 Can you report what operating system this was on, and what locale setting was in place? What is the value of locale.getpreferredencoding on that system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=808719&group_id=5470 From noreply at sourceforge.net Thu Aug 12 15:51:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 17:03:04 2004 Subject: [ python-Bugs-1007223 ] SGI (IRIX6.5.24) Problems building nismodule.c Message-ID: Bugs item #1007223, was opened at 2004-08-11 14:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007223&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Nobody/Anonymous (nobody) Summary: SGI (IRIX6.5.24) Problems building nismodule.c Initial Comment: Building python on SGI Irix 6.5.24 with MIPSpro Compilers Version 7.3.1.3m with: ./configure gmake gmake test The test shows that the test_nis.py failed. Running python from the build location: ./python >>> import nis >>> nis.maps() raises a nis.error "No NIS master found for any map". The Makefile has a LIBS-line (#151): LIBS=-lsocket -lnsl -ldl -lpthread -lmpz This line could be shortened to: LIBS=-lpthread After gmake distclean ./configure -> cleaning up the LIBS-line in Makefile gmake gmake test The nismodule could be successfull used. Why? Library libmpz isn't already installed on Irix 6.5.xx Library libdl isn't used for anything. Libraries libsocket and libnsl can't access the NIS. See intro(3) man-page .... (3N) There are actually 3 types of networking in IRIX. 1) BSD sockets implemented in the kernel, along with SUN RPC and NIS (YP). The functions that implement these calls are in libc [see (3C) section above]. 2) SVR4-style STREAMS/TLI networking (not sockets), along with SVR4-style RPC. SVR4-style RPC doesn't work with sockets, only with the TLI. Also, SVR4-style networking does not support NIS [see intro(3N)]. The functions that implement these calls are in libnsl, and to use them, the code must be compiled with : cc -D_SVR4_TIRPC prog.c -lnsl 3) SVR4 emulation of sockets. This is an implementation of sockets entirely in a library (libsocket) that sits on top of libnsl. There are no header file differences for libsocket. The MIPS ABI-compliant programs that use sockets must (in order to be ABI-compliant) link with libsocket. There is no NIS support for programs linked with libsocket [see intro(3N)]. To compile such a program, use: cc prog.c -lsocket (3Y) Remote Procedure Call (RPC) and NIS support routines. These functions are in the standard C library libc, already mentioned. ... Unfortunately I'm not a configure expert so I could only report the problem and a solution. --maik./ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-12 15:51 Message: Logged In: YES user_id=21627 Can you investigate in config.log where it refers to mpz for the first time? The configure file does never refer to mpz explicitly. Could it be that you have some environment variable set that influences configure? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007223&group_id=5470 From noreply at sourceforge.net Thu Aug 12 17:52:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 17:52:49 2004 Subject: [ python-Bugs-985154 ] HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin Message-ID: Bugs item #985154, was opened at 2004-07-04 22:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Jason Tishler (jlt63) Summary: HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin Initial Comment: Building 2.3.4 from the tarball, #define HAVE_FDATASYNC 1 appears in the pyconfig.h file, and the build of 'posixmodule' fails with undefined symbol _fdatasync Workaround is to delete the line and proceed, of course, but I've never seen this before when building under cygwin. There is no 'fdatasync' mentioned in any /usr/include/*.h or /usr/local/include/*.h The cygwin installation is kind of a mongrel (4 or 5 upgrades since install, some selective) This is the ID string from the built python: Python 2.3.4 (#2, Jul 4 2004, 22:10:22) [GCC 3.3.1 (cygming special)] on cygwin Let me know of any details of the cygwin install which might be useful. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-12 11:52 Message: Logged In: YES user_id=33168 Your wish is my command. :-) Closing as invalid, since this seems more a cygwin setup problem. Greg can re-open if he disagrees. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2004-08-09 12:43 Message: Logged In: YES user_id=86216 There has been no follow-up from Greg in a month. OK to close? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2004-07-08 07:10 Message: Logged In: YES user_id=86216 nnorwitz> Jason, do you know what the deal is with cygwin? AFAICT, Greg's Cygwin setup seems suspect. Actually, he alluded to this fact in the following: gregsmith> The cygwin installation is kind of a mongrel... On my Cygwin setup (i.e., 1.5.10-3), I have the following: /usr/include/sys/unistd.h: #ifndef __CYGWIN__ int _EXFUN(fdatasync, (int __fd)); #endif pyconfig.h: /* Define if you have the 'fdatasync' function. */ /* #undef HAVE_FDATASYNC */ Additionally, the official Cygwin Python package built cleanly. Greg, what version of Cygwin are you using? If not 1.5.10-3, then please upgrade and try again. If so, then your setup seems to be corrupted. Try reinstalling. Does it work any better now? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-07 21:32 Message: Logged In: YES user_id=33168 Jason, do you know what the deal is with cygwin? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-07 07:12 Message: Logged In: YES user_id=6656 Well, I guess that's an arguable bug in cygwin, but if you want to supply a patch that modifies configure to do the linking test too, I'll at least think about applying it :-) ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2004-07-05 21:58 Message: Logged In: YES user_id=292741 looked into config.log and 'configure' itself.. the compile for fdatasync succeeded, but the script does not attempt to link it. gcc -E led me to the following chunk of /usr/include/sys/unistd.h: (not inside any #ifdefs, as far as I can tell) int _EXFUN(fdatasync, (int __fd)); So it's declared in the header, but it's not in the library. This symbol is defined in libc.a on a RH8.0 system, I can't find it anywhere on the cygwin system. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-05 09:40 Message: Logged In: YES user_id=6656 That's odd. Why does configure think you have fdatasync? Maybe config.log will help... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470 From noreply at sourceforge.net Thu Aug 12 17:55:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 17:55:24 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 03:36 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 16:55 Message: Logged In: YES user_id=200117 I did a fresh install of Python-2.2a2 and applied your new patch, but I'm still getting compile errors for line 200: building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. Here are lines 198-203 after applying the patch #if Py_UNICODE_SIZE == 2 if (length == 2) { ucs4_t u4in [2] = {(ucs4_t)IN1, (ucs4_t)IN2}; encoded = dsg->encoder(u4in, &length); } else encoded = dsg->encoder(&c, &length); One of my collegues says that you can't initialise one variable with another variable, when using the cc compiler. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 14:03 Message: Logged In: YES user_id=55188 Thanks for testing! I uploaded new patch fixed the problem. Can you both test the patch whether it compiles? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 08:37 Message: Logged In: YES user_id=200117 After applying the patch I am still getting two comple errors on HP-UX 11i building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-11 23:14 Message: Logged In: YES user_id=55188 The attached patch converts C99 usages to plain legacy C. Can you please test it on HP-UX whether the problem is resolved? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-09 09:15 Message: Logged In: YES user_id=200117 I am getting slightly different errors on HP-UX 11i using the native C compiler 'cc'. building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 120: error 1578: Size of struct or union member is unknown. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1058: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1064: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1070: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1078: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1085: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1091: error 1523: Too many initializers. uname -a HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 06:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Thu Aug 12 17:57:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 17:57:35 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 03:36 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 16:57 Message: Logged In: YES user_id=200117 Oops! that was a fresh install of Python-2.4a2... ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 16:55 Message: Logged In: YES user_id=200117 I did a fresh install of Python-2.2a2 and applied your new patch, but I'm still getting compile errors for line 200: building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. Here are lines 198-203 after applying the patch #if Py_UNICODE_SIZE == 2 if (length == 2) { ucs4_t u4in [2] = {(ucs4_t)IN1, (ucs4_t)IN2}; encoded = dsg->encoder(u4in, &length); } else encoded = dsg->encoder(&c, &length); One of my collegues says that you can't initialise one variable with another variable, when using the cc compiler. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 14:03 Message: Logged In: YES user_id=55188 Thanks for testing! I uploaded new patch fixed the problem. Can you both test the patch whether it compiles? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 08:37 Message: Logged In: YES user_id=200117 After applying the patch I am still getting two comple errors on HP-UX 11i building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-11 23:14 Message: Logged In: YES user_id=55188 The attached patch converts C99 usages to plain legacy C. Can you please test it on HP-UX whether the problem is resolved? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-09 09:15 Message: Logged In: YES user_id=200117 I am getting slightly different errors on HP-UX 11i using the native C compiler 'cc'. building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 120: error 1578: Size of struct or union member is unknown. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1058: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1064: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1070: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1078: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1085: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1091: error 1523: Too many initializers. uname -a HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 06:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Thu Aug 12 18:39:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 18:39:27 2004 Subject: [ python-Bugs-1005248 ] new.code() not cleanly checking its arguments Message-ID: Bugs item #1005248, was opened at 2004-08-07 20:01 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: new.code() not cleanly checking its arguments Initial Comment: new.code() does not check its arguments properly: >>> new.code(1,1,1,0,"123",(None,),(5,),(5,),"123","321",2,"") Fatal Python error: non-string found in code slot Here the tuple (5,) is used for co_names and co_varnames. More generally it looks like this part of compile.c could do with quite some cleaning up. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-08-12 16:39 Message: Logged In: YES user_id=4771 Sounds reasonable. The patch looks OK. On a side note, PyCode_New() calls optimize_code(), but PyCode_New() is also used when un-marshalling .pyc files. I wonder how much time is lost re-optimizing in vain the code loaded from .pyc files, and I wonder why optimization is not done just as the last step of the compiler instead. While I'm wondering, I also wonder if some user bytecode hacks could be broken by optimize_code(). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 11:23 Message: Logged In: YES user_id=6656 > Why do you check for argcount<0 but not nlocals<0, which > also raises a SystemError? Because I didn't read that far... Obvious extension of patch added. Agree that current behaviour of PyCode_New is a bit crazy. OTOH, not changing PyCode_New itself seems a principle no worse than any other for the moment. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-09 10:54 Message: Logged In: YES user_id=4771 Why do you check for argcount<0 but not nlocals<0, which also raises a SystemError? More to the point, why on earth does PyCode_New() check for negative values of argcount and nlocals and not the other values? A negative stacksize, for example, is likely to crash the interpreter too. On the other hand, validating these numbers more precisely is much more complex, and not something we're trying to do here. So I don't understand why these two values in particular are checked for < 0. We should as well drop the check altogether. My position here is that calling new.code() shouldn't do anything bad to the interpreter; but actually executing the resulting code object is allowed to destroy the sun (provided, of course, that CPython runs in an environment that allows that). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 10:40 Message: Logged In: YES user_id=6656 Maybe new is meant to be scary, but current behaviour is going well above and beyond the effort required. new.code can mutate a tuple containing string subclasses into a tuple containing exact strings! Armin, what do you think of the attached? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-08 13:58 Message: Logged In: YES user_id=29957 I thought there was a general concensus that many things in the 'new' module could be used to make a mess, and that trying to fix them all was a pretty much open-ended task? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 From noreply at sourceforge.net Thu Aug 12 18:45:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 18:45:29 2004 Subject: [ python-Bugs-767150 ] socket.inet_aton on 64bit platform Message-ID: Bugs item #767150, was opened at 2003-07-07 08:03 Message generated for change (Comment added) made by mwichmann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767150&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: socket.inet_aton on 64bit platform Initial Comment: Hi, socket.inet_aton() returns an 8 byte string when built on Linux/IA64. This should be 4 bytes on all architectures. Example: >>> import socket >>> socket.inet_aton('192.168.2.1') '\xc0\xa8\x02\x01\x00\x00\x00\x00' The bug is caused by Modules/socketmodule.c using sizeof(unsinged long) when constructing the string, which is 8 bytes on Linux/IA64. The bug seems to be fixed in Python 2.3 in the case struct in_addr is available. Otherwise it still uses an unsigned long. Geert ---------------------------------------------------------------------- Comment By: Mats Wichmann (mwichmann) Date: 2004-08-12 10:45 Message: Logged In: YES user_id=53605 I've just run into this problem, which is still present in current cvs. This now (2.3.x and cvs head) occurs for the code path where inet_aton is not detected by configure, so it's not a terribly common case. Of course, I have one ... The conversion needs to be done on a 32-bit quantity. It's a one-liner to fix, I'll submit a patch if I can make the patch manager work for me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-07 15:10 Message: Logged In: YES user_id=21627 Can you try to come up with a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767150&group_id=5470 From noreply at sourceforge.net Thu Aug 12 19:58:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 19:58:46 2004 Subject: [ python-Bugs-1005248 ] new.code() not cleanly checking its arguments Message-ID: Bugs item #1005248, was opened at 2004-08-07 21:01 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Michael Hudson (mwh) Summary: new.code() not cleanly checking its arguments Initial Comment: new.code() does not check its arguments properly: >>> new.code(1,1,1,0,"123",(None,),(5,),(5,),"123","321",2,"") Fatal Python error: non-string found in code slot Here the tuple (5,) is used for co_names and co_varnames. More generally it looks like this part of compile.c could do with quite some cleaning up. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-12 18:58 Message: Logged In: YES user_id=6656 OK, checked in as Lib/test/test_new.py revision 1.18 Python/compile.c revision 2.314 I also rewrote all the tests of new.code() to use realistic arguments. > On a side note, PyCode_New() calls optimize_code(), but > PyCode_New() is also used when un-marshalling .pyc files. Yes, I noticed that too, and wondered some of the things you wondered. Ask Raymond? I think it's his code. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-12 17:39 Message: Logged In: YES user_id=4771 Sounds reasonable. The patch looks OK. On a side note, PyCode_New() calls optimize_code(), but PyCode_New() is also used when un-marshalling .pyc files. I wonder how much time is lost re-optimizing in vain the code loaded from .pyc files, and I wonder why optimization is not done just as the last step of the compiler instead. While I'm wondering, I also wonder if some user bytecode hacks could be broken by optimize_code(). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 12:23 Message: Logged In: YES user_id=6656 > Why do you check for argcount<0 but not nlocals<0, which > also raises a SystemError? Because I didn't read that far... Obvious extension of patch added. Agree that current behaviour of PyCode_New is a bit crazy. OTOH, not changing PyCode_New itself seems a principle no worse than any other for the moment. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-09 11:54 Message: Logged In: YES user_id=4771 Why do you check for argcount<0 but not nlocals<0, which also raises a SystemError? More to the point, why on earth does PyCode_New() check for negative values of argcount and nlocals and not the other values? A negative stacksize, for example, is likely to crash the interpreter too. On the other hand, validating these numbers more precisely is much more complex, and not something we're trying to do here. So I don't understand why these two values in particular are checked for < 0. We should as well drop the check altogether. My position here is that calling new.code() shouldn't do anything bad to the interpreter; but actually executing the resulting code object is allowed to destroy the sun (provided, of course, that CPython runs in an environment that allows that). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 11:40 Message: Logged In: YES user_id=6656 Maybe new is meant to be scary, but current behaviour is going well above and beyond the effort required. new.code can mutate a tuple containing string subclasses into a tuple containing exact strings! Armin, what do you think of the attached? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-08 14:58 Message: Logged In: YES user_id=29957 I thought there was a general concensus that many things in the 'new' module could be used to make a mess, and that trying to fix them all was a pretty much open-ended task? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 From noreply at sourceforge.net Thu Aug 12 21:40:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 21:40:53 2004 Subject: [ python-Bugs-1005113 ] test__locale fails on MacOS X Message-ID: Bugs item #1005113, was opened at 2004-08-07 15:23 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: test__locale fails on MacOS X Initial Comment: test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include #include int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks.... ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-12 21:40 Message: Logged In: YES user_id=580910 Many thanks to Bob Ippolito for finding what's going on... It turns out that CoreFoundation.framework calls __setonlyClocaleconv when it is loaded. As the name suggests this breaks the locale API's. I don't know what whoever added this "functionality" was smoking, but at least he had enough sense to make it possible to restore functionality. The prototype for __setonlyClocaleconv is: extern int __setonlyClocaleconv(int val); Experimentation shows that setting val to a non-zero value breaks setlocale and setting it to 0 re-enables setlocale. The function returns the previous setting. This means it is possible to create a workaround for this issue: 1) Add configure and/or weak-linking magic to detect the function 2) Call oldValue = __setonlyClocaleconv(0) before using a locale API 3) Call __setonlyClocaleconv(oldValue) after doing so. Would such a patch be accepted? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 21:14 Message: Logged In: YES user_id=357491 Ah! Nick Bastin and I were trying to solve this and noticed that in a straight C program it worked but under Python, no matter where you were, it was incorrect! Thanks for the insight! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 17:10 Message: Logged In: YES user_id=580910 Because this seems to be a bug in OSX I've filed a bug at bugreport.apple.com (radar#3754835) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 From noreply at sourceforge.net Thu Aug 12 23:28:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 23:34:48 2004 Subject: [ python-Bugs-1008275 ] os.getstatusoutput on win32 Message-ID: Bugs item #1008275, was opened at 2004-08-12 21:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008275&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chmouel Boudjnah (chmou) Assigned to: Nobody/Anonymous (nobody) Summary: os.getstatusoutput on win32 Initial Comment: Using: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 i cannot run command.getstatusoutput since i guess it expect a unix shell. >>> import commands >>> commands.getstatusoutput("c://usr//bin//echo") (1, "'{' n'est pas reconnu en tant que commande interne\nou externe, un programm e ex\x82cutable ou un fichier de commandes.") i had to bypass it on win32 by using this in my program : def _getstatusoutput(cmd): """Return Win32 (status, output) of executing cmd in a shell.""" pipe = os.popen(cmd, 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text Cheers, Chmouel. http://www.chmouel.com/wp/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008275&group_id=5470 From noreply at sourceforge.net Thu Aug 12 23:56:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 12 23:56:36 2004 Subject: [ python-Bugs-1008295 ] logging.getLevelName returns a number Message-ID: Bugs item #1008295, was opened at 2004-08-12 18:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paulo Eduardo Neves (neves) Assigned to: Nobody/Anonymous (nobody) Summary: logging.getLevelName returns a number Initial Comment: logging.getLevelName function doc says that it returns the "textual representation of logging level", but if the argument is already the level name, the log level integer is returned. It should return the argument. The problem is that if I add my own levels, and call LoggerInstance.log( levelName, message ), the formatter will save the level number in the log, insted of the desired level name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 From noreply at sourceforge.net Fri Aug 13 00:19:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 00:19:19 2004 Subject: [ python-Bugs-1005113 ] test__locale fails on MacOS X Message-ID: Bugs item #1005113, was opened at 2004-08-07 06:23 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: test__locale fails on MacOS X Initial Comment: test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include #include int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks.... ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-12 15:19 Message: Logged In: YES user_id=357491 I think modifying configure.in to detect the function is unnecessary; Darwin will be the only platform with it (Googling shows the CVS commit for Darwin that added the call to _CFInitialize() that probably set this whole problem off, so just blanket settting it (unless it is somehow new to OS X 10.3 or something) based on an ``#ifdef __APPLE__`` will probably be fine. But knowing that function was explicitly added in a version would lead to requiring a configure.in check. The next question becomes whether setting that value is a permanent settting in CoreFoundation until it is unloaded, or if it is just per run of an app. If it is the former, then setting it period might be bad since that would affect other running apps. But if Python is loaded against its own copy of CoreFoundation and it is local to Python then who cares; set the thing before any locale code is used and be done with it. And as for accepting a patch, I know I would be happy with accepting it, but I would want Martin v. Lowis' input first to make sure this is the best thing to do. Otherwise setlocale() should be changed to make it always raise an exception when __setonlyClocaleconv() is around. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-12 12:40 Message: Logged In: YES user_id=580910 Many thanks to Bob Ippolito for finding what's going on... It turns out that CoreFoundation.framework calls __setonlyClocaleconv when it is loaded. As the name suggests this breaks the locale API's. I don't know what whoever added this "functionality" was smoking, but at least he had enough sense to make it possible to restore functionality. The prototype for __setonlyClocaleconv is: extern int __setonlyClocaleconv(int val); Experimentation shows that setting val to a non-zero value breaks setlocale and setting it to 0 re-enables setlocale. The function returns the previous setting. This means it is possible to create a workaround for this issue: 1) Add configure and/or weak-linking magic to detect the function 2) Call oldValue = __setonlyClocaleconv(0) before using a locale API 3) Call __setonlyClocaleconv(oldValue) after doing so. Would such a patch be accepted? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:14 Message: Logged In: YES user_id=357491 Ah! Nick Bastin and I were trying to solve this and noticed that in a straight C program it worked but under Python, no matter where you were, it was incorrect! Thanks for the insight! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 08:10 Message: Logged In: YES user_id=580910 Because this seems to be a bug in OSX I've filed a bug at bugreport.apple.com (radar#3754835) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 From noreply at sourceforge.net Fri Aug 13 00:21:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 00:21:58 2004 Subject: [ python-Bugs-1008310 ] os.major() os.minor() example and description change Message-ID: Bugs item #1008310, was opened at 2004-08-12 15:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008310&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven (grayshark) Assigned to: Nobody/Anonymous (nobody) Summary: os.major() os.minor() example and description change Initial Comment: The description for os.major() and os.minor() are damn poor. major( device) Extracts a device major number from a raw device number. New in version 2.3. minor( device) Extracts a device minor number from a raw device number. New in version 2.3. The really bad part is the term "raw device number". it should be: Extracts a device [major,minor] number for stat st_rdev field, or returns a zero if the st_rdev does not reference a special block device. Example follows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008310&group_id=5470 From noreply at sourceforge.net Fri Aug 13 00:22:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 00:22:35 2004 Subject: [ python-Bugs-1008310 ] os.major() os.minor() example and description change Message-ID: Bugs item #1008310, was opened at 2004-08-12 15:21 Message generated for change (Settings changed) made by grayshark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008310&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven (grayshark) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.major() os.minor() example and description change Initial Comment: The description for os.major() and os.minor() are damn poor. major( device) Extracts a device major number from a raw device number. New in version 2.3. minor( device) Extracts a device minor number from a raw device number. New in version 2.3. The really bad part is the term "raw device number". it should be: Extracts a device [major,minor] number for stat st_rdev field, or returns a zero if the st_rdev does not reference a special block device. Example follows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008310&group_id=5470 From noreply at sourceforge.net Fri Aug 13 00:32:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 00:32:13 2004 Subject: [ python-Bugs-1005113 ] test__locale fails on MacOS X Message-ID: Bugs item #1005113, was opened at 2004-08-07 06:23 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Jack Jansen (jackjansen) Summary: test__locale fails on MacOS X Initial Comment: test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include #include int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks.... ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-12 15:32 Message: Logged In: YES user_id=357491 I just talked to a friend of mine and it looks like the function is gone from Tiger so this might not be a problem in the future. Plus, I don't know if we should be trying to work around this. Perhaps we should try to do this the proper way using CF for locale support? Don't know. At worst we should at least raise an exception for setlocale() . This is getting OS X specific enough to need input from Jack, so assigning to him. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-12 15:19 Message: Logged In: YES user_id=357491 I think modifying configure.in to detect the function is unnecessary; Darwin will be the only platform with it (Googling shows the CVS commit for Darwin that added the call to _CFInitialize() that probably set this whole problem off, so just blanket settting it (unless it is somehow new to OS X 10.3 or something) based on an ``#ifdef __APPLE__`` will probably be fine. But knowing that function was explicitly added in a version would lead to requiring a configure.in check. The next question becomes whether setting that value is a permanent settting in CoreFoundation until it is unloaded, or if it is just per run of an app. If it is the former, then setting it period might be bad since that would affect other running apps. But if Python is loaded against its own copy of CoreFoundation and it is local to Python then who cares; set the thing before any locale code is used and be done with it. And as for accepting a patch, I know I would be happy with accepting it, but I would want Martin v. Lowis' input first to make sure this is the best thing to do. Otherwise setlocale() should be changed to make it always raise an exception when __setonlyClocaleconv() is around. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-12 12:40 Message: Logged In: YES user_id=580910 Many thanks to Bob Ippolito for finding what's going on... It turns out that CoreFoundation.framework calls __setonlyClocaleconv when it is loaded. As the name suggests this breaks the locale API's. I don't know what whoever added this "functionality" was smoking, but at least he had enough sense to make it possible to restore functionality. The prototype for __setonlyClocaleconv is: extern int __setonlyClocaleconv(int val); Experimentation shows that setting val to a non-zero value breaks setlocale and setting it to 0 re-enables setlocale. The function returns the previous setting. This means it is possible to create a workaround for this issue: 1) Add configure and/or weak-linking magic to detect the function 2) Call oldValue = __setonlyClocaleconv(0) before using a locale API 3) Call __setonlyClocaleconv(oldValue) after doing so. Would such a patch be accepted? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:14 Message: Logged In: YES user_id=357491 Ah! Nick Bastin and I were trying to solve this and noticed that in a straight C program it worked but under Python, no matter where you were, it was incorrect! Thanks for the insight! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 08:10 Message: Logged In: YES user_id=580910 Because this seems to be a bug in OSX I've filed a bug at bugreport.apple.com (radar#3754835) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 From noreply at sourceforge.net Fri Aug 13 02:15:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 02:15:13 2004 Subject: [ python-Bugs-1008295 ] logging.getLevelName returns a number Message-ID: Bugs item #1008295, was opened at 2004-08-12 16:56 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paulo Eduardo Neves (neves) >Assigned to: Vinay Sajip (vsajip) Summary: logging.getLevelName returns a number Initial Comment: logging.getLevelName function doc says that it returns the "textual representation of logging level", but if the argument is already the level name, the log level integer is returned. It should return the argument. The problem is that if I add my own levels, and call LoggerInstance.log( levelName, message ), the formatter will save the level number in the log, insted of the desired level name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 From noreply at sourceforge.net Fri Aug 13 07:43:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 07:43:20 2004 Subject: [ python-Bugs-1005113 ] test__locale fails on MacOS X Message-ID: Bugs item #1005113, was opened at 2004-08-07 15:23 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: test__locale fails on MacOS X Initial Comment: test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include #include int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks.... ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-13 07:43 Message: Logged In: YES user_id=580910 According to Bob the "feature" is present in the Tiger DP. I haven't checked this myself yet. I also haven't check older versions of the OS. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-13 00:32 Message: Logged In: YES user_id=357491 I just talked to a friend of mine and it looks like the function is gone from Tiger so this might not be a problem in the future. Plus, I don't know if we should be trying to work around this. Perhaps we should try to do this the proper way using CF for locale support? Don't know. At worst we should at least raise an exception for setlocale() . This is getting OS X specific enough to need input from Jack, so assigning to him. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-13 00:19 Message: Logged In: YES user_id=357491 I think modifying configure.in to detect the function is unnecessary; Darwin will be the only platform with it (Googling shows the CVS commit for Darwin that added the call to _CFInitialize() that probably set this whole problem off, so just blanket settting it (unless it is somehow new to OS X 10.3 or something) based on an ``#ifdef __APPLE__`` will probably be fine. But knowing that function was explicitly added in a version would lead to requiring a configure.in check. The next question becomes whether setting that value is a permanent settting in CoreFoundation until it is unloaded, or if it is just per run of an app. If it is the former, then setting it period might be bad since that would affect other running apps. But if Python is loaded against its own copy of CoreFoundation and it is local to Python then who cares; set the thing before any locale code is used and be done with it. And as for accepting a patch, I know I would be happy with accepting it, but I would want Martin v. Lowis' input first to make sure this is the best thing to do. Otherwise setlocale() should be changed to make it always raise an exception when __setonlyClocaleconv() is around. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-12 21:40 Message: Logged In: YES user_id=580910 Many thanks to Bob Ippolito for finding what's going on... It turns out that CoreFoundation.framework calls __setonlyClocaleconv when it is loaded. As the name suggests this breaks the locale API's. I don't know what whoever added this "functionality" was smoking, but at least he had enough sense to make it possible to restore functionality. The prototype for __setonlyClocaleconv is: extern int __setonlyClocaleconv(int val); Experimentation shows that setting val to a non-zero value breaks setlocale and setting it to 0 re-enables setlocale. The function returns the previous setting. This means it is possible to create a workaround for this issue: 1) Add configure and/or weak-linking magic to detect the function 2) Call oldValue = __setonlyClocaleconv(0) before using a locale API 3) Call __setonlyClocaleconv(oldValue) after doing so. Would such a patch be accepted? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 21:14 Message: Logged In: YES user_id=357491 Ah! Nick Bastin and I were trying to solve this and noticed that in a straight C program it worked but under Python, no matter where you were, it was incorrect! Thanks for the insight! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 17:10 Message: Logged In: YES user_id=580910 Because this seems to be a bug in OSX I've filed a bug at bugreport.apple.com (radar#3754835) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 From noreply at sourceforge.net Fri Aug 13 10:30:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 10:30:24 2004 Subject: [ python-Bugs-1005248 ] new.code() not cleanly checking its arguments Message-ID: Bugs item #1005248, was opened at 2004-08-07 20:01 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Michael Hudson (mwh) Summary: new.code() not cleanly checking its arguments Initial Comment: new.code() does not check its arguments properly: >>> new.code(1,1,1,0,"123",(None,),(5,),(5,),"123","321",2,"") Fatal Python error: non-string found in code slot Here the tuple (5,) is used for co_names and co_varnames. More generally it looks like this part of compile.c could do with quite some cleaning up. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-08-13 08:30 Message: Logged In: YES user_id=4771 Raymond said: not worth the burden. The optimizer is "experimental and not fully developed". It is also superfast, so it doesn't matter. The AST branch will change all this anyway. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-12 17:58 Message: Logged In: YES user_id=6656 OK, checked in as Lib/test/test_new.py revision 1.18 Python/compile.c revision 2.314 I also rewrote all the tests of new.code() to use realistic arguments. > On a side note, PyCode_New() calls optimize_code(), but > PyCode_New() is also used when un-marshalling .pyc files. Yes, I noticed that too, and wondered some of the things you wondered. Ask Raymond? I think it's his code. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-12 16:39 Message: Logged In: YES user_id=4771 Sounds reasonable. The patch looks OK. On a side note, PyCode_New() calls optimize_code(), but PyCode_New() is also used when un-marshalling .pyc files. I wonder how much time is lost re-optimizing in vain the code loaded from .pyc files, and I wonder why optimization is not done just as the last step of the compiler instead. While I'm wondering, I also wonder if some user bytecode hacks could be broken by optimize_code(). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 11:23 Message: Logged In: YES user_id=6656 > Why do you check for argcount<0 but not nlocals<0, which > also raises a SystemError? Because I didn't read that far... Obvious extension of patch added. Agree that current behaviour of PyCode_New is a bit crazy. OTOH, not changing PyCode_New itself seems a principle no worse than any other for the moment. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-09 10:54 Message: Logged In: YES user_id=4771 Why do you check for argcount<0 but not nlocals<0, which also raises a SystemError? More to the point, why on earth does PyCode_New() check for negative values of argcount and nlocals and not the other values? A negative stacksize, for example, is likely to crash the interpreter too. On the other hand, validating these numbers more precisely is much more complex, and not something we're trying to do here. So I don't understand why these two values in particular are checked for < 0. We should as well drop the check altogether. My position here is that calling new.code() shouldn't do anything bad to the interpreter; but actually executing the resulting code object is allowed to destroy the sun (provided, of course, that CPython runs in an environment that allows that). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 10:40 Message: Logged In: YES user_id=6656 Maybe new is meant to be scary, but current behaviour is going well above and beyond the effort required. new.code can mutate a tuple containing string subclasses into a tuple containing exact strings! Armin, what do you think of the attached? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-08 13:58 Message: Logged In: YES user_id=29957 I thought there was a general concensus that many things in the 'new' module could be used to make a mess, and that trying to fix them all was a pretty much open-ended task? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 From noreply at sourceforge.net Fri Aug 13 11:29:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 11:29:50 2004 Subject: [ python-Bugs-1008275 ] os.getstatusoutput on win32 Message-ID: Bugs item #1008275, was opened at 2004-08-13 07:28 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008275&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chmouel Boudjnah (chmou) Assigned to: Nobody/Anonymous (nobody) Summary: os.getstatusoutput on win32 Initial Comment: Using: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 i cannot run command.getstatusoutput since i guess it expect a unix shell. >>> import commands >>> commands.getstatusoutput("c://usr//bin//echo") (1, "'{' n'est pas reconnu en tant que commande interne\nou externe, un programm e ex\x82cutable ou un fichier de commandes.") i had to bypass it on win32 by using this in my program : def _getstatusoutput(cmd): """Return Win32 (status, output) of executing cmd in a shell.""" pipe = os.popen(cmd, 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text Cheers, Chmouel. http://www.chmouel.com/wp/ ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-13 19:29 Message: Logged In: YES user_id=1038590 Well, the docs for the commands module explicitly state that it is only supported on Unix. While two of the functions it provides (getstatusoutput() and getoutput()) are trivial to provide on Windows, the 3rd (getstatus()) has no equivalent that I can see. I think I'll take this one to py-dev for further consideration ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008275&group_id=5470 From noreply at sourceforge.net Fri Aug 13 15:36:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 15:36:57 2004 Subject: [ python-Bugs-1008690 ] Incorrect href in Tutorial. Message-ID: Bugs item #1008690, was opened at 2004-08-13 15:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008690&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect href in Tutorial. Initial Comment: It seems like the always has a href="genindex.html" attribute. However, the tutorial uses the --numeric option to mkhowto, so the index lives at node18.html, making this an invalid link. I don't understand the documentation building tools well enough to fix this, so I'm assigning this to Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008690&group_id=5470 From noreply at sourceforge.net Fri Aug 13 15:37:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 15:37:39 2004 Subject: [ python-Bugs-1008690 ] Incorrect href in Tutorial. Message-ID: Bugs item #1008690, was opened at 2004-08-13 15:36 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008690&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Incorrect href in Tutorial. Initial Comment: It seems like the always has a href="genindex.html" attribute. However, the tutorial uses the --numeric option to mkhowto, so the index lives at node18.html, making this an invalid link. I don't understand the documentation building tools well enough to fix this, so I'm assigning this to Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008690&group_id=5470 From noreply at sourceforge.net Fri Aug 13 16:15:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 16:15:38 2004 Subject: [ python-Bugs-738154 ] pdb doesn't find some source files Message-ID: Bugs item #738154, was opened at 2003-05-15 11:53 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738154&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: pdb doesn't find some source files Initial Comment: In python 2.2.2 code object attribute co_filename contains relative to sys.path path (in python 2.3 the path is absolute), so pdb doesn't find some source files (for example, in the site-packages directory). The attached patch extends functionality of the bdb.Bdb.canonic method up to searching source files in sys.path. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 16:15 Message: Logged In: YES user_id=469548 I'm not sure I understand the problem. I can do the following just fine (on 2.2, 2.3 and 2.4 CVS): (Pdb) b bikeemacs.py:32 Breakpoint 1 at /usr/lib/python2.3/site-packages/bikeemacs.py:32 Could you clarify? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738154&group_id=5470 From noreply at sourceforge.net Fri Aug 13 19:08:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 19:08:43 2004 Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur Message-ID: Bugs item #570300, was opened at 2002-06-18 03:24 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 3 Submitted By: Amit Aronovitch (amitar) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getmodule symlink-related failur Initial Comment: news:ae3e29$pib$1@news.netvision.net.il Description: -------------- On a unix python2.2.1 installation I noticed that the documentations generated for modules by pydoc (in any mode - even the help command) did NOT contain any docs for functions. After some digging, I found out the reason for that, and now I believe it indicates a deeper problem with the "inspect" module, concerning file identification in the presence of symbolic or hard links, which I'll explain below, and also suggest solutions. Analysis: ----------- The reason the functions were dropped from the doc was pydoc's attempt to remove functions which were imported from other modules. This is done by something like "inspect.getmodule(my_func) is my_module". I found out that inspect.getmodule() returned "None" for these functions! Now, inspect.getmodule works by getting the function's filename, and then searching it in a dictionary containing the filenames for all the modules that were loaded ("modulesbyfile"). Unfortunately, the filename that getabsfile() returns for the function is not the same STRING as the one it returns for the module, but rather an equivalent unix path pointing to the same FILE (the reason for this fact is that the filename for a function is extracted from the code-object, which holds the path the module was referred to at the time it was COMPILED to .pyc, whereas the one for the module is taken from it's __file__, which holds the path it was referred to when it was IMPORTED - these two might differ even if it's the same file). So, the function's file is not found on the dictionary, and getmodule() returns None... Discussion: -------------- We see that the root cause of the problem is that "inspect" uses the "absolute path" (os.path.abspath()) for representing the file's identity. In unix systems, this might cause a problem, since this string is NOT unique (it is a unique path, but different paths may refer to the same file). If we only considered symbolic links, this could be resolved by scanning the path elements and "unfolding" any symlinks, but we must recall that unix can also has "hard links" which are equivalent references to the same inode, and can't be discriminated. So, if we want to resolve the problem in a portable way, we need an immutable (platform-dependant) object that will be unique to a FILE. This object could then be used for comparing files and as keys for dictionaries. A reasonable way to get it would be by means of a new function in the os module. e.g. : id = os.get_fileid(filename) def samefile(f1,f2): return os.get_fileid(f1) is os.get_fileid(f2) This function could be implemented by the inode number (os.stat(f).st_ino) on unix systems, and by the absolute path (os.path.abspath) on systems which do not support links (such as windows), or by anything else, as long as it would be immutable and unique for each file. Please let me know your opinion about this suggestion, Amit Aronovitch ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 19:08 Message: Logged In: YES user_id=469548 I can reproduce the problem using the steps outlined below. Replacing the line (it's not even worth creating a new patch item): modulesbyfile[getabsfile(module)] = module.__name__ with modulesbyfile[os.path.realpath(getabsfile(module))] = module.__name__ fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-13 02:26 Message: Logged In: YES user_id=357491 Well, when a bug gets old and you don't have a test to make sure it has been fixed, yes, things just do "go away" in the stdlib. The amount of code change in the stdlib can easily lead to some other bug being fixed. And I did read it. But when the problem stopped presenting itself to me (and I don't know why; I spent a good amount of time on this on the July 10 Bug Day)?I figured it was gone. If I can't reproduce it I can't try to fix it. But if you can come up with a patch to fix this feel free to assign it to me. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-07-13 00:08 Message: Logged In: YES user_id=564711 In my experience, problems don't just "go away" by themselves. Someone needs to actually fix them. So, I tested on 2.4a - and results are EXACTLY THE SAME (attached printout). It seems that no-one got to actually READ this lengthy description, so I'll have to send patches. Sorry I did not do that already, and sorry again but it seems I'm not going to get to that soon enough. I'll try to get it done by the end of July. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-10 20:23 Message: Logged In: YES user_id=357491 Well, looks like this problem has gone away, at least in 2.4. Closing out outdated. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2003-05-18 22:10 Message: Logged In: YES user_id=564711 Sorry - seems like I forgot most basic step in prob- reporting - the "howtorepeat" :-) - so here it comes: How to repeat: ---------------------- (as I said - you need unix & symlinks to see this happening): ~> mkdir test ~> setenv PYTHONPATH ~/test ~> cat >test/test_mod.py "module doc" def blah(): "hello" pass ^D ~> python >> import test_mod >> help(test_mod) >> ^D [ Prints help - so far so good - no problem - but see now] ~> ln -s test test2 ~> setenv PYTHONPATH test2 ~> python >> import test_mod >> help(test_mod) [ Now the help shows up without the help of the blah function] Relating the example to my explanations above: ------------------------------------------------------------------------ The help of the blah() function is filtered out, because "inspect" takes "~/test/test_mod.pyc" as it's filename, and "~/test1/test_mod.pyc" as the module's filename. It can't tell that these are the same file (see details in my "Analysis" section above). True, this messing up with symlinks and PYTHONPATH is a bit ugly, but this is just to demonstrate the problem. The system where I noticed it is quite complex, with disks shared (automounted) across several platforms, and it needs a few symlinks to make things easyer to maintain. As I explained, I think that few little changes in modules such as "inspect" and "os" can make them identify files better in the presence of links. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 04:34 Message: Logged In: YES user_id=357491 Just tested under 2.2.2 and 2.3b1 using a module containing just:: def blah(): """Hello"""" pass Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the name of the function and its docstring. Am I missing something here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 From noreply at sourceforge.net Fri Aug 13 19:38:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 19:38:24 2004 Subject: [ python-Bugs-1005113 ] test__locale fails on MacOS X Message-ID: Bugs item #1005113, was opened at 2004-08-07 06:23 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: test__locale fails on MacOS X Initial Comment: test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include #include int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks.... ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-13 10:38 Message: Logged In: YES user_id=357491 They must have removed it between the Tiger test release and now since my friend has checkin rights on that part of the tree at Apple. Regardless, I am leaning towards having setlocale() raise an exception under OS X until we can possibly wrap CF stuff since __setonlyClocaleconv() is obviously not a public function and thus not meant for us to play with. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-12 22:43 Message: Logged In: YES user_id=580910 According to Bob the "feature" is present in the Tiger DP. I haven't checked this myself yet. I also haven't check older versions of the OS. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-12 15:32 Message: Logged In: YES user_id=357491 I just talked to a friend of mine and it looks like the function is gone from Tiger so this might not be a problem in the future. Plus, I don't know if we should be trying to work around this. Perhaps we should try to do this the proper way using CF for locale support? Don't know. At worst we should at least raise an exception for setlocale() . This is getting OS X specific enough to need input from Jack, so assigning to him. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-12 15:19 Message: Logged In: YES user_id=357491 I think modifying configure.in to detect the function is unnecessary; Darwin will be the only platform with it (Googling shows the CVS commit for Darwin that added the call to _CFInitialize() that probably set this whole problem off, so just blanket settting it (unless it is somehow new to OS X 10.3 or something) based on an ``#ifdef __APPLE__`` will probably be fine. But knowing that function was explicitly added in a version would lead to requiring a configure.in check. The next question becomes whether setting that value is a permanent settting in CoreFoundation until it is unloaded, or if it is just per run of an app. If it is the former, then setting it period might be bad since that would affect other running apps. But if Python is loaded against its own copy of CoreFoundation and it is local to Python then who cares; set the thing before any locale code is used and be done with it. And as for accepting a patch, I know I would be happy with accepting it, but I would want Martin v. Lowis' input first to make sure this is the best thing to do. Otherwise setlocale() should be changed to make it always raise an exception when __setonlyClocaleconv() is around. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-12 12:40 Message: Logged In: YES user_id=580910 Many thanks to Bob Ippolito for finding what's going on... It turns out that CoreFoundation.framework calls __setonlyClocaleconv when it is loaded. As the name suggests this breaks the locale API's. I don't know what whoever added this "functionality" was smoking, but at least he had enough sense to make it possible to restore functionality. The prototype for __setonlyClocaleconv is: extern int __setonlyClocaleconv(int val); Experimentation shows that setting val to a non-zero value breaks setlocale and setting it to 0 re-enables setlocale. The function returns the previous setting. This means it is possible to create a workaround for this issue: 1) Add configure and/or weak-linking magic to detect the function 2) Call oldValue = __setonlyClocaleconv(0) before using a locale API 3) Call __setonlyClocaleconv(oldValue) after doing so. Would such a patch be accepted? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:14 Message: Logged In: YES user_id=357491 Ah! Nick Bastin and I were trying to solve this and noticed that in a straight C program it worked but under Python, no matter where you were, it was incorrect! Thanks for the insight! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 08:10 Message: Logged In: YES user_id=580910 Because this seems to be a bug in OSX I've filed a bug at bugreport.apple.com (radar#3754835) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 From noreply at sourceforge.net Fri Aug 13 20:47:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 13 20:47:29 2004 Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur Message-ID: Bugs item #570300, was opened at 2002-06-17 18:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Amit Aronovitch (amitar) >Assigned to: Brett Cannon (bcannon) Summary: inspect.getmodule symlink-related failur Initial Comment: news:ae3e29$pib$1@news.netvision.net.il Description: -------------- On a unix python2.2.1 installation I noticed that the documentations generated for modules by pydoc (in any mode - even the help command) did NOT contain any docs for functions. After some digging, I found out the reason for that, and now I believe it indicates a deeper problem with the "inspect" module, concerning file identification in the presence of symbolic or hard links, which I'll explain below, and also suggest solutions. Analysis: ----------- The reason the functions were dropped from the doc was pydoc's attempt to remove functions which were imported from other modules. This is done by something like "inspect.getmodule(my_func) is my_module". I found out that inspect.getmodule() returned "None" for these functions! Now, inspect.getmodule works by getting the function's filename, and then searching it in a dictionary containing the filenames for all the modules that were loaded ("modulesbyfile"). Unfortunately, the filename that getabsfile() returns for the function is not the same STRING as the one it returns for the module, but rather an equivalent unix path pointing to the same FILE (the reason for this fact is that the filename for a function is extracted from the code-object, which holds the path the module was referred to at the time it was COMPILED to .pyc, whereas the one for the module is taken from it's __file__, which holds the path it was referred to when it was IMPORTED - these two might differ even if it's the same file). So, the function's file is not found on the dictionary, and getmodule() returns None... Discussion: -------------- We see that the root cause of the problem is that "inspect" uses the "absolute path" (os.path.abspath()) for representing the file's identity. In unix systems, this might cause a problem, since this string is NOT unique (it is a unique path, but different paths may refer to the same file). If we only considered symbolic links, this could be resolved by scanning the path elements and "unfolding" any symlinks, but we must recall that unix can also has "hard links" which are equivalent references to the same inode, and can't be discriminated. So, if we want to resolve the problem in a portable way, we need an immutable (platform-dependant) object that will be unique to a FILE. This object could then be used for comparing files and as keys for dictionaries. A reasonable way to get it would be by means of a new function in the os module. e.g. : id = os.get_fileid(filename) def samefile(f1,f2): return os.get_fileid(f1) is os.get_fileid(f2) This function could be implemented by the inode number (os.stat(f).st_ino) on unix systems, and by the absolute path (os.path.abspath) on systems which do not support links (such as windows), or by anything else, as long as it would be immutable and unique for each file. Please let me know your opinion about this suggestion, Amit Aronovitch ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-13 11:47 Message: Logged In: YES user_id=357491 Checked in as rev. 1.52 for 'inspect'. Not going to backport since it is a semantic change. Thanks for the patch, Johannes. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 10:08 Message: Logged In: YES user_id=469548 I can reproduce the problem using the steps outlined below. Replacing the line (it's not even worth creating a new patch item): modulesbyfile[getabsfile(module)] = module.__name__ with modulesbyfile[os.path.realpath(getabsfile(module))] = module.__name__ fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-12 17:26 Message: Logged In: YES user_id=357491 Well, when a bug gets old and you don't have a test to make sure it has been fixed, yes, things just do "go away" in the stdlib. The amount of code change in the stdlib can easily lead to some other bug being fixed. And I did read it. But when the problem stopped presenting itself to me (and I don't know why; I spent a good amount of time on this on the July 10 Bug Day)?I figured it was gone. If I can't reproduce it I can't try to fix it. But if you can come up with a patch to fix this feel free to assign it to me. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-07-12 15:08 Message: Logged In: YES user_id=564711 In my experience, problems don't just "go away" by themselves. Someone needs to actually fix them. So, I tested on 2.4a - and results are EXACTLY THE SAME (attached printout). It seems that no-one got to actually READ this lengthy description, so I'll have to send patches. Sorry I did not do that already, and sorry again but it seems I'm not going to get to that soon enough. I'll try to get it done by the end of July. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-10 11:23 Message: Logged In: YES user_id=357491 Well, looks like this problem has gone away, at least in 2.4. Closing out outdated. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2003-05-18 13:10 Message: Logged In: YES user_id=564711 Sorry - seems like I forgot most basic step in prob- reporting - the "howtorepeat" :-) - so here it comes: How to repeat: ---------------------- (as I said - you need unix & symlinks to see this happening): ~> mkdir test ~> setenv PYTHONPATH ~/test ~> cat >test/test_mod.py "module doc" def blah(): "hello" pass ^D ~> python >> import test_mod >> help(test_mod) >> ^D [ Prints help - so far so good - no problem - but see now] ~> ln -s test test2 ~> setenv PYTHONPATH test2 ~> python >> import test_mod >> help(test_mod) [ Now the help shows up without the help of the blah function] Relating the example to my explanations above: ------------------------------------------------------------------------ The help of the blah() function is filtered out, because "inspect" takes "~/test/test_mod.pyc" as it's filename, and "~/test1/test_mod.pyc" as the module's filename. It can't tell that these are the same file (see details in my "Analysis" section above). True, this messing up with symlinks and PYTHONPATH is a bit ugly, but this is just to demonstrate the problem. The system where I noticed it is quite complex, with disks shared (automounted) across several platforms, and it needs a few symlinks to make things easyer to maintain. As I explained, I think that few little changes in modules such as "inspect" and "os" can make them identify files better in the presence of links. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 19:34 Message: Logged In: YES user_id=357491 Just tested under 2.2.2 and 2.3b1 using a module containing just:: def blah(): """Hello"""" pass Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the name of the function and its docstring. Am I missing something here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 From noreply at sourceforge.net Sat Aug 14 00:30:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 00:30:48 2004 Subject: [ python-Bugs-1008998 ] vertical bar typeset horizontal in docs Message-ID: Bugs item #1008998, was opened at 2004-08-13 17:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008998&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: vertical bar typeset horizontal in docs Initial Comment: I noticed a bug in the PDF version of the Python 2.3 docs. The PDF production tries to typeset the vertical bar '|' in textmode. An example of this problem is the documentation for set union, which looks like s--t instead of s|t. To typeset the vertical bar either i. use $|$ ii. use \texttt{|} or iii. change the encoding ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008998&group_id=5470 From noreply at sourceforge.net Sat Aug 14 00:57:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 00:57:15 2004 Subject: [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 16:04 Message generated for change (Comment added) made by hakansonsf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-13 15:57 Message: Logged In: YES user_id=1103758 Folks, I recently completed a build of python-2.3.2 (I realize 2.3.4 is out, but this info should still be relevant) on SPARC/Solaris-9, and as in this bug, the test_ioctl is failing. However, I believe I have found the cause, after running the tests with "-v" added to TESTOPTS in the Makefile. Since I have found no other mention of this particular cause for the failure, perhaps others will find this information helpful. The test is failing because the process group returned from the OS (the getpgrp() system call) does not match the process group associated with /dev/tty (as returned by the TIOCGPGRP ioctl() call). Now it turns out that this is not really an error, because some command shells (ksh, csh, perhaps bash), will assign each new command to a new process group, in order to do job-control (^Z interruption, moving to/from background, etc.). So, at least on this platform, using ksh, the test_ioctl will _always_ fail, since the "make" command gets a process group different from that of the parent shell, and different from /dev/tty's process group (which matches the parent shell). Therefor it would probably be better to test some other ioctl() call than the TIOCGPGRP call, or otherwise rework the test so it doesn't fail under what can be normal circumstances on some platforms. Regards, Marion ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-05 03:48 Message: Logged In: YES user_id=6656 You're supposed to run ./python ./Lib/test/regrtest.py test_ioctl or maybe ./python ./Lib/test/regrtest.py -v test_ioctl ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 00:39 Message: Logged In: YES user_id=91293 Blah. I was too hasty: while "./python ./Lib/test/test_ioctl.py" passed after making the modification I mentioned, a re-run of "make test" at the top level says that test_ioctl failed. Before I did the "make test", I did make sure to delete test_ioctl.pyc. ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 00:18 Message: Logged In: YES user_id=91293 I compiled with gcc-3.2.3 (compiled from source) on a RH9 system. The error message from doing "./python ./Lib/test/test_ioctl.py" (after appropriately setting LD_LIBRARY_PATH) was: Traceback (most recent call last): File "Lib/test/test_ioctl.py", line 2, in ? from test_support import TestSkipped, run_unittest File "/opt/src/Python-2.3/Lib/test/test_support.py", line 4, in ? raise ImportError, 'test_support must be imported from the test package' ImportError: test_support must be imported from the test package In the file Lib/test/test_ioctl.py, if I replace: from test_support import TestSkipped, run_unittest with from test.test_support import TestSkipped, run_unittest the test passes as expected. Gotta love error messages. ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 09:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 09:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 08:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 04:21 Message: Logged In: YES user_id=6656 Oh good <wink> Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 11:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 09:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 03:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply at sourceforge.net Sat Aug 14 01:36:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 01:36:45 2004 Subject: [ python-Bugs-1008275 ] os.getstatusoutput on win32 Message-ID: Bugs item #1008275, was opened at 2004-08-13 07:28 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008275&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Chmouel Boudjnah (chmou) Assigned to: Nobody/Anonymous (nobody) Summary: os.getstatusoutput on win32 Initial Comment: Using: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 i cannot run command.getstatusoutput since i guess it expect a unix shell. >>> import commands >>> commands.getstatusoutput("c://usr//bin//echo") (1, "'{' n'est pas reconnu en tant que commande interne\nou externe, un programm e ex\x82cutable ou un fichier de commandes.") i had to bypass it on win32 by using this in my program : def _getstatusoutput(cmd): """Return Win32 (status, output) of executing cmd in a shell.""" pipe = os.popen(cmd, 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text Cheers, Chmouel. http://www.chmouel.com/wp/ ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-14 09:36 Message: Logged In: YES user_id=1038590 The commands module is going to stay Unix-specific. There are too many potential issues with trying to support the various win32 command interpreters. It will eventually be deprecated in favour of a higher level process management API. Hopefully that will happen in the 2.5 timeframe, but we'll have to wait and see. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-13 19:29 Message: Logged In: YES user_id=1038590 Well, the docs for the commands module explicitly state that it is only supported on Unix. While two of the functions it provides (getstatusoutput() and getoutput()) are trivial to provide on Windows, the 3rd (getstatus()) has no equivalent that I can see. I think I'll take this one to py-dev for further consideration ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008275&group_id=5470 From noreply at sourceforge.net Sat Aug 14 01:42:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 01:42:56 2004 Subject: [ python-Bugs-1005248 ] new.code() not cleanly checking its arguments Message-ID: Bugs item #1005248, was opened at 2004-08-07 15:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Michael Hudson (mwh) Summary: new.code() not cleanly checking its arguments Initial Comment: new.code() does not check its arguments properly: >>> new.code(1,1,1,0,"123",(None,),(5,),(5,),"123","321",2,"") Fatal Python error: non-string found in code slot Here the tuple (5,) is used for co_names and co_varnames. More generally it looks like this part of compile.c could do with quite some cleaning up. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-13 18:42 Message: Logged In: YES user_id=80475 For the record, the thought is to leave the optimization code fully decoupled from the rest of the compiler until the AST branch goes in. Also, the optimizer itself needs a bit more evolution in Py2.5 before it gets moved. For the time being, it adds more than it costs and should be left alone. But, ultimately it should be placed at the tail end of compilation, before the pyc files are created. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-13 03:30 Message: Logged In: YES user_id=4771 Raymond said: not worth the burden. The optimizer is "experimental and not fully developed". It is also superfast, so it doesn't matter. The AST branch will change all this anyway. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-12 12:58 Message: Logged In: YES user_id=6656 OK, checked in as Lib/test/test_new.py revision 1.18 Python/compile.c revision 2.314 I also rewrote all the tests of new.code() to use realistic arguments. > On a side note, PyCode_New() calls optimize_code(), but > PyCode_New() is also used when un-marshalling .pyc files. Yes, I noticed that too, and wondered some of the things you wondered. Ask Raymond? I think it's his code. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-12 11:39 Message: Logged In: YES user_id=4771 Sounds reasonable. The patch looks OK. On a side note, PyCode_New() calls optimize_code(), but PyCode_New() is also used when un-marshalling .pyc files. I wonder how much time is lost re-optimizing in vain the code loaded from .pyc files, and I wonder why optimization is not done just as the last step of the compiler instead. While I'm wondering, I also wonder if some user bytecode hacks could be broken by optimize_code(). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 06:23 Message: Logged In: YES user_id=6656 > Why do you check for argcount<0 but not nlocals<0, which > also raises a SystemError? Because I didn't read that far... Obvious extension of patch added. Agree that current behaviour of PyCode_New is a bit crazy. OTOH, not changing PyCode_New itself seems a principle no worse than any other for the moment. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-09 05:54 Message: Logged In: YES user_id=4771 Why do you check for argcount<0 but not nlocals<0, which also raises a SystemError? More to the point, why on earth does PyCode_New() check for negative values of argcount and nlocals and not the other values? A negative stacksize, for example, is likely to crash the interpreter too. On the other hand, validating these numbers more precisely is much more complex, and not something we're trying to do here. So I don't understand why these two values in particular are checked for < 0. We should as well drop the check altogether. My position here is that calling new.code() shouldn't do anything bad to the interpreter; but actually executing the resulting code object is allowed to destroy the sun (provided, of course, that CPython runs in an environment that allows that). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-09 05:40 Message: Logged In: YES user_id=6656 Maybe new is meant to be scary, but current behaviour is going well above and beyond the effort required. new.code can mutate a tuple containing string subclasses into a tuple containing exact strings! Armin, what do you think of the attached? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-08 08:58 Message: Logged In: YES user_id=29957 I thought there was a general concensus that many things in the 'new' module could be used to make a mess, and that trying to fix them all was a pretty much open-ended task? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005248&group_id=5470 From noreply at sourceforge.net Sat Aug 14 05:49:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 05:49:21 2004 Subject: [ python-Bugs-1005325 ] inconsistent acceptance of floats for range() Message-ID: Bugs item #1005325, was opened at 2004-08-08 00:13 Message generated for change (Comment added) made by docwatson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005325&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistent acceptance of floats for range() Initial Comment: ``range(1.0)`` will raise a DeprecationWarning (thanks to PyArg_ParseTuple() warning when a float is passed when an integer is expected), but if you do ``range(1e100)`` it raises a TypeError saying that an "integer end argument expected, got float". Obviously not consistent. ---------------------------------------------------------------------- Comment By: Dave Watson (docwatson) Date: 2004-08-14 03:49 Message: Logged In: YES user_id=1094771 I've looked into it, and 1e100 is of type 'long float' internally, which uses a different range function (handle_range_long) instead of 1.0 which is a normal float, which uses the standard range function (bltin_range). It seems the long version was written after the standard one, and once the deprecation warning (which happens in both versions, but it will only print once per session, restart python to test each) is turned into an error, things will be consistent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005325&group_id=5470 From noreply at sourceforge.net Sat Aug 14 12:59:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 12:59:57 2004 Subject: [ python-Bugs-992078 ] test_format fails 2.4a1 Message-ID: Bugs item #992078, was opened at 2004-07-16 04:17 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992078&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: roadkill (dharma_roadkill) Assigned to: Nobody/Anonymous (nobody) Summary: test_format fails 2.4a1 Initial Comment: uname -a OSF1 pikachu.****.com V5.1 2650 alpha (HP alpha box running Tru64 V5.1B) Python-2.4a1 make test: test test_format produced unexpected output: ****************************************** **************************** *** line 2 of actual output doesn't appear in expected output after line 1: + u'%f' % (1.0,) == u'1,000000' != '1.000000' ****************************************** **************************** no fancy configure options no locale env variables set ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-14 12:59 Message: Logged In: YES user_id=469548 Fixed in rev 1.5 of test__locale__. ---------------------------------------------------------------------- Comment By: Mitchell Surface (msurface) Date: 2004-08-11 23:22 Message: Logged In: YES user_id=21257 I can confirm it's still failing in current CVS. It looks like test__locale.py is not restoring the locale when it it's finished. I've submitted patch #1007539. ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2004-07-16 21:20 Message: Logged In: YES user_id=129426 I can confirm this. It is caused by test__locale that is executed before test_format (and also, test_unicode fails likewise). See: Not only test_format but also test_unicode fail on my Mandrake 10 box. My default locale is nl_NL. Behold: [irmen@atlantis Python-2.4a1]$ cat testcases.in test__locale test_format test_unicode [irmen@atlantis Python-2.4a1]$ ./python Lib/test/regrtest.py -f testcases.in test__locale test_format test test_format produced unexpected output: ********************************************************************** *** line 2 of actual output doesn't appear in expected output after line 1: + u'%f' % (1.0,) == u'1,000000' != '1.000000' ********************************************************************** test_unicode test test_unicode failed -- Traceback (most recent call last): File "/home/irmen/BUILD/Python-2.4a1/Lib/test/test_unicode.py", line 358, in test_formatt ing string_tests.MixinStrUnicodeUserStringTest.test_formatting(self) File "/home/irmen/BUILD/Python-2.4a1/Lib/test/string_tests.py", line 615, in test_formatt ing self.checkequal('0042.00', '%07.2f', '__mod__', 42) File "/home/irmen/BUILD/Python-2.4a1/Lib/test/string_tests.py", line 56, in checkequal realresult AssertionError: u'0042.00' != u'0042,00' 1 test OK. 2 tests failed: test_format test_unicode [irmen@atlantis Python-2.4a1]$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992078&group_id=5470 From noreply at sourceforge.net Sat Aug 14 15:33:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 15:33:15 2004 Subject: [ python-Bugs-851123 ] shutil.copy destroys hard links Message-ID: Bugs item #851123, was opened at 2003-11-29 13:36 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851123&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerald Schlueter (gls62) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy destroys hard links Initial Comment: Hi, I am using python2.3 on a debian linux (unstable) kernel Version 2.4.20. shell: cd /tmp cp /etc/passwd a ln a b cp a b *** a and b are the same file *** python import shutil shutil.copy("a", "b") The file is destroyed and cut down to 0 Bytes! Thank you, Gerry (gls62) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-14 15:33 Message: Logged In: YES user_id=469548 Fixed in rev 1.31 of shutil.py using patch at http://python.org/sf/854853. ---------------------------------------------------------------------- Comment By: Gerald Schlueter (gls62) Date: 2003-12-02 16:28 Message: Logged In: YES user_id=920149 Hi Gregory, your patch works fine on my system. greetings, Gerry ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2003-12-01 18:03 Message: Logged In: YES user_id=11365 The problem is in function shutil.copyfile(). Unlike cp, it does not check whether the two filenames actually link to the same underlying file. If they do, the act of opening the dst file for writing destroys the src file. This is true for symbolic or hard links. cp notices the link and prints a message. A fix for this would be to replace the lines # check for same pathname; all platforms _src = os.path.normcase(os.path.abspath(src)) _dst = os.path.normcase(os.path.abspath(dst)) if _src == _dst: return with # check for same file if hasattr(os.path,'samefile'): # Macintosh, Unix. try: if os.path.samefile(src,dst): return except OSError: pass else: # check for same pathname; all other platforms _src = os.path.normcase(os.path.abspath(src)) _dst = os.path.normcase(os.path.abspath(dst)) if _src == _dst: return This should fix the bug under Unix (and Mac, I guess) and leave other platforms no worse than before (I guess most other platforms do not have hard or symbolic links anyway?) I have posted a patch at http://tane.cfa.harvard.edu/python/shutil.patch Gerry, could you try it out, then perhaps I can open a patch item. I've included some test code. However, it uses tempfile.mktemp which I see has now been deprecated, so it will need a fix for that. Also, I'm not sure that it properly cleans up in the event of a failure. Perhaps this should be fixed too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851123&group_id=5470 From noreply at sourceforge.net Sat Aug 14 15:53:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 15:53:59 2004 Subject: [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-31 00:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-14 14:53 Message: Logged In: YES user_id=6656 Oh, crud. However, if we don't test TIOCGPGRP, what *can* we test? Perhaps we should just test that the call doesn't blow up. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-13 23:57 Message: Logged In: YES user_id=1103758 Folks, I recently completed a build of python-2.3.2 (I realize 2.3.4 is out, but this info should still be relevant) on SPARC/Solaris-9, and as in this bug, the test_ioctl is failing. However, I believe I have found the cause, after running the tests with "-v" added to TESTOPTS in the Makefile. Since I have found no other mention of this particular cause for the failure, perhaps others will find this information helpful. The test is failing because the process group returned from the OS (the getpgrp() system call) does not match the process group associated with /dev/tty (as returned by the TIOCGPGRP ioctl() call). Now it turns out that this is not really an error, because some command shells (ksh, csh, perhaps bash), will assign each new command to a new process group, in order to do job-control (^Z interruption, moving to/from background, etc.). So, at least on this platform, using ksh, the test_ioctl will _always_ fail, since the "make" command gets a process group different from that of the parent shell, and different from /dev/tty's process group (which matches the parent shell). Therefor it would probably be better to test some other ioctl() call than the TIOCGPGRP call, or otherwise rework the test so it doesn't fail under what can be normal circumstances on some platforms. Regards, Marion ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-05 11:48 Message: Logged In: YES user_id=6656 You're supposed to run ./python ./Lib/test/regrtest.py test_ioctl or maybe ./python ./Lib/test/regrtest.py -v test_ioctl ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 08:39 Message: Logged In: YES user_id=91293 Blah. I was too hasty: while "./python ./Lib/test/test_ioctl.py" passed after making the modification I mentioned, a re-run of "make test" at the top level says that test_ioctl failed. Before I did the "make test", I did make sure to delete test_ioctl.pyc. ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 08:18 Message: Logged In: YES user_id=91293 I compiled with gcc-3.2.3 (compiled from source) on a RH9 system. The error message from doing "./python ./Lib/test/test_ioctl.py" (after appropriately setting LD_LIBRARY_PATH) was: Traceback (most recent call last): File "Lib/test/test_ioctl.py", line 2, in ? from test_support import TestSkipped, run_unittest File "/opt/src/Python-2.3/Lib/test/test_support.py", line 4, in ? raise ImportError, 'test_support must be imported from the test package' ImportError: test_support must be imported from the test package In the file Lib/test/test_ioctl.py, if I replace: from test_support import TestSkipped, run_unittest with from test.test_support import TestSkipped, run_unittest the test passes as expected. Gotta love error messages. ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 17:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 17:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 16:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 12:21 Message: Logged In: YES user_id=6656 Oh good <wink> Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 19:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 17:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 11:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply at sourceforge.net Sat Aug 14 16:05:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 16:05:41 2004 Subject: [ python-Bugs-851123 ] shutil.copy destroys hard links Message-ID: Bugs item #851123, was opened at 2003-11-29 13:36 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851123&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Gerald Schlueter (gls62) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: shutil.copy destroys hard links Initial Comment: Hi, I am using python2.3 on a debian linux (unstable) kernel Version 2.4.20. shell: cd /tmp cp /etc/passwd a ln a b cp a b *** a and b are the same file *** python import shutil shutil.copy("a", "b") The file is destroyed and cut down to 0 Bytes! Thank you, Gerry (gls62) ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-14 15:33 Message: Logged In: YES user_id=469548 Fixed in rev 1.31 of shutil.py using patch at http://python.org/sf/854853. ---------------------------------------------------------------------- Comment By: Gerald Schlueter (gls62) Date: 2003-12-02 16:28 Message: Logged In: YES user_id=920149 Hi Gregory, your patch works fine on my system. greetings, Gerry ---------------------------------------------------------------------- Comment By: Gregory H. Ball (greg_ball) Date: 2003-12-01 18:03 Message: Logged In: YES user_id=11365 The problem is in function shutil.copyfile(). Unlike cp, it does not check whether the two filenames actually link to the same underlying file. If they do, the act of opening the dst file for writing destroys the src file. This is true for symbolic or hard links. cp notices the link and prints a message. A fix for this would be to replace the lines # check for same pathname; all platforms _src = os.path.normcase(os.path.abspath(src)) _dst = os.path.normcase(os.path.abspath(dst)) if _src == _dst: return with # check for same file if hasattr(os.path,'samefile'): # Macintosh, Unix. try: if os.path.samefile(src,dst): return except OSError: pass else: # check for same pathname; all other platforms _src = os.path.normcase(os.path.abspath(src)) _dst = os.path.normcase(os.path.abspath(dst)) if _src == _dst: return This should fix the bug under Unix (and Mac, I guess) and leave other platforms no worse than before (I guess most other platforms do not have hard or symbolic links anyway?) I have posted a patch at http://tane.cfa.harvard.edu/python/shutil.patch Gerry, could you try it out, then perhaps I can open a patch item. I've included some test code. However, it uses tempfile.mktemp which I see has now been deprecated, so it will need a fix for that. Also, I'm not sure that it properly cleans up in the event of a failure. Perhaps this should be fixed too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851123&group_id=5470 From noreply at sourceforge.net Sat Aug 14 17:04:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 17:04:34 2004 Subject: [ python-Bugs-990669 ] os.path.realpath() does not handle symlinks correctly Message-ID: Bugs item #990669, was opened at 2004-07-14 06:58 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990669&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anton Koinov (dave0000) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: os.path.realpath() does not handle symlinks correctly Initial Comment: os.path.realpath() does not handle symlinks properly on Linux (at least, does not do it the same way as the Linux file functions do). To reproduce follow these steps: mkdir a mkdir a/k mkdir a/l mkdir a/k/x mkdir a/k/y cd a ln -s k/y link-y ls link-y/.. This outputs: x/ y/ In other words, link-y/.. == a/k Now, while still in directory 'a' (in bash) execute on one line: python -c 'import os.path'$'\n''print os.path.realpath("link-y/..")' This will print: /path/to/a In other words: os.path.realpath('link-y/..') == a That is, the link link-y has not been expanded to the directory it points to before .. (go to parent directory) has been applied to the path. os.path.normpath() has the same problem. This may be a potential security risk if one uses realpath to check if a requested path is inside a certain restricted subdirectory. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-14 17:04 Message: Logged In: YES user_id=469548 The patches below have been checked in. Closing as fixed. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-07-23 17:45 Message: Logged In: YES user_id=469548 I've created a patch for realpath (http://python.org/sf/996627) and a doc patch for normpath (http://python.org/sf/996626). There's a comment in posixpath.py warning for this problem with normpath, and it's been there since 1992, so I don't think we should go around changing it now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=990669&group_id=5470 From noreply at sourceforge.net Sat Aug 14 17:20:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 17:20:09 2004 Subject: [ python-Bugs-989672 ] misinforming help messages in pdb.py Message-ID: Bugs item #989672, was opened at 2004-07-12 21:21 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989672&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Simon Percivall (percivall) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: misinforming help messages in pdb.py Initial Comment: The help messages the help_d and help_u methods of the pdb.Pdb class gives have been switched. The standard library documentation gets it right. This is what it says: pdb.Pdb.help_d: Move the current frame one level down in the stack trace (to an older frame). pdb.Pdb.help_u: Move the current frame one level up in the stack trace (to a newer frame). ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-14 17:20 Message: Logged In: YES user_id=469548 pdb.doc also had it switched around. Correction checked in as rev 1.68 of pdb.py and rev 1.9 of pdb.doc. Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=989672&group_id=5470 From noreply at sourceforge.net Sat Aug 14 20:19:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 20:19:13 2004 Subject: [ python-Bugs-1009263 ] non-ascii readline input crashes python Message-ID: Bugs item #1009263, was opened at 2004-08-14 18:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: non-ascii readline input crashes python Initial Comment: Start Python 2.3.4 on Linux command line: $ python Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Enter the string "2?3" (2 times 3, the symbol between 2 and 3 is a multiplication sign, I think Unicode c397 or maybe 97c3 if I have it byte swapped) and hit return. Python reports a syntax error. Hit Ctrl-P to edit the line with readline. Use ctrl-D to delete the first character of the input line, and Python instantly crashes with a seg fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 From noreply at sourceforge.net Sat Aug 14 21:58:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 21:58:40 2004 Subject: [ python-Bugs-1000914 ] Carbon.CF.CFMutableArray hangs interpreter Message-ID: Bugs item #1000914, was opened at 2004-07-30 22:18 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.CF.CFMutableArray hangs interpreter Initial Comment: $ /opt/python2.4/bin/python Python 2.4a1+ (#1, Jul 30 2004, 20:22:17) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from Carbon.CF import * >>> c = CFArrayCreateMutable(0) >>> isinstance(c, CFMutableArrayRef) True >>> del c The interpreter hangs after deleting c. This also happens when the call to isinstance is left out. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2004-08-14 21:58 Message: Logged In: YES user_id=45365 Ronald, I think I fixed this in CVS just before my holidays. Could you please check? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 18:14 Message: Logged In: YES user_id=580910 It's infinite recursion... - CF.CFMutableArrayRef has is a subtype of CF.CFArrayRef - Both tp_del's call 'self->ob_type->tp_base->tp_dealloc' to deallocate the instance. - When the instance is an CFMutableArrayRef self->ob_type->tp_base is CFArrayRef, which means we get: 1. Object refcount is 0, call tp_dealloc 2. Enter CFMutableArrayRefObj_dealloc 3. Call self->ob_type->tp_dealloc 4. Enter CFArrayRefObj_dealloc 5. Call self->ob_type->tp_dealloc 6. Enter CFArrayRefObj_dealloc 7. ... I guess the right change is in Tools/bgen/bgen/bgenObjectDefinition.py: outputDealloc. Near line 138 this prints the problematic 'self->ob_type->tp_base- >tp_dealloc'. I'd change this to: Output("%s.tp_dealloc((PyObject*)self);"%(self.basetype,)) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-07-30 22:27 Message: Logged In: YES user_id=580910 when I use gdb to check where the program hangs I always end up in CFArrayRefObj_dealloc. This also happens when I continue to program and break again later on. It doesn't seem to be infinite recursion, the stack is 8 levels deep with the code mentioned earlier. However: (gdb) where #0 0x00551f98 in CFArrayRefObj_dealloc (self=0x37f0e0) at /Volumes/ Data/Users/ronald/Software/python-HEAD/dist/src/Mac/Modules/cf/ _CFmodule.c:525 #1 0x0008879c in PyEval_EvalFrame (f=0x60d820) at Python/ceval.c: 1662 #2 0x0008a4bc in PyEval_EvalCodeEx (co=0x2, globals=0x59e54, locals=0x552308, args=0x16c, argcount=6312944, kws=0x874a0, kwcount=1, defs=0x60d96c, defcount=0, closure=0x0) at Python/ ceval.c:2697 #3 0x0008d648 in PyEval_EvalCode (co=0x37f0e0, globals=0x59e54, locals=0x55e1d4) at Python/ceval.c:448 #4 0x0000c9a0 in run_node (n=0x16c, filename=0x59e54 "\201^", globals=0x2, locals=0x60d96c, flags=0x0) at Python/pythonrun.c:1255 #5 0x0000c128 in PyRun_SimpleFileExFlags (fp=0xa0009818, filename=0xbffffc9e "t.py", closeit=6346784, flags=0x377a92) at Python/ pythonrun.c:850 #6 0x00006328 in Py_Main (argc=3533392, argv=0xbffffc9e) at Modules/main.c:413 #7 0x00001ee4 in _start (argc=3533392, argv=0xa0009818, envp=0xbffffc9e) at /SourceCache/Csu/Csu-46/crt.c:267 #8 0x00001d58 in start () (gdb) p self $3 = (CFArrayRefObject *) 0x37f0e0 (gdb) p *self $4 = { ob_refcnt = 0, ob_type = 0x55e2e4, ob_itself = 0x0, ob_freeit = 0x90190b98 } (gdb) p self->ob_type->tp_base $5 = (struct _typeobject *) 0x55e1d4 (gdb) p self->ob_type->tp_base->tp_dealloc $6 = 0x551f48 (gdb) And CFArrayRefObj_dealloc is: static void CFArrayRefObj_dealloc(CFArrayRefObject *self) { if (self->ob_freeit && self->ob_itself) { self->ob_freeit((CFTypeRef)self->ob_itself); self->ob_itself = NULL; } self->ob_type->tp_base->tp_dealloc((PyObject *)self); } BTW: Python 2.4a1+ from anon-CVS as of today, running on OSX 10.3.4 with Xcode 1.2 (gcc 3.3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470 From noreply at sourceforge.net Sat Aug 14 22:03:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 22:03:38 2004 Subject: [ python-Bugs-1004810 ] Carbon.File fails if server vol is mounted after launch Message-ID: Bugs item #1004810, was opened at 2004-08-06 20:51 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004810&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Pharr (pharr) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.File fails if server vol is mounted after launch Initial Comment: On MacOs X 10.3.x (with the stock Python 2.3). Carbon.File.FSSpec(theFile) will fail with a -120 (Directory Not Found) error if theFile is on a server volume which was mounted after the script was launched. In actuality, it may be a little more complex, because if there is only a single server volume mounted, then Carbon.File sometimes will not fail until the volume is mounted, unmounted, and remounted a few times. Mounting two or more volumes causes the situation to become more consistently reproducible. What is going on is that each application's instance of the Carbon File Manager depends on being notified by the MacOS X operating system when volumes are mounted and unmounted through the application's runloop. Since python scripts do not implement a runloop, the running python process' carbon file manager never gets a chance to see these notifications and consequently it's internal data structures describing the state of the mounted volumes become out of date if volumes are mounted or unmounted repeatedly from other processes. This causes most Carbon.File calls to fail when manipulating files on a server volume if that volume is mounted while the script is running. My situation is an automated build script which wants to continue running while mounting and unmounting server volumes onto which to copy the resulting build products. After the first two builds (and mounting and unmounting two AFP volumes twice), all Carbon.File calls subsequently will fail until the python script is relaunched. It seems like there would be a way to get Carbon.File to be able to look a little harder for these volumes, but I haven't found a good workaround other than to call a sub-script for any operation which requires Carbon.File. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2004-08-14 22:03 Message: Logged In: YES user_id=45365 Paul, I've always known that there were potential problems with some of the FSSpec calls when you have no runloop, but you're the first one (in about 10 years:-) to actually give the impression you understand what goes on. While I don't think I can fix this in Python itself (adding a runloop is hardly an option) I could document what a user would have to do, and/or provide a helper method that would execute that code or something, but I would first need to know what it is you actually have to do in the runloop. Do you happen to know this? And/or do you have references to the specific sections of Apple documentation where this is described? BTW: does the problem alson happen if you go from filename to FSRef to FSSpec? And at which stage (fsr=FSRef(filename) or fss=FSSpec(fsr))? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004810&group_id=5470 From noreply at sourceforge.net Sat Aug 14 23:10:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 14 23:10:20 2004 Subject: [ python-Bugs-1009263 ] non-ascii readline input crashes python Message-ID: Bugs item #1009263, was opened at 2004-08-15 03:19 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: non-ascii readline input crashes python Initial Comment: Start Python 2.3.4 on Linux command line: $ python Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Enter the string "2?3" (2 times 3, the symbol between 2 and 3 is a multiplication sign, I think Unicode c397 or maybe 97c3 if I have it byte swapped) and hit return. Python reports a syntax error. Hit Ctrl-P to edit the line with readline. Use ctrl-D to delete the first character of the input line, and Python instantly crashes with a seg fault. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-15 06:10 Message: Logged In: YES user_id=55188 What locale do you use? I couldn't reproduce the problem on any of utf-8, iso8859-1, C, euc-kr locale. And, can you please attach a backtrace for the segfault point? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 From noreply at sourceforge.net Sun Aug 15 01:53:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 15 01:53:36 2004 Subject: [ python-Bugs-952953 ] execve rejects empty argument list Message-ID: Bugs item #952953, was opened at 2004-05-13 00:54 Message generated for change (Comment added) made by docwatson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=952953&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: newsham (newsham) Assigned to: Nobody/Anonymous (nobody) Summary: execve rejects empty argument list Initial Comment: The exec* family of calls in the os package does not allow an empty list of arguments to be passed in. Passing is an empty list (ie. allow argv[0] to be NULL and argc to be zero) is rarely desired, but perfectly legal. Verify by: import os os.execve("/bin/ls", [], {}) Tim N. ---------------------------------------------------------------------- Comment By: Dave Watson (docwatson) Date: 2004-08-14 23:53 Message: Logged In: YES user_id=1094771 a patch has been submitted (# 1009075) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:48 Message: Logged In: YES user_id=6656 I think you'll need to supply a patch to have any hope of this changing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=952953&group_id=5470 From noreply at sourceforge.net Sun Aug 15 01:58:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 15 01:58:27 2004 Subject: [ python-Bugs-1005936 ] Index entries with "_" are wrong in pdf file Message-ID: Bugs item #1005936, was opened at 2004-08-09 12:41 Message generated for change (Comment added) made by docwatson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005936&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: Index entries with "_" are wrong in pdf file Initial Comment: "make pdf". Open lib.pdf in acrobat reader, or another pdf viewer with the "bookmarks" feature. Open the "Python Language Services" item. Section 18.8 (in CVS) will read "pyprotect unhbox voidb@x kern 0.6emvbox {hrule width.55em}compile --- Compile Python source files" It should read simply "py_compile --- Compile Python source files"---If you visit that section, that's the title shown. I only know enough LaTeX to get myself hurt, but it looks like "_" was converted into a special sequence, and the step that produces the index used the expanded version. It's a fix that would feel icky, but if this sequence "protect ....55em}" was the same everywhere, simply replacing that string with "_" when generating the index would probably get the right results. I first noticed this problem in dist.pdf where many of the module names contained underscores. ---------------------------------------------------------------------- Comment By: Dave Watson (docwatson) Date: 2004-08-14 23:58 Message: Logged In: YES user_id=1094771 a patch has been submitted for this bug (#1009373) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-09 12:45 Message: Logged In: YES user_id=2772 This also affects older versions of the documentation, for instance the entries for __builtin__, __main__ and __future__ in Python-letter-2.3.4.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005936&group_id=5470 From noreply at sourceforge.net Sun Aug 15 03:55:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 15 03:55:08 2004 Subject: [ python-Bugs-1009263 ] non-ascii readline input crashes python Message-ID: Bugs item #1009263, was opened at 2004-08-14 18:19 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: non-ascii readline input crashes python Initial Comment: Start Python 2.3.4 on Linux command line: $ python Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Enter the string "2?3" (2 times 3, the symbol between 2 and 3 is a multiplication sign, I think Unicode c397 or maybe 97c3 if I have it byte swapped) and hit return. Python reports a syntax error. Hit Ctrl-P to edit the line with readline. Use ctrl-D to delete the first character of the input line, and Python instantly crashes with a seg fault. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2004-08-15 01:55 Message: Logged In: YES user_id=72053 Backtrace follows. I don't know how to tell my locale. My LOCALE shell variable is not set to anything--is there something else I need to check? Since the "2?3" displays properly in my terminal window, I think I'm likely using UTF-8. (gdb) r Starting program: /usr/local/bin/python [New Thread 1074951328 (LWP 6561)] Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 2?3 File "", line 1 2?3 ^ SyntaxError: invalid syntax >>> 2?3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1074951328 (LWP 6561)] 0x401eb687 in _rl_get_char_len () from /usr/lib/libreadline.so.4 (gdb) bt #0 0x401eb687 in _rl_get_char_len () from /usr/lib/libreadline.so.4 #1 0x401eb701 in _rl_compare_chars () from /usr/lib/libreadline.so.4 #2 0x401e0030 in rl_redisplay () from /usr/lib/libreadline.so.4 #3 0x401de816 in rl_redisplay () from /usr/lib/libreadline.so.4 #4 0x401d2588 in readline_internal_char () from /usr/lib/libreadline.so.4 #5 0x401d2695 in readline_internal_char () from /usr/lib/libreadline.so.4 #6 0x401d26ce in readline_internal_char () from /usr/lib/libreadline.so.4 #7 0x401d219f in readline () from /usr/lib/libreadline.so.4 #8 0x40019074 in call_readline (sys_stdin=0x4212fcc0, sys_stdout=0x4212fe20, prompt=0x40177254 ">>> ") at /home/phr/python/Python-2.3.4/Modules/readline.c:679 #9 0x080e6110 in PyOS_Readline (sys_stdin=0x4212fcc0, sys_stdout=0x4212fe20, prompt=0x40177254 ">>> ") at Parser/myreadline.c:183 #10 0x08056c47 in tok_nextc (tok=0x817f428) at Parser/tokenizer.c:683 #11 0x08055d8f in tok_get (tok=0x817f428, p_start=0xbfffecc4, p_end=0xbfffecc8) at Parser/tokenizer.c:1014 #12 0x080559de in PyTokenizer_Get (tok=0x817f428, p_start=0xbfffecc4, p_end=0xbfffecc8) at Parser/tokenizer.c:1414 #13 0x0805543a in parsetok (tok=0x817f428, g=0x8126b88, start=256, err_ret=0xbfffed10, flags=0) at Parser/parsetok.c:125 #14 0x080cb0e2 in PyRun_InteractiveOneFlags (fp=0x4212fcc0, filename=0x80f004a "", flags=0xbfffedf8) at Python/pythonrun.c:738 #15 0x080caf3b in PyRun_InteractiveLoopFlags (fp=0x4212fcc0, filename=0x80f004a "", flags=0xbfffedf8) at Python/pythonrun.c:690 #16 0x080cc2ee in PyRun_AnyFileExFlags (fp=0x4212fcc0, filename=0x80f004a "", closeit=0, flags=0xbfffedf8) at Python/pythonrun.c:653 #17 0x08054d32 in Py_Main (argc=0, argv=0xbfffee74) at Modules/main.c:415 #18 0x080548ab in main (argc=1, argv=0xbfffee74) at Modules/python.c:23 #19 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-14 21:10 Message: Logged In: YES user_id=55188 What locale do you use? I couldn't reproduce the problem on any of utf-8, iso8859-1, C, euc-kr locale. And, can you please attach a backtrace for the segfault point? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 From noreply at sourceforge.net Sun Aug 15 14:47:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 15 14:47:45 2004 Subject: [ python-Bugs-1000914 ] Carbon.CF.CFMutableArray hangs interpreter Message-ID: Bugs item #1000914, was opened at 2004-07-30 22:18 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470 Category: Macintosh Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.CF.CFMutableArray hangs interpreter Initial Comment: $ /opt/python2.4/bin/python Python 2.4a1+ (#1, Jul 30 2004, 20:22:17) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from Carbon.CF import * >>> c = CFArrayCreateMutable(0) >>> isinstance(c, CFMutableArrayRef) True >>> del c The interpreter hangs after deleting c. This also happens when the call to isinstance is left out. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-15 14:47 Message: Logged In: YES user_id=580910 Yup, the issue is no longer there. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-08-14 21:58 Message: Logged In: YES user_id=45365 Ronald, I think I fixed this in CVS just before my holidays. Could you please check? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 18:14 Message: Logged In: YES user_id=580910 It's infinite recursion... - CF.CFMutableArrayRef has is a subtype of CF.CFArrayRef - Both tp_del's call 'self->ob_type->tp_base->tp_dealloc' to deallocate the instance. - When the instance is an CFMutableArrayRef self->ob_type->tp_base is CFArrayRef, which means we get: 1. Object refcount is 0, call tp_dealloc 2. Enter CFMutableArrayRefObj_dealloc 3. Call self->ob_type->tp_dealloc 4. Enter CFArrayRefObj_dealloc 5. Call self->ob_type->tp_dealloc 6. Enter CFArrayRefObj_dealloc 7. ... I guess the right change is in Tools/bgen/bgen/bgenObjectDefinition.py: outputDealloc. Near line 138 this prints the problematic 'self->ob_type->tp_base- >tp_dealloc'. I'd change this to: Output("%s.tp_dealloc((PyObject*)self);"%(self.basetype,)) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-07-30 22:27 Message: Logged In: YES user_id=580910 when I use gdb to check where the program hangs I always end up in CFArrayRefObj_dealloc. This also happens when I continue to program and break again later on. It doesn't seem to be infinite recursion, the stack is 8 levels deep with the code mentioned earlier. However: (gdb) where #0 0x00551f98 in CFArrayRefObj_dealloc (self=0x37f0e0) at /Volumes/ Data/Users/ronald/Software/python-HEAD/dist/src/Mac/Modules/cf/ _CFmodule.c:525 #1 0x0008879c in PyEval_EvalFrame (f=0x60d820) at Python/ceval.c: 1662 #2 0x0008a4bc in PyEval_EvalCodeEx (co=0x2, globals=0x59e54, locals=0x552308, args=0x16c, argcount=6312944, kws=0x874a0, kwcount=1, defs=0x60d96c, defcount=0, closure=0x0) at Python/ ceval.c:2697 #3 0x0008d648 in PyEval_EvalCode (co=0x37f0e0, globals=0x59e54, locals=0x55e1d4) at Python/ceval.c:448 #4 0x0000c9a0 in run_node (n=0x16c, filename=0x59e54 "\201^", globals=0x2, locals=0x60d96c, flags=0x0) at Python/pythonrun.c:1255 #5 0x0000c128 in PyRun_SimpleFileExFlags (fp=0xa0009818, filename=0xbffffc9e "t.py", closeit=6346784, flags=0x377a92) at Python/ pythonrun.c:850 #6 0x00006328 in Py_Main (argc=3533392, argv=0xbffffc9e) at Modules/main.c:413 #7 0x00001ee4 in _start (argc=3533392, argv=0xa0009818, envp=0xbffffc9e) at /SourceCache/Csu/Csu-46/crt.c:267 #8 0x00001d58 in start () (gdb) p self $3 = (CFArrayRefObject *) 0x37f0e0 (gdb) p *self $4 = { ob_refcnt = 0, ob_type = 0x55e2e4, ob_itself = 0x0, ob_freeit = 0x90190b98 } (gdb) p self->ob_type->tp_base $5 = (struct _typeobject *) 0x55e1d4 (gdb) p self->ob_type->tp_base->tp_dealloc $6 = 0x551f48 (gdb) And CFArrayRefObj_dealloc is: static void CFArrayRefObj_dealloc(CFArrayRefObject *self) { if (self->ob_freeit && self->ob_itself) { self->ob_freeit((CFTypeRef)self->ob_itself); self->ob_itself = NULL; } self->ob_type->tp_base->tp_dealloc((PyObject *)self); } BTW: Python 2.4a1+ from anon-CVS as of today, running on OSX 10.3.4 with Xcode 1.2 (gcc 3.3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470 From noreply at sourceforge.net Sun Aug 15 14:57:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 15 14:57:17 2004 Subject: [ python-Bugs-769569 ] weird/buggy inspect.getsource behavious Message-ID: Bugs item #769569, was opened at 2003-07-11 12:42 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien de Menten (sdementen) Assigned to: Nobody/Anonymous (nobody) Summary: weird/buggy inspect.getsource behavious Initial Comment: Using python 2.2.2 on a mandrake 9.1 with the inspect.py of python 2.2.3 (correction for lambda keyword), I run the following code """ import inspect a = [ None, lambda x: x>1 and x<0, None] print "Ok",inspect.getsource(a[1]) if 1: a = [ None, lambda x: x>1 and x<0, None] print "Ko",inspect.getsource(a[1]) """ Two weird behaviours occurs 1. The line "print "Ok",inspect.getsource(a[1])" prints Ok lambda x: x>1 and x<0, None] It prints a superfluous line. 2. The line "print "Ko",inspect.getsource(a[1])" raises an exception Ko Traceback (most recent call last): File "bug-inspect.py", line 13, in ? print "Ko",inspect.getsource(a[1]) File "/usr/lib/python2.2/inspect.py", line 523, in getsource lines, lnum = getsourcelines(object) File "/usr/lib/python2.2/inspect.py", line 515, in getsourcelines else: return getblock(lines[lnum:]), lnum + 1 File "/usr/lib/python2.2/inspect.py", line 498, in getblock tokenize.tokenize(ListReader(lines).readline, BlockFinder().tokeneater) File "/usr/lib/python2.2/tokenize.py", line 138, in tokenize tokenize_loop(readline, tokeneater) File "/usr/lib/python2.2/tokenize.py", line 144, in tokenize_loop for token_info in generate_tokens(readline): File "/usr/lib/python2.2/tokenize.py", line 218, in generate_tokens raise TokenError, ("EOF in multi-line statement", (lnum, 0)) tokenize.TokenError: ('EOF in multi-line statement', (7, 0)) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-15 14:57 Message: Logged In: YES user_id=469548 I can't reproduce problem 2 on today's CVS, but http://python.org/sf/1006219 fixes problem 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 From noreply at sourceforge.net Sun Aug 15 15:14:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 15 15:14:49 2004 Subject: [ python-Bugs-1008275 ] os.getstatusoutput on win32 Message-ID: Bugs item #1008275, was opened at 2004-08-12 23:28 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008275&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Chmouel Boudjnah (chmou) Assigned to: Nobody/Anonymous (nobody) Summary: os.getstatusoutput on win32 Initial Comment: Using: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 i cannot run command.getstatusoutput since i guess it expect a unix shell. >>> import commands >>> commands.getstatusoutput("c://usr//bin//echo") (1, "'{' n'est pas reconnu en tant que commande interne\nou externe, un programm e ex\x82cutable ou un fichier de commandes.") i had to bypass it on win32 by using this in my program : def _getstatusoutput(cmd): """Return Win32 (status, output) of executing cmd in a shell.""" pipe = os.popen(cmd, 'r') text = pipe.read() sts = pipe.close() if sts is None: sts = 0 if text[-1:] == '\n': text = text[:-1] return sts, text Cheers, Chmouel. http://www.chmouel.com/wp/ ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-15 15:14 Message: Logged In: YES user_id=469548 Closing. Nick: I borrowed your text for the various other bugs/patches that ask for this (713428, 889949, 660505). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-14 01:36 Message: Logged In: YES user_id=1038590 The commands module is going to stay Unix-specific. There are too many potential issues with trying to support the various win32 command interpreters. It will eventually be deprecated in favour of a higher level process management API. Hopefully that will happen in the 2.5 timeframe, but we'll have to wait and see. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-13 11:29 Message: Logged In: YES user_id=1038590 Well, the docs for the commands module explicitly state that it is only supported on Unix. While two of the functions it provides (getstatusoutput() and getoutput()) are trivial to provide on Windows, the 3rd (getstatus()) has no equivalent that I can see. I think I'll take this one to py-dev for further consideration ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008275&group_id=5470 From noreply at sourceforge.net Sun Aug 15 19:17:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 15 19:17:34 2004 Subject: [ python-Bugs-891637 ] pydoc crashes on a class property Message-ID: Bugs item #891637, was opened at 2004-02-06 09:44 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891637&group_id=5470 Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc crashes on a class property Initial Comment: [forwarded from http://bugs.debian.org/231202] --- class foo(object): __slots__ = ['_bar'] bar = property(lambda (self): self._bar) def __init__(self, bar): self._bar = bar f = foo(1) assert(f.bar == 1) --- removing the parenthesis around the lambda's parameter avoids the pydoc crash. Python itself doesn't seem to care about the parenthesis. $ python tmp.py # no errors $ pydoc tmp Traceback (most recent call last): File "/usr/bin/pydoc", line 4, in ? pydoc.cli() File "/usr/lib/python2.3/pydoc.py", line 2123, in cli help.help(arg) File "/usr/lib/python2.3/pydoc.py", line 1582, in help elif request: doc(request, 'Help on %s:') File "/usr/lib/python2.3/pydoc.py", line 1375, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/usr/lib/python2.3/pydoc.py", line 283, in document if inspect.ismodule(object): return self.docmodule(*args) File "/usr/lib/python2.3/pydoc.py", line 990, in docmodule contents.append(self.document(value, key, name)) File "/usr/lib/python2.3/pydoc.py", line 284, in document if inspect.isclass(object): return self.docclass(*args) File "/usr/lib/python2.3/pydoc.py", line 1135, in docclass lambda t: t[1] == 'property') File "/usr/lib/python2.3/pydoc.py", line 1087, in spillproperties base = self.document(func, tag, mod) File "/usr/lib/python2.3/pydoc.py", line 285, in document if inspect.isroutine(object): return self.docroutine(*args) File "/usr/lib/python2.3/pydoc.py", line 1177, in docroutine args, varargs, varkw, defaults = inspect.getargspec(object) File "/usr/lib/python2.3/inspect.py", line 656, in getargspec args, varargs, varkw = getargs(func.func_code) File "/usr/lib/python2.3/inspect.py", line 624, in getargs remain[-1] = remain[-1] - 1 IndexError: list index out of range ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2004-08-15 19:17 Message: Logged In: YES user_id=60903 Fixed in - Lib/inspect.py 1.53 and 1.47.8.2 - Lib/test/test_inspect.py 1.15 and 1.12.8.3 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-08 13:31 Message: Logged In: YES user_id=469548 This crashes as well: def foo((bar)): return 1 A patch is available at http://python.org/sf/1005466. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-08 12:23 Message: Logged In: YES user_id=469548 First, note that the problem doesn't lie in properties. This crashes as well: foo = lambda (bar): 1 second, Python does care about the parentheses. It just doesn't matter when the lambda has only one argument. Using parentheses creates a sublist instead of a parameter list, as in the following example with normal functions: def foo((bar, baz)): return bar assert(foo((1, 2)) == 1) pydoc (or rather, inspect) should still be fixed though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891637&group_id=5470 From noreply at sourceforge.net Mon Aug 16 02:20:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 02:20:27 2004 Subject: [ python-Bugs-1009729 ] Cannot doctest a SyntaxError Message-ID: Bugs item #1009729, was opened at 2004-08-15 19:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009729&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Edward Loper (edloper) Summary: Cannot doctest a SyntaxError Initial Comment: Currently, doctests cannot be used to demonstrate or test that misconstructions produce a syntax error. I'm not certain, but I believe that case is trappable and veriable. The following is an actual use case for one of the tests I would like to have in test.test_genexps.py: Verify that parenthesis are required in a statement >>> def f(n): ... return i*i for i in xrange(n) ... SyntaxError: invalid syntax ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009729&group_id=5470 From noreply at sourceforge.net Mon Aug 16 02:33:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 02:34:02 2004 Subject: [ python-Bugs-1009729 ] Cannot doctest a SyntaxError Message-ID: Bugs item #1009729, was opened at 2004-08-15 20:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009729&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Edward Loper (edloper) Summary: Cannot doctest a SyntaxError Initial Comment: Currently, doctests cannot be used to demonstrate or test that misconstructions produce a syntax error. I'm not certain, but I believe that case is trappable and veriable. The following is an actual use case for one of the tests I would like to have in test.test_genexps.py: Verify that parenthesis are required in a statement >>> def f(n): ... return i*i for i in xrange(n) ... SyntaxError: invalid syntax ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-15 20:33 Message: Logged In: YES user_id=31435 doctest has always been able to handle SyntaxError; e.g., see test_generators.py. You need a "Traceback:" line too. This is explained in detail in the current (CVS) doctest LaTeX docs. For example, this spelling works fine as a doctest: """ >>> def f(n): ... return i*i for i in xrange(n) Traceback (most recent call last): ... SyntaxError: invalid syntax """ You can take out the ellipsis between Traceback and SyntaxError if you like. You can also keep your "extra" sys.PS2 line if you like. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009729&group_id=5470 From noreply at sourceforge.net Mon Aug 16 06:28:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 06:29:06 2004 Subject: [ python-Bugs-1009803 ] xmlrpclib, PEP291, "yield" Message-ID: Bugs item #1009803, was opened at 2004-08-16 14:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib, PEP291, "yield" Initial Comment: PEP 291 says that xmlrpclib should be 1.5.2 compatible. This patch: revision 1.31 date: 2003/10/31 13:49:36; author: loewis; state: Exp; lines: +66 -2 Patch #531629: Add multicall support. however, introduced code with the 'yield' keyword. This is completely and utterly non-1.5.2 compatible. Either the PEP (and the comment in the file) should be updated, or the code should be rewritten to not use yield. Martin? You checked in the patch, what's your opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 From noreply at sourceforge.net Mon Aug 16 09:04:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 09:04:59 2004 Subject: [ python-Bugs-738154 ] pdb doesn't find some source files Message-ID: Bugs item #738154, was opened at 2003-05-15 13:53 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738154&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: pdb doesn't find some source files Initial Comment: In python 2.2.2 code object attribute co_filename contains relative to sys.path path (in python 2.3 the path is absolute), so pdb doesn't find some source files (for example, in the site-packages directory). The attached patch extends functionality of the bdb.Bdb.canonic method up to searching source files in sys.path. ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2004-08-16 11:04 Message: Logged In: YES user_id=388573 Now I can't remember the problem too, since I don't use python2.2 more than a year. I suggest close this bug as "not bug". ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 18:15 Message: Logged In: YES user_id=469548 I'm not sure I understand the problem. I can do the following just fine (on 2.2, 2.3 and 2.4 CVS): (Pdb) b bikeemacs.py:32 Breakpoint 1 at /usr/lib/python2.3/site-packages/bikeemacs.py:32 Could you clarify? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738154&group_id=5470 From noreply at sourceforge.net Mon Aug 16 11:24:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 11:25:00 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 11:41 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-08-16 12:24 Message: Logged In: YES user_id=358087 It hangs even if I don't do anything and even without screen saver. Seems to be a problem in Tk since if I run both win32 IDLE and cygwin IDLE both hang. If I run only cygwin IDLE it's OK. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-11 04:55 Message: Logged In: YES user_id=149084 If you just start IDLE (shell window only) and don't do anything, does it always hang in two hours? If so, /please/ try this without your screen saver. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-08 10:58 Message: Logged In: YES user_id=358087 Hangs means the window content does not refresh. I can move it, resize it ... It is killable and task manager show it as "active". ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 23:17 Message: Logged In: YES user_id=593130 By 'hangs' do you mean when viewing the TasKManager Applications list, and killable with its End Task button? or something more evil, like locks the computer and prevents rebooting? Even Outlook Express and Internet Explore, with MS's billions, still do the former. With Win95, 98, and XP home and pro, I have had several problems, often intermittent, and maybe hardware specific, with bad interactions between programs, screen savers, and stand-by. On LCDs (and, I believe, modern CRTs) 'screen savers' save nothing except the boredom of a constant picture. I would turn it off and also check screen properites/screensaver/power button and the bios to see if anything is scheduled to happen at 2 hours. The timing, if consistent, is definitely suspicious. A major change for Windows between 2.3.4 and 2.4 is the compiler 'upgrade' which could change a program's interaction with Windows and its vulnerability to bugs within. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 11:11 Message: Logged In: YES user_id=358087 1. "Pure" Python (without IDLE) don't hang after 2 hours 2. I didn't try this time but I'm pretty sure it hanged without screen saver as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-04 04:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 12:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 11:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Mon Aug 16 14:29:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 14:29:47 2004 Subject: [ python-Bugs-1009263 ] non-ascii readline input crashes python Message-ID: Bugs item #1009263, was opened at 2004-08-14 19:19 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: non-ascii readline input crashes python Initial Comment: Start Python 2.3.4 on Linux command line: $ python Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Enter the string "2?3" (2 times 3, the symbol between 2 and 3 is a multiplication sign, I think Unicode c397 or maybe 97c3 if I have it byte swapped) and hit return. Python reports a syntax error. Hit Ctrl-P to edit the line with readline. Use ctrl-D to delete the first character of the input line, and Python instantly crashes with a seg fault. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-16 13:29 Message: Logged In: YES user_id=6656 You should check the $LANG or $LC_ALL env vars. Or just run 'locale' in the shell. What version of readline are you using? Both instinct, and looking at the backtrace, suggest a readline bug to me. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2004-08-15 02:55 Message: Logged In: YES user_id=72053 Backtrace follows. I don't know how to tell my locale. My LOCALE shell variable is not set to anything--is there something else I need to check? Since the "2?3" displays properly in my terminal window, I think I'm likely using UTF-8. (gdb) r Starting program: /usr/local/bin/python [New Thread 1074951328 (LWP 6561)] Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 2?3 File "", line 1 2?3 ^ SyntaxError: invalid syntax >>> 2?3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1074951328 (LWP 6561)] 0x401eb687 in _rl_get_char_len () from /usr/lib/libreadline.so.4 (gdb) bt #0 0x401eb687 in _rl_get_char_len () from /usr/lib/libreadline.so.4 #1 0x401eb701 in _rl_compare_chars () from /usr/lib/libreadline.so.4 #2 0x401e0030 in rl_redisplay () from /usr/lib/libreadline.so.4 #3 0x401de816 in rl_redisplay () from /usr/lib/libreadline.so.4 #4 0x401d2588 in readline_internal_char () from /usr/lib/libreadline.so.4 #5 0x401d2695 in readline_internal_char () from /usr/lib/libreadline.so.4 #6 0x401d26ce in readline_internal_char () from /usr/lib/libreadline.so.4 #7 0x401d219f in readline () from /usr/lib/libreadline.so.4 #8 0x40019074 in call_readline (sys_stdin=0x4212fcc0, sys_stdout=0x4212fe20, prompt=0x40177254 ">>> ") at /home/phr/python/Python-2.3.4/Modules/readline.c:679 #9 0x080e6110 in PyOS_Readline (sys_stdin=0x4212fcc0, sys_stdout=0x4212fe20, prompt=0x40177254 ">>> ") at Parser/myreadline.c:183 #10 0x08056c47 in tok_nextc (tok=0x817f428) at Parser/tokenizer.c:683 #11 0x08055d8f in tok_get (tok=0x817f428, p_start=0xbfffecc4, p_end=0xbfffecc8) at Parser/tokenizer.c:1014 #12 0x080559de in PyTokenizer_Get (tok=0x817f428, p_start=0xbfffecc4, p_end=0xbfffecc8) at Parser/tokenizer.c:1414 #13 0x0805543a in parsetok (tok=0x817f428, g=0x8126b88, start=256, err_ret=0xbfffed10, flags=0) at Parser/parsetok.c:125 #14 0x080cb0e2 in PyRun_InteractiveOneFlags (fp=0x4212fcc0, filename=0x80f004a "", flags=0xbfffedf8) at Python/pythonrun.c:738 #15 0x080caf3b in PyRun_InteractiveLoopFlags (fp=0x4212fcc0, filename=0x80f004a "", flags=0xbfffedf8) at Python/pythonrun.c:690 #16 0x080cc2ee in PyRun_AnyFileExFlags (fp=0x4212fcc0, filename=0x80f004a "", closeit=0, flags=0xbfffedf8) at Python/pythonrun.c:653 #17 0x08054d32 in Py_Main (argc=0, argv=0xbfffee74) at Modules/main.c:415 #18 0x080548ab in main (argc=1, argv=0xbfffee74) at Modules/python.c:23 #19 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-14 22:10 Message: Logged In: YES user_id=55188 What locale do you use? I couldn't reproduce the problem on any of utf-8, iso8859-1, C, euc-kr locale. And, can you please attach a backtrace for the segfault point? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 From noreply at sourceforge.net Mon Aug 16 15:15:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 15:15:43 2004 Subject: [ python-Bugs-738154 ] pdb doesn't find some source files Message-ID: Bugs item #738154, was opened at 2003-05-15 11:53 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738154&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: pdb doesn't find some source files Initial Comment: In python 2.2.2 code object attribute co_filename contains relative to sys.path path (in python 2.3 the path is absolute), so pdb doesn't find some source files (for example, in the site-packages directory). The attached patch extends functionality of the bdb.Bdb.canonic method up to searching source files in sys.path. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-16 15:15 Message: Logged In: YES user_id=469548 Okay, closing. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2004-08-16 09:04 Message: Logged In: YES user_id=388573 Now I can't remember the problem too, since I don't use python2.2 more than a year. I suggest close this bug as "not bug". ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 16:15 Message: Logged In: YES user_id=469548 I'm not sure I understand the problem. I can do the following just fine (on 2.2, 2.3 and 2.4 CVS): (Pdb) b bikeemacs.py:32 Breakpoint 1 at /usr/lib/python2.3/site-packages/bikeemacs.py:32 Could you clarify? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738154&group_id=5470 From noreply at sourceforge.net Mon Aug 16 17:54:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 17:54:20 2004 Subject: [ python-Bugs-1010098 ] CPU usage shoots up with asyncore Message-ID: Bugs item #1010098, was opened at 2004-08-16 15:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas (thomasabc) Assigned to: Nobody/Anonymous (nobody) Summary: CPU usage shoots up with asyncore Initial Comment: The CPU usage of a python application program using asyncore.py shoot up to 99% under Python 2.4a1. After a comparison, it was found out that the same program ran without such high CPU usage under Python 2.3.3 A simple couple of programs to narrow down the problem showed that a single loop() was accompanied by a large number of poll() with 2.4a1, whereas a single loop() had only 3 calls to poll() with 2.3.3. Please let me know if there is anything else I can do for you to analyse. A couple of python scripts are attached in a zip file for you as below: - Summary of the test scripts With these scripts, the test attempts to identify what function calls are called that might explain the high CPU usage observed. asyncore_test.py: Taken from the Python Library Reference 11.24.2 asynchat Example, the test program starts a server process to simulate client request process. http_test.py: This program simply establishes connection to the server and closes after 10 seconds. - Procedure 1. Start asyncore_test.py 2. Start http_test.py 3. Stop asyncore_test.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 From noreply at sourceforge.net Mon Aug 16 17:57:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 17:57:05 2004 Subject: [ python-Bugs-1010102 ] smtpd.py docstring says wrong default class Message-ID: Bugs item #1010102, was opened at 2004-08-16 15:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010102&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Green (chrisgreen) Assigned to: Nobody/Anonymous (nobody) Summary: smtpd.py docstring says wrong default class Initial Comment: Python 2.3.3 smtpd.py Says it uses SMTPProxy by default where it's actually "PureProxy" -c classname Use `classname' as the concrete SMTP proxy class. Uses `SMTPProxy' by default. [...] class Options: setuid = 1 classname = 'PureProxy' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010102&group_id=5470 From noreply at sourceforge.net Mon Aug 16 18:13:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 18:13:44 2004 Subject: [ python-Bugs-1010102 ] smtpd.py docstring says wrong default class Message-ID: Bugs item #1010102, was opened at 2004-08-16 11:57 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010102&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Green (chrisgreen) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: smtpd.py docstring says wrong default class Initial Comment: Python 2.3.3 smtpd.py Says it uses SMTPProxy by default where it's actually "PureProxy" -c classname Use `classname' as the concrete SMTP proxy class. Uses `SMTPProxy' by default. [...] class Options: setuid = 1 classname = 'PureProxy' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010102&group_id=5470 From noreply at sourceforge.net Mon Aug 16 20:08:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 20:08:42 2004 Subject: [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 16:04 Message generated for change (Comment added) made by hakansonsf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-16 11:08 Message: Logged In: YES user_id=1103758 Maybe test TIOCGPGRP on a file/directory that the test creates anew, instead of /dev/tty. That should definitely match the process group of the current process. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-14 06:53 Message: Logged In: YES user_id=6656 Oh, crud. However, if we don't test TIOCGPGRP, what *can* we test? Perhaps we should just test that the call doesn't blow up. ---------------------------------------------------------------------- Comment By: Hakanson (hakansonsf) Date: 2004-08-13 15:57 Message: Logged In: YES user_id=1103758 Folks, I recently completed a build of python-2.3.2 (I realize 2.3.4 is out, but this info should still be relevant) on SPARC/Solaris-9, and as in this bug, the test_ioctl is failing. However, I believe I have found the cause, after running the tests with "-v" added to TESTOPTS in the Makefile. Since I have found no other mention of this particular cause for the failure, perhaps others will find this information helpful. The test is failing because the process group returned from the OS (the getpgrp() system call) does not match the process group associated with /dev/tty (as returned by the TIOCGPGRP ioctl() call). Now it turns out that this is not really an error, because some command shells (ksh, csh, perhaps bash), will assign each new command to a new process group, in order to do job-control (^Z interruption, moving to/from background, etc.). So, at least on this platform, using ksh, the test_ioctl will _always_ fail, since the "make" command gets a process group different from that of the parent shell, and different from /dev/tty's process group (which matches the parent shell). Therefor it would probably be better to test some other ioctl() call than the TIOCGPGRP call, or otherwise rework the test so it doesn't fail under what can be normal circumstances on some platforms. Regards, Marion ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-05 03:48 Message: Logged In: YES user_id=6656 You're supposed to run ./python ./Lib/test/regrtest.py test_ioctl or maybe ./python ./Lib/test/regrtest.py -v test_ioctl ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 00:39 Message: Logged In: YES user_id=91293 Blah. I was too hasty: while "./python ./Lib/test/test_ioctl.py" passed after making the modification I mentioned, a re-run of "make test" at the top level says that test_ioctl failed. Before I did the "make test", I did make sure to delete test_ioctl.pyc. ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 00:18 Message: Logged In: YES user_id=91293 I compiled with gcc-3.2.3 (compiled from source) on a RH9 system. The error message from doing "./python ./Lib/test/test_ioctl.py" (after appropriately setting LD_LIBRARY_PATH) was: Traceback (most recent call last): File "Lib/test/test_ioctl.py", line 2, in ? from test_support import TestSkipped, run_unittest File "/opt/src/Python-2.3/Lib/test/test_support.py", line 4, in ? raise ImportError, 'test_support must be imported from the test package' ImportError: test_support must be imported from the test package In the file Lib/test/test_ioctl.py, if I replace: from test_support import TestSkipped, run_unittest with from test.test_support import TestSkipped, run_unittest the test passes as expected. Gotta love error messages. ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 09:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 09:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 08:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 04:21 Message: Logged In: YES user_id=6656 Oh good <wink> Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 11:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 09:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 03:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply at sourceforge.net Mon Aug 16 20:12:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 16 20:13:02 2004 Subject: [ python-Bugs-1010196 ] xml.dom documentation omits hasAttribute, hasAttributeNS Message-ID: Bugs item #1010196, was opened at 2004-08-16 11:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010196&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom documentation omits hasAttribute, hasAttributeNS Initial Comment: http://www.python.org/doc/2.3.4/lib/dom-element- objects.html does not mention hasAttribute() and hasAttributeNS(), which are DOM L2 Core methods present on Element objects. They should be mentioned not just for completeness, but also so that people are not tempted to use getAttribute() and getAttributeNS() to test for attribute existence. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010196&group_id=5470 From noreply at sourceforge.net Tue Aug 17 00:15:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 00:15:18 2004 Subject: [ python-Bugs-1010370 ] sys.ps1 not protected in EditorWindow.py Message-ID: Bugs item #1010370, was opened at 2004-08-16 15:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Florek (d_florek) Assigned to: Nobody/Anonymous (nobody) Summary: sys.ps1 not protected in EditorWindow.py Initial Comment: Python 2.3.4 on Linux 2.4.19-xfs-p3-929 #1 SMP Thu Oct 24 11:29:34 PDT 2002 i686 unknown (RedHat 7.3, patched) Auto-indenting fails (and dumps errors to the shell) when idle is started as a file editor. I've wrapped original lines 987 and 1057 of EditorWindow.py (last_line_of_prompt = sys.ps1.split('\n')[-1]) with if self.context_use_ps1: last_line_of_prompt = sys.ps1.split('\n')[-1] else: last_line_of_prompt = '>>> ' This seems to fix it (might want to double-check other attempts to access sys.ps1 and make sure they're likewise protected). FYI, the errors I got (other than incorrect line numbers -- I was tracking down a different problem when I stumbled across this) are: Exception in Tkinter callback Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/work/florek/dev/python2.3/idlelib/EditorWindow.py", line 1069, in newline_and_indent_event last_line_of_prompt = sys.ps1.split('\n')[-1] AttributeError: 'module' object has no attribute 'ps1' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 From noreply at sourceforge.net Tue Aug 17 01:16:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 01:17:13 2004 Subject: [ python-Bugs-991962 ] Building with --disable-toolbox-glue fails Message-ID: Bugs item #991962, was opened at 2004-07-15 15:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Building with --disable-toolbox-glue fails Initial Comment: Building with --disable-toolbox-glue fails, because setup.py still tries to build lots of MacOSX extension modules (which fails). There's a define USE_TOOLBOX_OBJECT_GLUE in pyconfig.h that shows whether we're building with or without toolbox glue, but distutils needs to look at that. If it can, otherwise we need a flag in the Makefile too. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-16 16:16 Message: Logged In: YES user_id=357491 Can we add ``"--disable-toolbox-glue" not in distutils.sysconfig.get_config_var("CONFIG_ARGS")`` as part of the conditional? That should prevent unneeded compiling. If that does work the question becomes whether that should be part of the conditional for all the modules in setup.py or only some of them. Personally I say get rid all of them since if you are building with -- disable-toolbox-glue I would suspect you want a simple UNIX version of Python and not really have anything to do with OS X-specific features. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:32 Message: Logged In: YES user_id=357491 It seems like we need some way to either have access in Python to what the arguments to Configure were or what macro defs pyconfig.h comes up with. That would be enough info to find out if compiling with toolbox glue we turned off. Otherwise I don't know how Distutils could possibly get access without somehow parsing pyconfig.h to look to see what is set and what isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 From noreply at sourceforge.net Tue Aug 17 01:18:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 01:18:28 2004 Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct? Message-ID: Bugs item #978833, was opened at 2004-06-24 02:57 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: SSL-ed sockets don't close correct? Initial Comment: When testing FTP over SSL I have strong doubt, that ssl-ed sockets are not closed correctly. (This doesn't show with https because nobody takes care about whats going on "after the party".) See the following : --- I need to run FTP over SSL from windows (not shitty sftp via ssh etc!) as explained on http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html (good variant 3: FTP_TLS ) I tried to learn from M2Crypto's ftpslib.py (uses OpenSSL - not Pythons SSL) and made a wrapper for ftplib.FTP using Pythons SSL. I wrap the cmd socket like: self.voidcmd('AUTH TLS') ssl = socket.ssl(self.sock, self.key_file, self.cert_file) import httplib self.sock = httplib.FakeSocket(self.sock, ssl) self.file = self.sock.makefile('rb') Everything works ok, if I don't SSL the data port connection, but only the If I SSL the data port connection too, it almosts work, but ... self.voidcmd('PBSZ 0') self.voidcmd('PROT P') wrap the data connection with SSL: ssl = socket.ssl(conn, self.key_file, self.cert_file) import httplib conn = httplib.FakeSocket(conn, ssl) than in retrbinary it hangs endless in the last 'return self.voidresp()'. all data of the retrieved file is already correctly in my basket! The ftp server just won't send the final '226 Transfer complete.' on the cmd socket. Why? def retrbinary(self, cmd, callback, blocksize=8192, rest=None): self.voidcmd('TYPE I') conn = self.transfercmd(cmd, rest) fp = conn.makefile('rb') while 1: #data = conn.recv(blocksize) data = fp.read() #blocksize) if not data: break callback(data) fp.close() conn.close() return self.voidresp() what could be reason? The server is a ProFTPD 1.2.9 Server. I debugged, that the underlying (Shared)socket of the conn object is really closed. (If I simly omit the self.voidresp(), I have one file in the box, but subsequent ftp communication on that connection is not anymore correct.) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-16 16:18 Message: Logged In: YES user_id=357491 Is this still a problem for you, Roberto, with Python 2.4a2? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-10 15:30 Message: Logged In: YES user_id=212920 Hi Roberto! Today a patch for _ssl.c was checked in (see #945642) that might solve your problem, too. Could you please grab the *next* alpha (this will be Python 2.4 Alpha 2) and test and report afterwards if it is solved? Thanks for your help! Tino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 From noreply at sourceforge.net Tue Aug 17 04:17:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 04:17:43 2004 Subject: [ python-Bugs-1005325 ] inconsistent acceptance of floats for range() Message-ID: Bugs item #1005325, was opened at 2004-08-07 17:13 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005325&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 4 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistent acceptance of floats for range() Initial Comment: ``range(1.0)`` will raise a DeprecationWarning (thanks to PyArg_ParseTuple() warning when a float is passed when an integer is expected), but if you do ``range(1e100)`` it raises a TypeError saying that an "integer end argument expected, got float". Obviously not consistent. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-16 19:17 Message: Logged In: YES user_id=357491 OK, works for me. ---------------------------------------------------------------------- Comment By: Dave Watson (docwatson) Date: 2004-08-13 20:49 Message: Logged In: YES user_id=1094771 I've looked into it, and 1e100 is of type 'long float' internally, which uses a different range function (handle_range_long) instead of 1.0 which is a normal float, which uses the standard range function (bltin_range). It seems the long version was written after the standard one, and once the deprecation warning (which happens in both versions, but it will only print once per session, restart python to test each) is turned into an error, things will be consistent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005325&group_id=5470 From noreply at sourceforge.net Tue Aug 17 04:22:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 04:22:42 2004 Subject: [ python-Bugs-805304 ] super instances don't support item assignment Message-ID: Bugs item #805304, was opened at 2003-09-12 15:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Raymond Hettinger (rhettinger) Summary: super instances don't support item assignment Initial Comment: This snippet produces a TypeError in Python 2.2.3, 2.3, and CVS: class C(object): def __setitem__(self, name, value): print (name, value) class D(C): def __setitem__(self, name, value): super(D, self)[name] = value d = D() d['foo'] = 'bar' Here's the traceback: Traceback (most recent call last): File "/home/fdrake/tmp/setitem.py", line 10, in ? d['foo'] = 'bar' File "/home/fdrake/tmp/setitem.py", line 7, in __setitem__ super(D, self)[name] = value TypeError: object does not support item assignment The problem appears to be that the item assignment isn't getting mapped to the __setitem__ of the base class, so this is probably somewhere deep in Objects/typeobject.c. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-16 21:22 Message: Logged In: YES user_id=80475 Documented in Doc/lib/libfuncs.tex 1.173. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-03-20 17:56 Message: Logged In: YES user_id=6380 This should be coded as Raymond originally recommended: super(D, self).__setitem__(name, value). Raymond, can you update the docs? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-15 23:48 Message: Logged In: YES user_id=80475 Referring to Guido for pronouncement. I've been thinking that this one could be left alone and just document that super objects only do their magic upon explicit attribute lookup. Otherwise, fixing it completely involves combing Python for every place that directly calls functions from the slots table, and then adding a followup call using attribute lookup if the slot is empty. When it comes to functions like repr(obj), I think we want the super object to identify itself rather than forwarding the call to the target object's __repr__() method. The downside of leaving it alone is that it breaks the symmetry between obj[k] and obj.__getitem__[k]. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-13 18:19 Message: Logged In: YES user_id=80475 Okay, let's apply the two-step problem solving approach. First, declare the problem impossible to solve. Then, propose a solution ;-) The attached patch is a proof-of-concept. It teaches PyObject_SetItem to use an attribute lookup for super objects whenever a direct table lookup fails. If the approach is approved, the final version of the patch should also address PyObject_GetItem and other ways that the attribute lookup mechanism can be bypassed. Also, the test for super can be improved by adding PySuper_Check() to the typeobject.c API. Of course, there is also the question as to whether fixing this is a bug or a feature. It does enable a whole set of programs to run under Py2.3.1 and Py2.2.4 that would not run under Py2.3.0 and Py2.2.3. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-13 01:50 Message: Logged In: YES user_id=80475 This one is tough. All of super's magic happens with descriptors upon attribute lookup. The example above will work fine if the call were written as: "super(D, self).__setitem__(name)". However, when written as "super(D, self)[name]", ceval.c triggers a STORE_SUBSCR opcode which calls PyObject_SetItem which in turns looks directly at the super object's type table (and finding nothing). Nowhere in this process is an attribute lookup called or a descriptor invoked. The current implementation waits until attribute binding time to search the bases. Hence, at the time the super object is created, it doesn't know enough information to fill out its table about which methods will be available. Consequently, direct table probes will fail. To make a general purpose fix would be a mess and involves changing the semantics of super to do its base search at the time the super object is created and to fillout its table with the appropriate methods. Unfortunately, any dynamic changes to the methods in the base object would *not* get reflected at lookup. There may be a reasonable special purpose fix. Fill-out the entire superobject table with custom methods that trigger an attribute lookup. For instance, fillout the sq_ass_item slot with a function that calls self.__setitem__ which will trigger the attribute search. Even this approach has problems because the super object has no way of knowing in advance whether sq_ass_item or mp_ass_subscript is the appropriate method for the object being referred to (is it a mapping or a sequence?). I recommend punting on this one and documenting that direct syntax manipulation of super objects is not defined and the super().__special_method__ format be used instead. Perhaps, all of super's unfilled slots can be filled with a placeholder method that emits an explanatory error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470 From noreply at sourceforge.net Tue Aug 17 04:32:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 04:32:48 2004 Subject: [ python-Bugs-951482 ] New module: doc versus action Message-ID: Bugs item #951482, was opened at 2004-05-10 15:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=951482&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Raymond Hettinger (rhettinger) Summary: New module: doc versus action Initial Comment: Because the functions in the new module give direct access to API functions, syntactically legal code that uses them can be more fragile than normal -- leading to possible core dumps (which are normally considered to be interpreter bugs). Should Lib Ref 3.27 warn about this possibility? Can the interfacing be strengthened to cover at least some bad inputs? Can ceval be strengthed without slowing it down? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-16 21:32 Message: Logged In: YES user_id=80475 Michael Hudson patched compile.c to make PyNew_Code less susceptible to bogus arguments. See Python/compile.c 2.315 Also, I expanded the warnings in the docs for the new module. See Doc/lib/libnew.tex 1.10. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=951482&group_id=5470 From noreply at sourceforge.net Tue Aug 17 04:34:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 04:35:17 2004 Subject: [ python-Bugs-878275 ] Handle: class MyTest(unittest.TestSuite) Message-ID: Bugs item #878275, was opened at 2004-01-16 09:22 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Steve Purcell (purcell) Summary: Handle: class MyTest(unittest.TestSuite) Initial Comment: TestCases are supposed to be derived from unittest.TestCase; however, if they are derived from unittest.TestSuite, the traceback is inexplicable and hard to diagnose: Traceback (most recent call last): File "C:/pydev/tmp.py", line 10, in -toplevel- unittest.TextTestRunner(verbosity=2).run(suite) File "C:\PY24\lib\unittest.py", line 690, in run test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) File "C:\PY24\lib\unittest.py", line 423, in __call__ test(result) TypeError: 'str' object is not callable Let's either improve the error message or make it possible to derive from TestSuite. The above traceback is produced by the following script: import unittest class TestStats(unittest.TestSuite): def testtwo(self): self.assertEqual(2,2) suite = unittest.TestSuite() suite.addTest(unittest.makeSuite(TestStats)) unittest.TextTestRunner(verbosity=2).run(suite) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878275&group_id=5470 From noreply at sourceforge.net Tue Aug 17 04:36:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 04:36:59 2004 Subject: [ python-Bugs-574241 ] Automated daily documentation builds Message-ID: Bugs item #574241, was opened at 2002-06-26 14:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Automated daily documentation builds Initial Comment: Set-up a cron job or python script to make daily rebuilds of the Python documentation at: www.python.org/dev/doc/devel Developers using Windows and not using Cygwin do not have a method for doing their own builds. I think daily updates would be helpful for all developers and would increase the likelihood that people check their patches versus current documentation. Also, it increases the chance that someone will notice and report a documentation error earlier in the release cycle. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-16 21:36 Message: Logged In: YES user_id=80475 With your new automation scripts is it now possible to run a daily cron job? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 14:03 Message: Logged In: YES user_id=3066 I don't think failing frequently is a problem if the failure shows up in someone's email. It should probably go to python-docs@python.org, and I can turn that into a fix. Perhaps it should go to the Doc-SIG instead, to allow more people to help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-30 13:46 Message: Logged In: YES user_id=21627 I don't think this is possible. Automatic rebuilding of the documentation will likely fail frequently, because of errors in the tex input. OTOH, if somebody volunteers to produce the documentation automatically somewhere in the world (and fixes errors found during the rebuild), then it would be easy to mirror those on python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 From noreply at sourceforge.net Tue Aug 17 05:39:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 05:40:00 2004 Subject: [ python-Bugs-985154 ] HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin Message-ID: Bugs item #985154, was opened at 2004-07-04 22:38 Message generated for change (Comment added) made by gregsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Jason Tishler (jlt63) Summary: HAVE_FDATASYNC incorrectly set for 2.3.4 under cygwin Initial Comment: Building 2.3.4 from the tarball, #define HAVE_FDATASYNC 1 appears in the pyconfig.h file, and the build of 'posixmodule' fails with undefined symbol _fdatasync Workaround is to delete the line and proceed, of course, but I've never seen this before when building under cygwin. There is no 'fdatasync' mentioned in any /usr/include/*.h or /usr/local/include/*.h The cygwin installation is kind of a mongrel (4 or 5 upgrades since install, some selective) This is the ID string from the built python: Python 2.3.4 (#2, Jul 4 2004, 22:10:22) [GCC 3.3.1 (cygming special)] on cygwin Let me know of any details of the cygwin install which might be useful. ---------------------------------------------------------------------- >Comment By: Gregory Smith (gregsmith) Date: 2004-08-16 23:39 Message: Logged In: YES user_id=292741 Fine with me . Sorry about being out of touch for so long - I had to beef up my mail filtering due to spam, and as a side-effect the sourceforge traffic no longer shows up directly in front of me... Anyway, it seems pretty clear there's an anomaly with my cygwin (which shows 1.5.7-1); if no-one else has it then clearly there's no point in messing with the python install to fix it. I've had bad experiences with things breaking when I upgrade cygwin, so I'm squiffy about doing it again, maybe it's time for a 'scorched earth mode' upgrade. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-12 11:52 Message: Logged In: YES user_id=33168 Your wish is my command. :-) Closing as invalid, since this seems more a cygwin setup problem. Greg can re-open if he disagrees. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2004-08-09 12:43 Message: Logged In: YES user_id=86216 There has been no follow-up from Greg in a month. OK to close? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2004-07-08 07:10 Message: Logged In: YES user_id=86216 nnorwitz> Jason, do you know what the deal is with cygwin? AFAICT, Greg's Cygwin setup seems suspect. Actually, he alluded to this fact in the following: gregsmith> The cygwin installation is kind of a mongrel... On my Cygwin setup (i.e., 1.5.10-3), I have the following: /usr/include/sys/unistd.h: #ifndef __CYGWIN__ int _EXFUN(fdatasync, (int __fd)); #endif pyconfig.h: /* Define if you have the 'fdatasync' function. */ /* #undef HAVE_FDATASYNC */ Additionally, the official Cygwin Python package built cleanly. Greg, what version of Cygwin are you using? If not 1.5.10-3, then please upgrade and try again. If so, then your setup seems to be corrupted. Try reinstalling. Does it work any better now? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-07-07 21:32 Message: Logged In: YES user_id=33168 Jason, do you know what the deal is with cygwin? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-07 07:12 Message: Logged In: YES user_id=6656 Well, I guess that's an arguable bug in cygwin, but if you want to supply a patch that modifies configure to do the linking test too, I'll at least think about applying it :-) ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2004-07-05 21:58 Message: Logged In: YES user_id=292741 looked into config.log and 'configure' itself.. the compile for fdatasync succeeded, but the script does not attempt to link it. gcc -E led me to the following chunk of /usr/include/sys/unistd.h: (not inside any #ifdefs, as far as I can tell) int _EXFUN(fdatasync, (int __fd)); So it's declared in the header, but it's not in the library. This symbol is defined in libc.a on a RH8.0 system, I can't find it anywhere on the cygwin system. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-05 09:40 Message: Logged In: YES user_id=6656 That's odd. Why does configure think you have fdatasync? Maybe config.log will help... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=985154&group_id=5470 From noreply at sourceforge.net Tue Aug 17 07:39:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 07:39:43 2004 Subject: [ python-Bugs-1010370 ] sys.ps1 not protected in EditorWindow.py Message-ID: Bugs item #1010370, was opened at 2004-08-16 18:15 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Florek (d_florek) >Assigned to: Kurt B. Kaiser (kbk) Summary: sys.ps1 not protected in EditorWindow.py Initial Comment: Python 2.3.4 on Linux 2.4.19-xfs-p3-929 #1 SMP Thu Oct 24 11:29:34 PDT 2002 i686 unknown (RedHat 7.3, patched) Auto-indenting fails (and dumps errors to the shell) when idle is started as a file editor. I've wrapped original lines 987 and 1057 of EditorWindow.py (last_line_of_prompt = sys.ps1.split('\n')[-1]) with if self.context_use_ps1: last_line_of_prompt = sys.ps1.split('\n')[-1] else: last_line_of_prompt = '>>> ' This seems to fix it (might want to double-check other attempts to access sys.ps1 and make sure they're likewise protected). FYI, the errors I got (other than incorrect line numbers -- I was tracking down a different problem when I stumbled across this) are: Exception in Tkinter callback Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/work/florek/dev/python2.3/idlelib/EditorWindow.py", line 1069, in newline_and_indent_event last_line_of_prompt = sys.ps1.split('\n')[-1] AttributeError: 'module' object has no attribute 'ps1' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 From noreply at sourceforge.net Tue Aug 17 08:36:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 08:36:39 2004 Subject: [ python-Bugs-1010370 ] sys.ps1 not protected in EditorWindow.py Message-ID: Bugs item #1010370, was opened at 2004-08-16 17:15 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Florek (d_florek) Assigned to: Kurt B. Kaiser (kbk) Summary: sys.ps1 not protected in EditorWindow.py Initial Comment: Python 2.3.4 on Linux 2.4.19-xfs-p3-929 #1 SMP Thu Oct 24 11:29:34 PDT 2002 i686 unknown (RedHat 7.3, patched) Auto-indenting fails (and dumps errors to the shell) when idle is started as a file editor. I've wrapped original lines 987 and 1057 of EditorWindow.py (last_line_of_prompt = sys.ps1.split('\n')[-1]) with if self.context_use_ps1: last_line_of_prompt = sys.ps1.split('\n')[-1] else: last_line_of_prompt = '>>> ' This seems to fix it (might want to double-check other attempts to access sys.ps1 and make sure they're likewise protected). FYI, the errors I got (other than incorrect line numbers -- I was tracking down a different problem when I stumbled across this) are: Exception in Tkinter callback Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/work/florek/dev/python2.3/idlelib/EditorWindow.py", line 1069, in newline_and_indent_event last_line_of_prompt = sys.ps1.split('\n')[-1] AttributeError: 'module' object has no attribute 'ps1' ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 01:36 Message: Logged In: YES user_id=149084 When IDLE starts via PyShell.main() sys.ps1 is set to '>>>' at line 1273. How are you "starting idle as a file editor?" It may be started either with the idle script (probably in /usr/bin/ if IDLE was installed from the rpm) or by calling ../../python ./PyShell.py from .../Lib/idlelib. Also, take a look at idle.py, it's pretty flexible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 From noreply at sourceforge.net Tue Aug 17 08:40:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 08:40:33 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 03:41 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 01:40 Message: Logged In: YES user_id=149084 um, run win32 IDLE and cygwin IDLE at the same time? What happens when you run win32 IDLE without cygwin IDLE? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-16 04:24 Message: Logged In: YES user_id=358087 It hangs even if I don't do anything and even without screen saver. Seems to be a problem in Tk since if I run both win32 IDLE and cygwin IDLE both hang. If I run only cygwin IDLE it's OK. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:55 Message: Logged In: YES user_id=149084 If you just start IDLE (shell window only) and don't do anything, does it always hang in two hours? If so, /please/ try this without your screen saver. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-08 02:58 Message: Logged In: YES user_id=358087 Hangs means the window content does not refresh. I can move it, resize it ... It is killable and task manager show it as "active". ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 15:17 Message: Logged In: YES user_id=593130 By 'hangs' do you mean when viewing the TasKManager Applications list, and killable with its End Task button? or something more evil, like locks the computer and prevents rebooting? Even Outlook Express and Internet Explore, with MS's billions, still do the former. With Win95, 98, and XP home and pro, I have had several problems, often intermittent, and maybe hardware specific, with bad interactions between programs, screen savers, and stand-by. On LCDs (and, I believe, modern CRTs) 'screen savers' save nothing except the boredom of a constant picture. I would turn it off and also check screen properites/screensaver/power button and the bios to see if anything is scheduled to happen at 2 hours. The timing, if consistent, is definitely suspicious. A major change for Windows between 2.3.4 and 2.4 is the compiler 'upgrade' which could change a program's interaction with Windows and its vulnerability to bugs within. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 03:11 Message: Logged In: YES user_id=358087 1. "Pure" Python (without IDLE) don't hang after 2 hours 2. I didn't try this time but I'm pretty sure it hanged without screen saver as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-03 20:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 04:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 03:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Tue Aug 17 09:23:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 09:24:22 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 11:41 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-08-17 10:23 Message: Logged In: YES user_id=358087 Same thing, it hangs after about 2 hours. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 09:40 Message: Logged In: YES user_id=149084 um, run win32 IDLE and cygwin IDLE at the same time? What happens when you run win32 IDLE without cygwin IDLE? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-16 12:24 Message: Logged In: YES user_id=358087 It hangs even if I don't do anything and even without screen saver. Seems to be a problem in Tk since if I run both win32 IDLE and cygwin IDLE both hang. If I run only cygwin IDLE it's OK. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-11 04:55 Message: Logged In: YES user_id=149084 If you just start IDLE (shell window only) and don't do anything, does it always hang in two hours? If so, /please/ try this without your screen saver. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-08 10:58 Message: Logged In: YES user_id=358087 Hangs means the window content does not refresh. I can move it, resize it ... It is killable and task manager show it as "active". ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 23:17 Message: Logged In: YES user_id=593130 By 'hangs' do you mean when viewing the TasKManager Applications list, and killable with its End Task button? or something more evil, like locks the computer and prevents rebooting? Even Outlook Express and Internet Explore, with MS's billions, still do the former. With Win95, 98, and XP home and pro, I have had several problems, often intermittent, and maybe hardware specific, with bad interactions between programs, screen savers, and stand-by. On LCDs (and, I believe, modern CRTs) 'screen savers' save nothing except the boredom of a constant picture. I would turn it off and also check screen properites/screensaver/power button and the bios to see if anything is scheduled to happen at 2 hours. The timing, if consistent, is definitely suspicious. A major change for Windows between 2.3.4 and 2.4 is the compiler 'upgrade' which could change a program's interaction with Windows and its vulnerability to bugs within. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 11:11 Message: Logged In: YES user_id=358087 1. "Pure" Python (without IDLE) don't hang after 2 hours 2. I didn't try this time but I'm pretty sure it hanged without screen saver as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-04 04:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 12:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 11:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Tue Aug 17 10:01:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 10:02:10 2004 Subject: [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 19:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 Category: IDLE Group: None Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-17 03:01 Message: Logged In: YES user_id=80475 At least for Windows, this is *not* a feature. The Windows standard required these keys to be case insensitive (look at MS-Word for a practical example). Fixed by loading alternate upper-cased keys to config-keys.def. See Lib/idlelib/config-keys.def 1.21. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:48 Message: Logged In: YES user_id=149084 Although the Tk man pages state that extra modifiers are ignored if not in the binding, that's not true for Shift (or Caps Lock). I don't see a good way to program around this, there are many bindings native to tcl/tk like Ctrl-e which also don't work in conjunction with Shift. I'm going to say that that's the way it is, and it's a *feature* since you can assign different bindings for upper case letters. You can always use the Options menu to add the shifted bindings, since it's possible to have more than one keycode bound to a given event. Playing with the following tcl/tk program is instructive: wm title . BindTest frame .top pack .top -fill x button .top.ctrly -text Control-y -command printcy pack .top.ctrly -fill x button .top.ctrlshift2 -text Control-Shift-@ -command printcs2 pack .top.ctrlshift2 -fill x button .top.ctrlshift5 -text Control-Shift-% -command printcs5 pack .top.ctrlshift5 -fill x proc printcy {} { puts Control-y } proc printcs2 {} { puts Control-Shift-at } proc printcs5 {} { puts Control-Shift-percent } bind .top printcy bind .top printcs2 #bind .top printcs5 # The Shift is not needed (but does no harm): #bind .top printcs5 # But the 'percent' is required, the lc key cap doesn't work: bind .top printcs5 # space keysym is not the same for upper and lower case: bind .top {puts Shift-space} bind .top {puts space} # Print the key being pressed: bind .top {puts **%K} focus .tophydra /home/kbk/proj/tcl$ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-01 19:28 Message: Logged In: YES user_id=149084 Hrm? The way Tk is supposed to work, if there is no binding for a key + Shift, the Shift is ignored. Or was there a Shift binding in your case? Note that the Shift bindings had an error for which I recently checked in a fix. Latter due to be backported to 2.3.4. Don't know it this helps Kirby Urner. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 15:46 Message: Logged In: YES user_id=80475 Hey, hey! That was a good hint. It is the CAPS LOCK key that is that culprit. That is a bit weird because other windows applications like Excel and Word are not similarly affected by CAPS LOCK. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-01 13:44 Message: Logged In: YES user_id=149084 By any chance did NumLk get switched on? I've heard that can cause problems. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:30 Message: Logged In: YES user_id=80475 FWIW, I've had this happen also. Unfortunately, I usually have so much going on that I haven't been able to relate it to a specific cause. ---------------------------------------------------------------------- Comment By: Kirby Urner (urnerk) Date: 2003-11-17 11:04 Message: Logged In: YES user_id=191709 I'm using WinXP Pro. Given this has not previously been reported, I will do my best to gather data on your questions as I continue to use IDLE. Ideally, I will be able to duplicate it at will. We shall see. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-16 23:56 Message: Logged In: YES user_id=149084 I haven't observed this behavior, nor heard of it before. What version of Windows are you using? The keybindings are established in Tk just after IDLE starts and are subsequently intercepted and handled by the Tk library. Do all the Ctrl bindings fail? Even Tk defaults like Ctrl-E, which goes to end of line? What about Alt bindings? Do the Ctrl keys work in other applications after they stop working in IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Tue Aug 17 10:02:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 10:02:40 2004 Subject: [ python-Bugs-1004217 ] Shortcut keys don't work when CAPS LOCK is on Message-ID: Bugs item #1004217, was opened at 2004-08-05 16:48 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004217&group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed >Resolution: Fixed Priority: 5 Submitted By: otto (ottoisi) Assigned to: Kurt B. Kaiser (kbk) Summary: Shortcut keys don't work when CAPS LOCK is on Initial Comment: IDLE for win32 does not execute keyboard shortcuts when CAPS LOCK is on or the SHIFT key is is pressed. e.g. ctrl-C doesn't work if it's a capital C. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-17 03:02 Message: Logged In: YES user_id=80475 Fixed for Py2.4. See Lib/idlelib/config-keys.def 1.21. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:39 Message: Logged In: YES user_id=149084 That's correct. Don't do that :-) This is the way the keyboard and tcl/tk works. If you really want this, customize using the options menu. It's possible to have more than one keycode bound to an event. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-07 13:13 Message: Logged In: YES user_id=149084 Dup of 833957 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1004217&group_id=5470 From noreply at sourceforge.net Tue Aug 17 12:39:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 12:39:24 2004 Subject: [ python-Bugs-1010645 ] bsddb3 testsuite failure when running more than one time Message-ID: Bugs item #1010645, was opened at 2004-08-17 12:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010645&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb3 testsuite failure when running more than one time Initial Comment: running the testsuite with TESTOPTS="-l -unetwork,bsddb" leaves (sometimes?) an directory Lib/test/db_home, which lets two of the bsddb tests fail in further test runs. Removing this directory before the next test run, lets the tests complete sucessfully. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010645&group_id=5470 From noreply at sourceforge.net Tue Aug 17 15:26:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 15:27:04 2004 Subject: [ python-Bugs-891637 ] pydoc crashes on a class property Message-ID: Bugs item #891637, was opened at 2004-02-06 09:44 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891637&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc crashes on a class property Initial Comment: [forwarded from http://bugs.debian.org/231202] --- class foo(object): __slots__ = ['_bar'] bar = property(lambda (self): self._bar) def __init__(self, bar): self._bar = bar f = foo(1) assert(f.bar == 1) --- removing the parenthesis around the lambda's parameter avoids the pydoc crash. Python itself doesn't seem to care about the parenthesis. $ python tmp.py # no errors $ pydoc tmp Traceback (most recent call last): File "/usr/bin/pydoc", line 4, in ? pydoc.cli() File "/usr/lib/python2.3/pydoc.py", line 2123, in cli help.help(arg) File "/usr/lib/python2.3/pydoc.py", line 1582, in help elif request: doc(request, 'Help on %s:') File "/usr/lib/python2.3/pydoc.py", line 1375, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/usr/lib/python2.3/pydoc.py", line 283, in document if inspect.ismodule(object): return self.docmodule(*args) File "/usr/lib/python2.3/pydoc.py", line 990, in docmodule contents.append(self.document(value, key, name)) File "/usr/lib/python2.3/pydoc.py", line 284, in document if inspect.isclass(object): return self.docclass(*args) File "/usr/lib/python2.3/pydoc.py", line 1135, in docclass lambda t: t[1] == 'property') File "/usr/lib/python2.3/pydoc.py", line 1087, in spillproperties base = self.document(func, tag, mod) File "/usr/lib/python2.3/pydoc.py", line 285, in document if inspect.isroutine(object): return self.docroutine(*args) File "/usr/lib/python2.3/pydoc.py", line 1177, in docroutine args, varargs, varkw, defaults = inspect.getargspec(object) File "/usr/lib/python2.3/inspect.py", line 656, in getargspec args, varargs, varkw = getargs(func.func_code) File "/usr/lib/python2.3/inspect.py", line 624, in getargs remain[-1] = remain[-1] - 1 IndexError: list index out of range ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2004-08-17 15:26 Message: Logged In: YES user_id=60903 Fixed in - Lib/inspect.py 1.53 and 1.47.8.2 - Lib/test/test_inspect.py 1.15 and 1.12.8.3 ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2004-08-15 19:17 Message: Logged In: YES user_id=60903 Fixed in - Lib/inspect.py 1.53 and 1.47.8.2 - Lib/test/test_inspect.py 1.15 and 1.12.8.3 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-08 13:31 Message: Logged In: YES user_id=469548 This crashes as well: def foo((bar)): return 1 A patch is available at http://python.org/sf/1005466. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-08 12:23 Message: Logged In: YES user_id=469548 First, note that the problem doesn't lie in properties. This crashes as well: foo = lambda (bar): 1 second, Python does care about the parentheses. It just doesn't matter when the lambda has only one argument. Using parentheses creates a sublist instead of a parameter list, as in the following example with normal functions: def foo((bar, baz)): return bar assert(foo((1, 2)) == 1) pydoc (or rather, inspect) should still be fixed though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=891637&group_id=5470 From noreply at sourceforge.net Tue Aug 17 16:54:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 17:01:25 2004 Subject: [ python-Bugs-1010777 ] test_queue fails occasionally Message-ID: Bugs item #1010777, was opened at 2004-08-17 15:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Tim Peters (tim_one) Summary: test_queue fails occasionally Initial Comment: I guess this is some kind of race condition. I see test_queue fail about 5% of the time (judged by running ./python ../Lib/test/regrtest.py test_queue test_queue test_queue test_queue ... with a couple of hundred test_queue's, but I've seen it fail as part of a more normal test run too). It's always this failure: test test_queue failed -- blocking function '>' appeared not to block and then, at least sometimes, you get this traceback: Exception in thread Thread-3408: Traceback (most recent call last): File "/home/mwh/src/python/dist/src/Lib/threading.py", line 442, in __bootstrap self.run() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 23, in run self.fn(*self.args) File "/home/mwh/src/python/dist/src/Lib/Queue.py", line 129, in get item = self._get() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 58, in _get return Queue.Queue._get(self) AttributeError: 'NoneType' object has no attribute 'Queue' somewhat later, usually while a subsequent test is running. This is a debug build from CVS as of an hour or so back on Redhat Linux 9 (so, in particular, with the NPTL threading libray, not LinuxThreads). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 From noreply at sourceforge.net Tue Aug 17 19:10:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 19:10:54 2004 Subject: [ python-Bugs-1010370 ] sys.ps1 not protected in EditorWindow.py Message-ID: Bugs item #1010370, was opened at 2004-08-16 15:15 Message generated for change (Comment added) made by d_florek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Florek (d_florek) Assigned to: Kurt B. Kaiser (kbk) Summary: sys.ps1 not protected in EditorWindow.py Initial Comment: Python 2.3.4 on Linux 2.4.19-xfs-p3-929 #1 SMP Thu Oct 24 11:29:34 PDT 2002 i686 unknown (RedHat 7.3, patched) Auto-indenting fails (and dumps errors to the shell) when idle is started as a file editor. I've wrapped original lines 987 and 1057 of EditorWindow.py (last_line_of_prompt = sys.ps1.split('\n')[-1]) with if self.context_use_ps1: last_line_of_prompt = sys.ps1.split('\n')[-1] else: last_line_of_prompt = '>>> ' This seems to fix it (might want to double-check other attempts to access sys.ps1 and make sure they're likewise protected). FYI, the errors I got (other than incorrect line numbers -- I was tracking down a different problem when I stumbled across this) are: Exception in Tkinter callback Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/work/florek/dev/python2.3/idlelib/EditorWindow.py", line 1069, in newline_and_indent_event last_line_of_prompt = sys.ps1.split('\n')[-1] AttributeError: 'module' object has no attribute 'ps1' ---------------------------------------------------------------------- >Comment By: Dave Florek (d_florek) Date: 2004-08-17 10:10 Message: Logged In: YES user_id=1105316 We have a Tk-based app that integrates IDLE as the default text editor for python "scriptlets". We create a new idlelib.FileList attached to the parent gui, and then on-demand from a button do a editor = self.parentGui.flist.open(file) editor.set_close_hook(lambda self=self: self.parentGui.close_idle(self)) self.editor = editor the close_idle callback, among other things, calls flist.close_edit(widget.editor) I'll look at idle.py and PyShell.py for more ideas, but it seems to me if there's a valid "context" flag that indicates whether IDLE is acting as a Python shell interface or as a text-editor, then that flag should be used in this particular case, since there won't be a prompt when acting as a text-editor, and then there's no need to ensure that sys.ps1 is currently defined. Thanks, Dave ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-16 23:36 Message: Logged In: YES user_id=149084 When IDLE starts via PyShell.main() sys.ps1 is set to '>>>' at line 1273. How are you "starting idle as a file editor?" It may be started either with the idle script (probably in /usr/bin/ if IDLE was installed from the rpm) or by calling ../../python ./PyShell.py from .../Lib/idlelib. Also, take a look at idle.py, it's pretty flexible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 From noreply at sourceforge.net Tue Aug 17 21:13:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 21:14:05 2004 Subject: [ python-Bugs-1010952 ] running test_codecmaps_* takes too much effort Message-ID: Bugs item #1010952, was opened at 2004-08-17 21:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: running test_codecmaps_* takes too much effort Initial Comment: The only way I've found to actually run the codecmap tests is by running it over and over again, downloading the missing files when a test complains in between, until the tests no longer complains. E.g $ make test - test_codecmap_jp complains about a missing file - download this file $ make test - test_codecmap_jp complains about another missing filie - ... Another problem: it is completely unclear where I should place the downloaded files. I've worked around this by placing the files in Lib/test and patching test_multibytecodec_support to look for the files in os.path.dirname(__file__): cvs diff: Diffing . Index: test_multibytecodec_support.py ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Lib/test/ test_multibytecodec_support.py,v retrieving revision 1.5 diff -r1.5 test_multibytecodec_support.py 165a166 > self.mapfilename = os.path.join(os.path.dirname(__file__), self.mapfilename) It would be nice if there were a document that described what should be done to run these tests, adding the required files to CVS would be fine too :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 From noreply at sourceforge.net Tue Aug 17 21:19:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 17 21:20:01 2004 Subject: [ python-Bugs-1010952 ] running test_codecmaps_* takes too much effort Message-ID: Bugs item #1010952, was opened at 2004-08-17 21:13 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: running test_codecmaps_* takes too much effort Initial Comment: The only way I've found to actually run the codecmap tests is by running it over and over again, downloading the missing files when a test complains in between, until the tests no longer complains. E.g $ make test - test_codecmap_jp complains about a missing file - download this file $ make test - test_codecmap_jp complains about another missing filie - ... Another problem: it is completely unclear where I should place the downloaded files. I've worked around this by placing the files in Lib/test and patching test_multibytecodec_support to look for the files in os.path.dirname(__file__): cvs diff: Diffing . Index: test_multibytecodec_support.py ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Lib/test/ test_multibytecodec_support.py,v retrieving revision 1.5 diff -r1.5 test_multibytecodec_support.py 165a166 > self.mapfilename = os.path.join(os.path.dirname(__file__), self.mapfilename) It would be nice if there were a document that described what should be done to run these tests, adding the required files to CVS would be fine too :-) ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-17 21:19 Message: Logged In: YES user_id=580910 test_normalization suffers from a simular problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 From noreply at sourceforge.net Wed Aug 18 02:36:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 02:36:15 2004 Subject: [ python-Bugs-1011113 ] distutils install with -b / --build-base Message-ID: Bugs item #1011113, was opened at 2004-08-18 00:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011113&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: distutils install with -b / --build-base Initial Comment: This is somewhat related to Bug#818201, in that it involves that fact that the --build-base option only appears to be operational under the build command. Hence it is not possible to do: python setup.py install -b The --help for install does not say that one can, so the situation is not as inconsistent as in the previous bug report. Nevertheless, it is problematic that once one does: python setup.py build -b as far as I can tell there is _no way_ to just install the result. One needs to always do: python setup.py build -b install This seems somewhat unwieldy; perhaps -b should be more universally available to all distutil commands? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011113&group_id=5470 From noreply at sourceforge.net Wed Aug 18 04:15:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 04:15:46 2004 Subject: [ python-Bugs-1010370 ] sys.ps1 not protected in EditorWindow.py Message-ID: Bugs item #1010370, was opened at 2004-08-16 17:15 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Florek (d_florek) Assigned to: Kurt B. Kaiser (kbk) Summary: sys.ps1 not protected in EditorWindow.py Initial Comment: Python 2.3.4 on Linux 2.4.19-xfs-p3-929 #1 SMP Thu Oct 24 11:29:34 PDT 2002 i686 unknown (RedHat 7.3, patched) Auto-indenting fails (and dumps errors to the shell) when idle is started as a file editor. I've wrapped original lines 987 and 1057 of EditorWindow.py (last_line_of_prompt = sys.ps1.split('\n')[-1]) with if self.context_use_ps1: last_line_of_prompt = sys.ps1.split('\n')[-1] else: last_line_of_prompt = '>>> ' This seems to fix it (might want to double-check other attempts to access sys.ps1 and make sure they're likewise protected). FYI, the errors I got (other than incorrect line numbers -- I was tracking down a different problem when I stumbled across this) are: Exception in Tkinter callback Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/work/florek/dev/python2.3/idlelib/EditorWindow.py", line 1069, in newline_and_indent_event last_line_of_prompt = sys.ps1.split('\n')[-1] AttributeError: 'module' object has no attribute 'ps1' ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 21:15 Message: Logged In: YES user_id=149084 I'm thinking that it might be best to move the code which sets sys.ps1 from PyShell.main() to the EditorWindow module toplevel. Do you see a downside to that? (sys.ps1 is only defined for the python interactive interpreter, so it's undefined in IDLE until set.) ---------------------------------------------------------------------- Comment By: Dave Florek (d_florek) Date: 2004-08-17 12:10 Message: Logged In: YES user_id=1105316 We have a Tk-based app that integrates IDLE as the default text editor for python "scriptlets". We create a new idlelib.FileList attached to the parent gui, and then on-demand from a button do a editor = self.parentGui.flist.open(file) editor.set_close_hook(lambda self=self: self.parentGui.close_idle(self)) self.editor = editor the close_idle callback, among other things, calls flist.close_edit(widget.editor) I'll look at idle.py and PyShell.py for more ideas, but it seems to me if there's a valid "context" flag that indicates whether IDLE is acting as a Python shell interface or as a text-editor, then that flag should be used in this particular case, since there won't be a prompt when acting as a text-editor, and then there's no need to ensure that sys.ps1 is currently defined. Thanks, Dave ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 01:36 Message: Logged In: YES user_id=149084 When IDLE starts via PyShell.main() sys.ps1 is set to '>>>' at line 1273. How are you "starting idle as a file editor?" It may be started either with the idle script (probably in /usr/bin/ if IDLE was installed from the rpm) or by calling ../../python ./PyShell.py from .../Lib/idlelib. Also, take a look at idle.py, it's pretty flexible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 From noreply at sourceforge.net Wed Aug 18 04:43:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 04:43:42 2004 Subject: [ python-Bugs-1010777 ] test_queue fails occasionally Message-ID: Bugs item #1010777, was opened at 2004-08-17 10:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Tim Peters (tim_one) Summary: test_queue fails occasionally Initial Comment: I guess this is some kind of race condition. I see test_queue fail about 5% of the time (judged by running ./python ../Lib/test/regrtest.py test_queue test_queue test_queue test_queue ... with a couple of hundred test_queue's, but I've seen it fail as part of a more normal test run too). It's always this failure: test test_queue failed -- blocking function '>' appeared not to block and then, at least sometimes, you get this traceback: Exception in thread Thread-3408: Traceback (most recent call last): File "/home/mwh/src/python/dist/src/Lib/threading.py", line 442, in __bootstrap self.run() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 23, in run self.fn(*self.args) File "/home/mwh/src/python/dist/src/Lib/Queue.py", line 129, in get item = self._get() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 58, in _get return Queue.Queue._get(self) AttributeError: 'NoneType' object has no attribute 'Queue' somewhat later, usually while a subsequent test is running. This is a debug build from CVS as of an hour or so back on Redhat Linux 9 (so, in particular, with the NPTL threading libray, not LinuxThreads). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-17 22:43 Message: Logged In: YES user_id=31435 FYI, Guido and I first noticed that test_queue sometimes fails a few years ago. It's apparently much more likely to fail on a non-Windows box, perhaps because Windows is happy to switch threads frequently. I ran it for half an hour today on a WinXP box, and it didn't fail at all. IIRC, it's not easy to fix - - there are threads, and some of the coordination is done via time.sleep() calls. I'll leave this assigned to me for a few more days, but it's unlikely I'll find time to "do something" about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 From noreply at sourceforge.net Wed Aug 18 06:49:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 06:50:01 2004 Subject: [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 19:27 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 Category: IDLE Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 23:49 Message: Logged In: YES user_id=149084 OK, thanks for all that boring typing :-) There is still an issue with Ctrl-A, Ctrl-E, Ctrl-K etc., the emacs bindings native to tcl. I guess it will be a FAQ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-17 03:01 Message: Logged In: YES user_id=80475 At least for Windows, this is *not* a feature. The Windows standard required these keys to be case insensitive (look at MS-Word for a practical example). Fixed by loading alternate upper-cased keys to config-keys.def. See Lib/idlelib/config-keys.def 1.21. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:48 Message: Logged In: YES user_id=149084 Although the Tk man pages state that extra modifiers are ignored if not in the binding, that's not true for Shift (or Caps Lock). I don't see a good way to program around this, there are many bindings native to tcl/tk like Ctrl-e which also don't work in conjunction with Shift. I'm going to say that that's the way it is, and it's a *feature* since you can assign different bindings for upper case letters. You can always use the Options menu to add the shifted bindings, since it's possible to have more than one keycode bound to a given event. Playing with the following tcl/tk program is instructive: wm title . BindTest frame .top pack .top -fill x button .top.ctrly -text Control-y -command printcy pack .top.ctrly -fill x button .top.ctrlshift2 -text Control-Shift-@ -command printcs2 pack .top.ctrlshift2 -fill x button .top.ctrlshift5 -text Control-Shift-% -command printcs5 pack .top.ctrlshift5 -fill x proc printcy {} { puts Control-y } proc printcs2 {} { puts Control-Shift-at } proc printcs5 {} { puts Control-Shift-percent } bind .top printcy bind .top printcs2 #bind .top printcs5 # The Shift is not needed (but does no harm): #bind .top printcs5 # But the 'percent' is required, the lc key cap doesn't work: bind .top printcs5 # space keysym is not the same for upper and lower case: bind .top {puts Shift-space} bind .top {puts space} # Print the key being pressed: bind .top {puts **%K} focus .tophydra /home/kbk/proj/tcl$ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-01 19:28 Message: Logged In: YES user_id=149084 Hrm? The way Tk is supposed to work, if there is no binding for a key + Shift, the Shift is ignored. Or was there a Shift binding in your case? Note that the Shift bindings had an error for which I recently checked in a fix. Latter due to be backported to 2.3.4. Don't know it this helps Kirby Urner. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 15:46 Message: Logged In: YES user_id=80475 Hey, hey! That was a good hint. It is the CAPS LOCK key that is that culprit. That is a bit weird because other windows applications like Excel and Word are not similarly affected by CAPS LOCK. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-01 13:44 Message: Logged In: YES user_id=149084 By any chance did NumLk get switched on? I've heard that can cause problems. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:30 Message: Logged In: YES user_id=80475 FWIW, I've had this happen also. Unfortunately, I usually have so much going on that I haven't been able to relate it to a specific cause. ---------------------------------------------------------------------- Comment By: Kirby Urner (urnerk) Date: 2003-11-17 11:04 Message: Logged In: YES user_id=191709 I'm using WinXP Pro. Given this has not previously been reported, I will do my best to gather data on your questions as I continue to use IDLE. Ideally, I will be able to duplicate it at will. We shall see. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-16 23:56 Message: Logged In: YES user_id=149084 I haven't observed this behavior, nor heard of it before. What version of Windows are you using? The keybindings are established in Tk just after IDLE starts and are subsequently intercepted and handled by the Tk library. Do all the Ctrl bindings fail? Even Tk defaults like Ctrl-E, which goes to end of line? What about Alt bindings? Do the Ctrl keys work in other applications after they stop working in IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Wed Aug 18 07:01:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 07:02:01 2004 Subject: [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 19:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 Category: IDLE Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-18 00:01 Message: Logged In: YES user_id=80475 At least we covered the Windows standard keys. A FAQ entry seems appropriate for everything else where case sensitivity may be important. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 23:49 Message: Logged In: YES user_id=149084 OK, thanks for all that boring typing :-) There is still an issue with Ctrl-A, Ctrl-E, Ctrl-K etc., the emacs bindings native to tcl. I guess it will be a FAQ? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-17 03:01 Message: Logged In: YES user_id=80475 At least for Windows, this is *not* a feature. The Windows standard required these keys to be case insensitive (look at MS-Word for a practical example). Fixed by loading alternate upper-cased keys to config-keys.def. See Lib/idlelib/config-keys.def 1.21. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:48 Message: Logged In: YES user_id=149084 Although the Tk man pages state that extra modifiers are ignored if not in the binding, that's not true for Shift (or Caps Lock). I don't see a good way to program around this, there are many bindings native to tcl/tk like Ctrl-e which also don't work in conjunction with Shift. I'm going to say that that's the way it is, and it's a *feature* since you can assign different bindings for upper case letters. You can always use the Options menu to add the shifted bindings, since it's possible to have more than one keycode bound to a given event. Playing with the following tcl/tk program is instructive: wm title . BindTest frame .top pack .top -fill x button .top.ctrly -text Control-y -command printcy pack .top.ctrly -fill x button .top.ctrlshift2 -text Control-Shift-@ -command printcs2 pack .top.ctrlshift2 -fill x button .top.ctrlshift5 -text Control-Shift-% -command printcs5 pack .top.ctrlshift5 -fill x proc printcy {} { puts Control-y } proc printcs2 {} { puts Control-Shift-at } proc printcs5 {} { puts Control-Shift-percent } bind .top printcy bind .top printcs2 #bind .top printcs5 # The Shift is not needed (but does no harm): #bind .top printcs5 # But the 'percent' is required, the lc key cap doesn't work: bind .top printcs5 # space keysym is not the same for upper and lower case: bind .top {puts Shift-space} bind .top {puts space} # Print the key being pressed: bind .top {puts **%K} focus .tophydra /home/kbk/proj/tcl$ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-01 19:28 Message: Logged In: YES user_id=149084 Hrm? The way Tk is supposed to work, if there is no binding for a key + Shift, the Shift is ignored. Or was there a Shift binding in your case? Note that the Shift bindings had an error for which I recently checked in a fix. Latter due to be backported to 2.3.4. Don't know it this helps Kirby Urner. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 15:46 Message: Logged In: YES user_id=80475 Hey, hey! That was a good hint. It is the CAPS LOCK key that is that culprit. That is a bit weird because other windows applications like Excel and Word are not similarly affected by CAPS LOCK. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-01 13:44 Message: Logged In: YES user_id=149084 By any chance did NumLk get switched on? I've heard that can cause problems. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:30 Message: Logged In: YES user_id=80475 FWIW, I've had this happen also. Unfortunately, I usually have so much going on that I haven't been able to relate it to a specific cause. ---------------------------------------------------------------------- Comment By: Kirby Urner (urnerk) Date: 2003-11-17 11:04 Message: Logged In: YES user_id=191709 I'm using WinXP Pro. Given this has not previously been reported, I will do my best to gather data on your questions as I continue to use IDLE. Ideally, I will be able to duplicate it at will. We shall see. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-16 23:56 Message: Logged In: YES user_id=149084 I haven't observed this behavior, nor heard of it before. What version of Windows are you using? The keybindings are established in Tk just after IDLE starts and are subsequently intercepted and handled by the Tk library. Do all the Ctrl bindings fail? Even Tk defaults like Ctrl-E, which goes to end of line? What about Alt bindings? Do the Ctrl keys work in other applications after they stop working in IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Wed Aug 18 11:56:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 11:56:45 2004 Subject: [ python-Bugs-1008310 ] os.major() os.minor() example and description change Message-ID: Bugs item #1008310, was opened at 2004-08-12 22:21 Message generated for change (Comment added) made by ddorfman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008310&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven (grayshark) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: os.major() os.minor() example and description change Initial Comment: The description for os.major() and os.minor() are damn poor. major( device) Extracts a device major number from a raw device number. New in version 2.3. minor( device) Extracts a device minor number from a raw device number. New in version 2.3. The really bad part is the term "raw device number". it should be: Extracts a device [major,minor] number for stat st_rdev field, or returns a zero if the st_rdev does not reference a special block device. Example follows. ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-08-18 09:56 Message: Logged In: YES user_id=908995 The proposed description is incorrect. st_rdev is not the only place to get this value; st_dev comes to mind, and those interested in these values are likely to be playing with other system interfaces anyway, so implying a coupling with st_rdev would be a mistake. I haven't found any documentation suggesting that major and minor return 0 if the input is invalid, and since none of these operations are standardized, we shouldn't document what are platform- specific semantics. My recent posting on the topic to comp.lang.python ("using os.major") said, in part, The documentation for os.stat mentions st_rdev, but it doesn't call it the "raw" device number. The FreeBSD documentation is about evenly split on calling it the "raw device number" or the "device ID", but Posix uses the latter, and I think that makes more sense. There's nothing raw about this value; I think it's only "raw" compared to internal kernel structures, where a device could be a pointer to struct instead of an integer (it's certainly not more raw than st_dev, which has the same type). Accordingly, it might be good to change the documentation for all of these things to consistently use the term "device ID" instead of "raw device number". That might still be poor, but it's as much as can be said for these operations on all platforms. I'll submit a patch for that in a few days unless someone beats me to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008310&group_id=5470 From noreply at sourceforge.net Wed Aug 18 14:07:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 14:07:20 2004 Subject: [ python-Bugs-1011380 ] Make GIL acquire/release functions idempotent if PyEval_Init Message-ID: Bugs item #1011380, was opened at 2004-08-18 13:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011380&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gustavo J. A. M. Carneiro (gustavo) Assigned to: Nobody/Anonymous (nobody) Summary: Make GIL acquire/release functions idempotent if PyEval_Init Initial Comment: The patch makes GIL acquire/release functions idempotent if PyEval_InitThreads hasn't been called. Motivation for this change can be found in my post to python-dev, here: http://mail.python.org/pipermail/python-dev/2004-August/047870.html http://mail.python.org/pipermail/python-dev/2004-August/047871.html Some feedback here: http://mail.python.org/pipermail/python-dev/2004-August/047949.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011380&group_id=5470 From noreply at sourceforge.net Wed Aug 18 15:52:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 15:52:42 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 11:36 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-18 22:52 Message: Logged In: YES user_id=55188 Thanks for testing. Do you mean that it compiles on HP-UX with the current patch? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-13 00:57 Message: Logged In: YES user_id=200117 Oops! that was a fresh install of Python-2.4a2... ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-13 00:55 Message: Logged In: YES user_id=200117 I did a fresh install of Python-2.2a2 and applied your new patch, but I'm still getting compile errors for line 200: building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. Here are lines 198-203 after applying the patch #if Py_UNICODE_SIZE == 2 if (length == 2) { ucs4_t u4in [2] = {(ucs4_t)IN1, (ucs4_t)IN2}; encoded = dsg->encoder(u4in, &length); } else encoded = dsg->encoder(&c, &length); One of my collegues says that you can't initialise one variable with another variable, when using the cc compiler. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 22:03 Message: Logged In: YES user_id=55188 Thanks for testing! I uploaded new patch fixed the problem. Can you both test the patch whether it compiles? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 16:37 Message: Logged In: YES user_id=200117 After applying the patch I am still getting two comple errors on HP-UX 11i building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 07:14 Message: Logged In: YES user_id=55188 The attached patch converts C99 usages to plain legacy C. Can you please test it on HP-UX whether the problem is resolved? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-09 17:15 Message: Logged In: YES user_id=200117 I am getting slightly different errors on HP-UX 11i using the native C compiler 'cc'. building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 120: error 1578: Size of struct or union member is unknown. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1058: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1064: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1070: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1078: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1085: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1091: error 1523: Too many initializers. uname -a HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 14:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Wed Aug 18 15:53:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 15:53:22 2004 Subject: [ python-Bugs-1010952 ] running test_codecmaps_* takes too much effort Message-ID: Bugs item #1010952, was opened at 2004-08-18 04:13 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Hye-Shik Chang (perky) Summary: running test_codecmaps_* takes too much effort Initial Comment: The only way I've found to actually run the codecmap tests is by running it over and over again, downloading the missing files when a test complains in between, until the tests no longer complains. E.g $ make test - test_codecmap_jp complains about a missing file - download this file $ make test - test_codecmap_jp complains about another missing filie - ... Another problem: it is completely unclear where I should place the downloaded files. I've worked around this by placing the files in Lib/test and patching test_multibytecodec_support to look for the files in os.path.dirname(__file__): cvs diff: Diffing . Index: test_multibytecodec_support.py ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Lib/test/ test_multibytecodec_support.py,v retrieving revision 1.5 diff -r1.5 test_multibytecodec_support.py 165a166 > self.mapfilename = os.path.join(os.path.dirname(__file__), self.mapfilename) It would be nice if there were a document that described what should be done to run these tests, adding the required files to CVS would be fine too :-) ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-18 04:19 Message: Logged In: YES user_id=580910 test_normalization suffers from a simular problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 From noreply at sourceforge.net Wed Aug 18 15:56:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 15:56:38 2004 Subject: [ python-Bugs-949052 ] winzip cannot extrat tarfile created tars Message-ID: Bugs item #949052, was opened at 2004-05-06 12:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=949052&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Simon Eisenmann (longsleep) Assigned to: Nobody/Anonymous (nobody) Summary: winzip cannot extrat tarfile created tars Initial Comment: The tarfile module uses the posix way to handle long file names per default. This is not supported by lots of extractors (like winzip). This should be changed not to be the default. Long file names should be handled by the gnu extension anytime. right now this is reached by setting $tarobject.posix = False manually. In addition the tarfile module sets a file size on directory entries. This isnt supported as well on well known extractors like winzip. The size for directory entries should be zero anytime. I attached a patch to fix the latter problem. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-18 15:56 Message: Logged In: YES user_id=21627 Fixed with patch #995126. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=949052&group_id=5470 From noreply at sourceforge.net Wed Aug 18 16:56:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 16:56:24 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 03:36 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-18 15:56 Message: Logged In: YES user_id=200117 Sorry for the confusion, but it doesn't compile on HP-UX with the last patch. My post of 2004-08-12 16:57 was just correcting a typo in the previous post. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-18 14:52 Message: Logged In: YES user_id=55188 Thanks for testing. Do you mean that it compiles on HP-UX with the current patch? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 16:57 Message: Logged In: YES user_id=200117 Oops! that was a fresh install of Python-2.4a2... ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 16:55 Message: Logged In: YES user_id=200117 I did a fresh install of Python-2.2a2 and applied your new patch, but I'm still getting compile errors for line 200: building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. Here are lines 198-203 after applying the patch #if Py_UNICODE_SIZE == 2 if (length == 2) { ucs4_t u4in [2] = {(ucs4_t)IN1, (ucs4_t)IN2}; encoded = dsg->encoder(u4in, &length); } else encoded = dsg->encoder(&c, &length); One of my collegues says that you can't initialise one variable with another variable, when using the cc compiler. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 14:03 Message: Logged In: YES user_id=55188 Thanks for testing! I uploaded new patch fixed the problem. Can you both test the patch whether it compiles? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 08:37 Message: Logged In: YES user_id=200117 After applying the patch I am still getting two comple errors on HP-UX 11i building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-11 23:14 Message: Logged In: YES user_id=55188 The attached patch converts C99 usages to plain legacy C. Can you please test it on HP-UX whether the problem is resolved? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-09 09:15 Message: Logged In: YES user_id=200117 I am getting slightly different errors on HP-UX 11i using the native C compiler 'cc'. building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 120: error 1578: Size of struct or union member is unknown. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1058: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1064: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1070: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1078: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1085: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1091: error 1523: Too many initializers. uname -a HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 06:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Wed Aug 18 19:19:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 19:19:28 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 13:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Wed Aug 18 21:01:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 21:01:11 2004 Subject: [ python-Bugs-1011687 ] distutils install with -b / --build-base Message-ID: Bugs item #1011687, was opened at 2004-08-18 19:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011687&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: distutils install with -b / --build-base Initial Comment: This is somewhat related to Bug#818201, in that it involves that fact that the --build-base option only appears to be operational under the build command. Hence it is not possible to do: python setup.py install -b The --help for install does not say that one can, so the situation is not as inconsistent as in the previous bug report. Nevertheless, it is problematic that once one does: python setup.py build -b as far as I can tell there is _no way_ to just install the result. One needs to always do: python setup.py build -b install This seems somewhat unwieldy; perhaps -b should be more universally available to all distutil commands? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011687&group_id=5470 From noreply at sourceforge.net Wed Aug 18 21:02:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 21:02:17 2004 Subject: [ python-Bugs-1011687 ] distutils install with -b / --build-base Message-ID: Bugs item #1011687, was opened at 2004-08-18 19:01 Message generated for change (Settings changed) made by daishiharada You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011687&group_id=5470 Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: daishi harada (daishiharada) Assigned to: Nobody/Anonymous (nobody) Summary: distutils install with -b / --build-base Initial Comment: This is somewhat related to Bug#818201, in that it involves that fact that the --build-base option only appears to be operational under the build command. Hence it is not possible to do: python setup.py install -b The --help for install does not say that one can, so the situation is not as inconsistent as in the previous bug report. Nevertheless, it is problematic that once one does: python setup.py build -b as far as I can tell there is _no way_ to just install the result. One needs to always do: python setup.py build -b install This seems somewhat unwieldy; perhaps -b should be more universally available to all distutil commands? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011687&group_id=5470 From noreply at sourceforge.net Wed Aug 18 22:48:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 22:48:39 2004 Subject: [ python-Bugs-1010370 ] sys.ps1 not protected in EditorWindow.py Message-ID: Bugs item #1010370, was opened at 2004-08-16 15:15 Message generated for change (Comment added) made by d_florek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Florek (d_florek) Assigned to: Kurt B. Kaiser (kbk) Summary: sys.ps1 not protected in EditorWindow.py Initial Comment: Python 2.3.4 on Linux 2.4.19-xfs-p3-929 #1 SMP Thu Oct 24 11:29:34 PDT 2002 i686 unknown (RedHat 7.3, patched) Auto-indenting fails (and dumps errors to the shell) when idle is started as a file editor. I've wrapped original lines 987 and 1057 of EditorWindow.py (last_line_of_prompt = sys.ps1.split('\n')[-1]) with if self.context_use_ps1: last_line_of_prompt = sys.ps1.split('\n')[-1] else: last_line_of_prompt = '>>> ' This seems to fix it (might want to double-check other attempts to access sys.ps1 and make sure they're likewise protected). FYI, the errors I got (other than incorrect line numbers -- I was tracking down a different problem when I stumbled across this) are: Exception in Tkinter callback Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/work/florek/dev/python2.3/idlelib/EditorWindow.py", line 1069, in newline_and_indent_event last_line_of_prompt = sys.ps1.split('\n')[-1] AttributeError: 'module' object has no attribute 'ps1' ---------------------------------------------------------------------- >Comment By: Dave Florek (d_florek) Date: 2004-08-18 13:48 Message: Logged In: YES user_id=1105316 Whatever fixes the problem is fine with me. Knock yourself out. Seems to me that cases which are specific to run-as-shell or run-as-editor should be sensibly divided rather than "if there isn't a prompt then create a fake one" hacks, but you're the one who has to maintain it down the road. As I illustrated, I already have a fix in place. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 19:15 Message: Logged In: YES user_id=149084 I'm thinking that it might be best to move the code which sets sys.ps1 from PyShell.main() to the EditorWindow module toplevel. Do you see a downside to that? (sys.ps1 is only defined for the python interactive interpreter, so it's undefined in IDLE until set.) ---------------------------------------------------------------------- Comment By: Dave Florek (d_florek) Date: 2004-08-17 10:10 Message: Logged In: YES user_id=1105316 We have a Tk-based app that integrates IDLE as the default text editor for python "scriptlets". We create a new idlelib.FileList attached to the parent gui, and then on-demand from a button do a editor = self.parentGui.flist.open(file) editor.set_close_hook(lambda self=self: self.parentGui.close_idle(self)) self.editor = editor the close_idle callback, among other things, calls flist.close_edit(widget.editor) I'll look at idle.py and PyShell.py for more ideas, but it seems to me if there's a valid "context" flag that indicates whether IDLE is acting as a Python shell interface or as a text-editor, then that flag should be used in this particular case, since there won't be a prompt when acting as a text-editor, and then there's no need to ensure that sys.ps1 is currently defined. Thanks, Dave ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-16 23:36 Message: Logged In: YES user_id=149084 When IDLE starts via PyShell.main() sys.ps1 is set to '>>>' at line 1273. How are you "starting idle as a file editor?" It may be started either with the idle script (probably in /usr/bin/ if IDLE was installed from the rpm) or by calling ../../python ./PyShell.py from .../Lib/idlelib. Also, take a look at idle.py, it's pretty flexible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010370&group_id=5470 From noreply at sourceforge.net Wed Aug 18 22:55:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 22:55:23 2004 Subject: [ python-Bugs-1011790 ] GC assertion failure Message-ID: Bugs item #1011790, was opened at 2004-08-18 22:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011790&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stephane Thiell (mbuna) Assigned to: Nobody/Anonymous (nobody) Summary: GC assertion failure Initial Comment: I'm encountering the following problem: Objects/classobject.c:631: failed assertion `g->gc.gc_refs != _PyGC_REFS_UNTRACKED' Abort Program received signal SIGABRT, Aborted. 0x900429ac in kill () (gdb) bt #0 0x900429ac in kill () #1 0x9009eb1c in abort () #2 0x95fec53c in __eprintf () #3 0x95f4e1d8 in PyInstance_New () #4 0x95fa9600 in PyEval_GetFuncDesc () #5 0x95fa6c64 in PyEval_EvalCode () #6 0x95fa7e30 in PyEval_EvalCodeEx () #7 0x95f5f354 in PyFunction_SetClosure () #8 0x95f4a8d0 in PyObject_Call () #9 0x95fa91ec in PyEval_CallObjectWithKeywords () #10 0x000aea30 in pypeak_stream_event_callback (s=0x0, type=406112, self=0x3) at peakmodule.c:499 (The stack seems corrupted as arguments make no sense in #10) I use the current version of latest Mac OS X: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011790&group_id=5470 From noreply at sourceforge.net Wed Aug 18 23:08:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 18 23:08:46 2004 Subject: [ python-Bugs-1011790 ] GC assertion failure Message-ID: Bugs item #1011790, was opened at 2004-08-18 22:55 Message generated for change (Comment added) made by mbuna You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011790&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Stephane Thiell (mbuna) Assigned to: Nobody/Anonymous (nobody) Summary: GC assertion failure Initial Comment: I'm encountering the following problem: Objects/classobject.c:631: failed assertion `g->gc.gc_refs != _PyGC_REFS_UNTRACKED' Abort Program received signal SIGABRT, Aborted. 0x900429ac in kill () (gdb) bt #0 0x900429ac in kill () #1 0x9009eb1c in abort () #2 0x95fec53c in __eprintf () #3 0x95f4e1d8 in PyInstance_New () #4 0x95fa9600 in PyEval_GetFuncDesc () #5 0x95fa6c64 in PyEval_EvalCode () #6 0x95fa7e30 in PyEval_EvalCodeEx () #7 0x95f5f354 in PyFunction_SetClosure () #8 0x95f4a8d0 in PyObject_Call () #9 0x95fa91ec in PyEval_CallObjectWithKeywords () #10 0x000aea30 in pypeak_stream_event_callback (s=0x0, type=406112, self=0x3) at peakmodule.c:499 (The stack seems corrupted as arguments make no sense in #10) I use the current version of latest Mac OS X: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin ---------------------------------------------------------------------- >Comment By: Stephane Thiell (mbuna) Date: 2004-08-18 23:08 Message: Logged In: YES user_id=342163 Damn, I just found the problem. It isn't the core but simply my C module where I forgot to increase the refcount in an accessor method. Sorry for the trouble. I'm a python users since a few days and enjoying its great extensibility ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011790&group_id=5470 From noreply at sourceforge.net Thu Aug 19 03:14:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 03:14:38 2004 Subject: [ python-Bugs-769569 ] weird/buggy inspect.getsource behavious Message-ID: Bugs item #769569, was opened at 2003-07-11 12:42 Message generated for change (Comment added) made by percivall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien de Menten (sdementen) Assigned to: Nobody/Anonymous (nobody) Summary: weird/buggy inspect.getsource behavious Initial Comment: Using python 2.2.2 on a mandrake 9.1 with the inspect.py of python 2.2.3 (correction for lambda keyword), I run the following code """ import inspect a = [ None, lambda x: x>1 and x<0, None] print "Ok",inspect.getsource(a[1]) if 1: a = [ None, lambda x: x>1 and x<0, None] print "Ko",inspect.getsource(a[1]) """ Two weird behaviours occurs 1. The line "print "Ok",inspect.getsource(a[1])" prints Ok lambda x: x>1 and x<0, None] It prints a superfluous line. 2. The line "print "Ko",inspect.getsource(a[1])" raises an exception Ko Traceback (most recent call last): File "bug-inspect.py", line 13, in ? print "Ko",inspect.getsource(a[1]) File "/usr/lib/python2.2/inspect.py", line 523, in getsource lines, lnum = getsourcelines(object) File "/usr/lib/python2.2/inspect.py", line 515, in getsourcelines else: return getblock(lines[lnum:]), lnum + 1 File "/usr/lib/python2.2/inspect.py", line 498, in getblock tokenize.tokenize(ListReader(lines).readline, BlockFinder().tokeneater) File "/usr/lib/python2.2/tokenize.py", line 138, in tokenize tokenize_loop(readline, tokeneater) File "/usr/lib/python2.2/tokenize.py", line 144, in tokenize_loop for token_info in generate_tokens(readline): File "/usr/lib/python2.2/tokenize.py", line 218, in generate_tokens raise TokenError, ("EOF in multi-line statement", (lnum, 0)) tokenize.TokenError: ('EOF in multi-line statement', (7, 0)) ---------------------------------------------------------------------- Comment By: Simon Percivall (percivall) Date: 2004-08-19 03:14 Message: Logged In: YES user_id=329382 http://www.python.org/sf/1011890 fixes problem 1. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-15 14:57 Message: Logged In: YES user_id=469548 I can't reproduce problem 2 on today's CVS, but http://python.org/sf/1006219 fixes problem 1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 From noreply at sourceforge.net Thu Aug 19 03:18:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 03:18:02 2004 Subject: [ python-Bugs-1011893 ] Cannot import PKZIP 2.50 created ZIP file Message-ID: Bugs item #1011893, was opened at 2004-08-19 13:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011893&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dennis Chuah (dennis_cs_chuah) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot import PKZIP 2.50 created ZIP file Initial Comment: Python 2.3.2 Windows platform Python is unable to import modules in ZIP files created by the PKZIP command line tool, version 2.50. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011893&group_id=5470 From noreply at sourceforge.net Thu Aug 19 03:20:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 03:20:03 2004 Subject: [ python-Bugs-1011894 ] PyDoc does not support ZIP Message-ID: Bugs item #1011894, was opened at 2004-08-19 13:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011894&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dennis Chuah (dennis_cs_chuah) Assigned to: Nobody/Anonymous (nobody) Summary: PyDoc does not support ZIP Initial Comment: Python 2.3.2: Windows version It is possible to run PyDoc as a HTTP server that serves Python Doc pages. When run in this mode, it does not list modules and packages in .ZIP files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011894&group_id=5470 From noreply at sourceforge.net Thu Aug 19 03:42:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 03:42:28 2004 Subject: [ python-Bugs-1008690 ] Incorrect href in Tutorial. Message-ID: Bugs item #1008690, was opened at 2004-08-13 09:36 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008690&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Incorrect href in Tutorial. Initial Comment: It seems like the always has a href="genindex.html" attribute. However, the tutorial uses the --numeric option to mkhowto, so the index lives at node18.html, making this an invalid link. I don't understand the documentation building tools well enough to fix this, so I'm assigning this to Fred. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-18 21:42 Message: Logged In: YES user_id=3066 Fixed in Doc/perl/l2hinit.perl revision 1.82. The make_head_and_body() function used a hardcoded value for the element for the index; this patch causes the proper output filename to be captured during the transformation phase so it can be used during the page assembly phase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008690&group_id=5470 From noreply at sourceforge.net Thu Aug 19 05:18:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 05:18:48 2004 Subject: [ python-Bugs-574241 ] Automated daily documentation builds Message-ID: Bugs item #574241, was opened at 2002-06-26 15:58 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Automated daily documentation builds Initial Comment: Set-up a cron job or python script to make daily rebuilds of the Python documentation at: www.python.org/dev/doc/devel Developers using Windows and not using Cygwin do not have a method for doing their own builds. I think daily updates would be helpful for all developers and would increase the likelihood that people check their patches versus current documentation. Also, it increases the chance that someone will notice and report a documentation error earlier in the release cycle. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-18 23:18 Message: Logged In: YES user_id=3066 At this point it is trivial to checkout and build the documentation automatically, with one caveat. The script would need to be able to do an authenticated checkout from SourceForge, and needs to be able to log into the python.org webserver as one of the webmasters to install the fresh tarball. While an anonymous checkout of the documentation sources is possible, it's out of date by several hours (as long as we use SF's CVS). That means the script needs to run within the context of an ssh-agent with the right keys added, or the keys must not have passphrases. I'm too paranoid to live without passphrases on my private keys, and I really haven't thought about how to run a cron job such that it can use a properly populated ssh-agent, but that seems conceptually fragile. (Who *always* has such an agent running, not just when logged in directly?) The documentation build is too heavy a process to run on the python.org webserver itself, and that still relies on being able to do an authenticated checkout from SF. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-16 22:36 Message: Logged In: YES user_id=80475 With your new automation scripts is it now possible to run a daily cron job? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 15:03 Message: Logged In: YES user_id=3066 I don't think failing frequently is a problem if the failure shows up in someone's email. It should probably go to python-docs@python.org, and I can turn that into a fix. Perhaps it should go to the Doc-SIG instead, to allow more people to help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-30 14:46 Message: Logged In: YES user_id=21627 I don't think this is possible. Automatic rebuilding of the documentation will likely fail frequently, because of errors in the tex input. OTOH, if somebody volunteers to produce the documentation automatically somewhere in the world (and fixes errors found during the rebuild), then it would be easy to mirror those on python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 From noreply at sourceforge.net Thu Aug 19 05:49:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 05:49:21 2004 Subject: [ python-Bugs-1011790 ] GC assertion failure Message-ID: Bugs item #1011790, was opened at 2004-08-18 16:55 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011790&group_id=5470 Category: Python Interpreter Core >Group: 3rd Party Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Stephane Thiell (mbuna) Assigned to: Nobody/Anonymous (nobody) Summary: GC assertion failure Initial Comment: I'm encountering the following problem: Objects/classobject.c:631: failed assertion `g->gc.gc_refs != _PyGC_REFS_UNTRACKED' Abort Program received signal SIGABRT, Aborted. 0x900429ac in kill () (gdb) bt #0 0x900429ac in kill () #1 0x9009eb1c in abort () #2 0x95fec53c in __eprintf () #3 0x95f4e1d8 in PyInstance_New () #4 0x95fa9600 in PyEval_GetFuncDesc () #5 0x95fa6c64 in PyEval_EvalCode () #6 0x95fa7e30 in PyEval_EvalCodeEx () #7 0x95f5f354 in PyFunction_SetClosure () #8 0x95f4a8d0 in PyObject_Call () #9 0x95fa91ec in PyEval_CallObjectWithKeywords () #10 0x000aea30 in pypeak_stream_event_callback (s=0x0, type=406112, self=0x3) at peakmodule.c:499 (The stack seems corrupted as arguments make no sense in #10) I use the current version of latest Mac OS X: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-18 23:49 Message: Logged In: YES user_id=31435 Ya, the "peakmodule.c" in the traceback kinda revealed the conclusion at once . It's almost certain that failures of this kind don't occur due to core code, since that's run by hundreds of thousands of people every day. I'm delighted to see that you're running a debug-build Python! That's the best way to minimize debugging time for your own C extensions (of course the Python developers use debug builds extensively for Python development too). ---------------------------------------------------------------------- Comment By: Stephane Thiell (mbuna) Date: 2004-08-18 17:08 Message: Logged In: YES user_id=342163 Damn, I just found the problem. It isn't the core but simply my C module where I forgot to increase the refcount in an accessor method. Sorry for the trouble. I'm a python users since a few days and enjoying its great extensibility ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011790&group_id=5470 From noreply at sourceforge.net Thu Aug 19 08:03:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 08:03:30 2004 Subject: [ python-Bugs-574241 ] Automated daily documentation builds Message-ID: Bugs item #574241, was opened at 2002-06-26 21:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Automated daily documentation builds Initial Comment: Set-up a cron job or python script to make daily rebuilds of the Python documentation at: www.python.org/dev/doc/devel Developers using Windows and not using Cygwin do not have a method for doing their own builds. I think daily updates would be helpful for all developers and would increase the likelihood that people check their patches versus current documentation. Also, it increases the chance that someone will notice and report a documentation error earlier in the release cycle. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-19 08:03 Message: Logged In: YES user_id=21627 For a daily build, it is IMO sufficient to use the anonymous CVS - it may be a few hours behind, but you'ld have to wait a full day anyway for the changes to show up. If somebody builds the documentation elsewhere, a cronjob on python.org could pick it up from "elsewhere", which would mean no access to python.org is necessary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-19 05:18 Message: Logged In: YES user_id=3066 At this point it is trivial to checkout and build the documentation automatically, with one caveat. The script would need to be able to do an authenticated checkout from SourceForge, and needs to be able to log into the python.org webserver as one of the webmasters to install the fresh tarball. While an anonymous checkout of the documentation sources is possible, it's out of date by several hours (as long as we use SF's CVS). That means the script needs to run within the context of an ssh-agent with the right keys added, or the keys must not have passphrases. I'm too paranoid to live without passphrases on my private keys, and I really haven't thought about how to run a cron job such that it can use a properly populated ssh-agent, but that seems conceptually fragile. (Who *always* has such an agent running, not just when logged in directly?) The documentation build is too heavy a process to run on the python.org webserver itself, and that still relies on being able to do an authenticated checkout from SF. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-17 04:36 Message: Logged In: YES user_id=80475 With your new automation scripts is it now possible to run a daily cron job? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 21:03 Message: Logged In: YES user_id=3066 I don't think failing frequently is a problem if the failure shows up in someone's email. It should probably go to python-docs@python.org, and I can turn that into a fix. Perhaps it should go to the Doc-SIG instead, to allow more people to help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-30 20:46 Message: Logged In: YES user_id=21627 I don't think this is possible. Automatic rebuilding of the documentation will likely fail frequently, because of errors in the tex input. OTOH, if somebody volunteers to produce the documentation automatically somewhere in the world (and fixes errors found during the rebuild), then it would be easy to mirror those on python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 From noreply at sourceforge.net Thu Aug 19 08:39:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 08:39:37 2004 Subject: [ python-Bugs-574241 ] Automated daily documentation builds Message-ID: Bugs item #574241, was opened at 2002-06-26 15:58 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Automated daily documentation builds Initial Comment: Set-up a cron job or python script to make daily rebuilds of the Python documentation at: www.python.org/dev/doc/devel Developers using Windows and not using Cygwin do not have a method for doing their own builds. I think daily updates would be helpful for all developers and would increase the likelihood that people check their patches versus current documentation. Also, it increases the chance that someone will notice and report a documentation error earlier in the release cycle. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-19 02:39 Message: Logged In: YES user_id=3066 Perhaps that's good enough, though I've generally done updates from the latest CVS. Would anyone object to my setting up a cronjob to perform the build on starship? It appears that sufficient software is installed on that machine to perform the build (and much faster than on anything I have). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-19 02:03 Message: Logged In: YES user_id=21627 For a daily build, it is IMO sufficient to use the anonymous CVS - it may be a few hours behind, but you'ld have to wait a full day anyway for the changes to show up. If somebody builds the documentation elsewhere, a cronjob on python.org could pick it up from "elsewhere", which would mean no access to python.org is necessary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-18 23:18 Message: Logged In: YES user_id=3066 At this point it is trivial to checkout and build the documentation automatically, with one caveat. The script would need to be able to do an authenticated checkout from SourceForge, and needs to be able to log into the python.org webserver as one of the webmasters to install the fresh tarball. While an anonymous checkout of the documentation sources is possible, it's out of date by several hours (as long as we use SF's CVS). That means the script needs to run within the context of an ssh-agent with the right keys added, or the keys must not have passphrases. I'm too paranoid to live without passphrases on my private keys, and I really haven't thought about how to run a cron job such that it can use a properly populated ssh-agent, but that seems conceptually fragile. (Who *always* has such an agent running, not just when logged in directly?) The documentation build is too heavy a process to run on the python.org webserver itself, and that still relies on being able to do an authenticated checkout from SF. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-16 22:36 Message: Logged In: YES user_id=80475 With your new automation scripts is it now possible to run a daily cron job? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 15:03 Message: Logged In: YES user_id=3066 I don't think failing frequently is a problem if the failure shows up in someone's email. It should probably go to python-docs@python.org, and I can turn that into a fix. Perhaps it should go to the Doc-SIG instead, to allow more people to help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-30 14:46 Message: Logged In: YES user_id=21627 I don't think this is possible. Automatic rebuilding of the documentation will likely fail frequently, because of errors in the tex input. OTOH, if somebody volunteers to produce the documentation automatically somewhere in the world (and fixes errors found during the rebuild), then it would be easy to mirror those on python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 From noreply at sourceforge.net Thu Aug 19 16:49:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 16:49:24 2004 Subject: [ python-Bugs-574241 ] Automated daily documentation builds Message-ID: Bugs item #574241, was opened at 2002-06-26 20:58 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Automated daily documentation builds Initial Comment: Set-up a cron job or python script to make daily rebuilds of the Python documentation at: www.python.org/dev/doc/devel Developers using Windows and not using Cygwin do not have a method for doing their own builds. I think daily updates would be helpful for all developers and would increase the likelihood that people check their patches versus current documentation. Also, it increases the chance that someone will notice and report a documentation error earlier in the release cycle. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-19 15:49 Message: Logged In: YES user_id=6656 I'd have thought it was an entirely reasonable use of the starship, but I guess you could ask on the crew list first if you want to be really polite... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-19 07:39 Message: Logged In: YES user_id=3066 Perhaps that's good enough, though I've generally done updates from the latest CVS. Would anyone object to my setting up a cronjob to perform the build on starship? It appears that sufficient software is installed on that machine to perform the build (and much faster than on anything I have). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-19 07:03 Message: Logged In: YES user_id=21627 For a daily build, it is IMO sufficient to use the anonymous CVS - it may be a few hours behind, but you'ld have to wait a full day anyway for the changes to show up. If somebody builds the documentation elsewhere, a cronjob on python.org could pick it up from "elsewhere", which would mean no access to python.org is necessary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-08-19 04:18 Message: Logged In: YES user_id=3066 At this point it is trivial to checkout and build the documentation automatically, with one caveat. The script would need to be able to do an authenticated checkout from SourceForge, and needs to be able to log into the python.org webserver as one of the webmasters to install the fresh tarball. While an anonymous checkout of the documentation sources is possible, it's out of date by several hours (as long as we use SF's CVS). That means the script needs to run within the context of an ssh-agent with the right keys added, or the keys must not have passphrases. I'm too paranoid to live without passphrases on my private keys, and I really haven't thought about how to run a cron job such that it can use a properly populated ssh-agent, but that seems conceptually fragile. (Who *always* has such an agent running, not just when logged in directly?) The documentation build is too heavy a process to run on the python.org webserver itself, and that still relies on being able to do an authenticated checkout from SF. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-17 03:36 Message: Logged In: YES user_id=80475 With your new automation scripts is it now possible to run a daily cron job? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-07-02 20:03 Message: Logged In: YES user_id=3066 I don't think failing frequently is a problem if the failure shows up in someone's email. It should probably go to python-docs@python.org, and I can turn that into a fix. Perhaps it should go to the Doc-SIG instead, to allow more people to help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-06-30 19:46 Message: Logged In: YES user_id=21627 I don't think this is possible. Automatic rebuilding of the documentation will likely fail frequently, because of errors in the tex input. OTOH, if somebody volunteers to produce the documentation automatically somewhere in the world (and fixes errors found during the rebuild), then it would be easy to mirror those on python.org. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=574241&group_id=5470 From noreply at sourceforge.net Thu Aug 19 16:57:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 16:57:26 2004 Subject: [ python-Bugs-1012249 ] dictionary referencing error Message-ID: Bugs item #1012249, was opened at 2004-08-19 10:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: AMIT Consulting LLC (ckbcouture) Assigned to: Nobody/Anonymous (nobody) Summary: dictionary referencing error Initial Comment: When I write a class as such: class MyObject: myDict = {} ... Each new instance refers to the SAME dictionary, not a newly minted one. However, this does not hold true for other data types. This has forced me to place dictionary declarations in the __init__ method to ensure uniqueness. Unless this is intended for some obscure reason, it should be fixed. Thanks, Cameron ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 From noreply at sourceforge.net Thu Aug 19 17:45:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 17:45:41 2004 Subject: [ python-Bugs-933795 ] configure not able to find ncurses/curses in Solaris Message-ID: Bugs item #933795, was opened at 2004-04-12 13:12 Message generated for change (Comment added) made by beerfrick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933795&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 2 Submitted By: stefanparvu (sparvu) Assigned to: Nobody/Anonymous (nobody) Summary: configure not able to find ncurses/curses in Solaris Initial Comment: I am trying to build Python 2.3.3 on Solaris 9 x86. Everything goes fine except that I have some issues with curses module ... It looks like configure is failing to detect curses found /usr/lib or any ncurses installed under system. Other fixes: 1) I had to fix configure script in order to get it running by changing SunOS/5.6 in SunOS/5.* eg. " case $ac_sys_system/$ac_sys_release in # On OpenBSD, select(2) is not available if _XOPEN_SOURCE is defined, # even though select is a POSIX function. Reported by J. Ribbens. # Reconfirmed for OpenBSD 3.3 by Zachary Hamm, for 3.4 by Jason Ish. OpenBSD/2.* | OpenBSD/3.[01234]) define_xopen_source=no;; # On Solaris 2.6, sys/wait.h is inconsistent in the usage # of union __?sigval. Reported by Stuart Bishop. SunOS/5.*) " Im building python using 2.95 the GNU compiler. The configure command was something like: ./configure --prefix=/usr/local --with-threads --enable-shared My LD_LIBRARY_PATH is defined as: /usr/lib:/opt/sfw/lib:/usr/sfw/lib I have tried passing to the command line LDFLAGS="-L/usr/lib :/usr/sfw/lib -lcurses -ltermcap " ./configure .... without success --- I have found that after compilation there are some warnings about curses module ... *** WARNING: renaming "_curses" since importing it failed: ld.so.1: ./python: fatal: relocation error: file build/lib.solaris-2.9-i86pc-2.3/_curses.so: symbol newscr: referenced symbol not found building '_curses_panel' extension *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses ... which, I think, will end by having no curses module available. >From help() found out these: help> modules Please wait a moment while I gather a list of all available modules... ... _curses_failed getpass py_compile _curses_panel_failed So python 2.3.3 does not biuild 100% clean under Solaris x86 I havent tried this on sparc but most likely same problem is in there too. Please evaluate. stefan ---------------------------------------------------------------------- Comment By: Ariel Arjona (beerfrick) Date: 2004-08-19 10:45 Message: Logged In: YES user_id=200741 Submitted patch 1012280 https://sourceforge.net/tracker/index.php?func=detail&aid=1012280&group_id=5470&atid=305470 I saw this bug on both 2.3.3 and 2.3.4 on Solaris 8 on SPARC ---------------------------------------------------------------------- Comment By: stefanparvu (sparvu) Date: 2004-04-13 08:30 Message: Logged In: YES user_id=1019660 I think the problem is between GNU gcc compiler and autoconf ... when Im using Sun's compiler and libcurses ... I see no problem. python builds fine without any problem. The problem is visible when Im using gcc and autconf does not pick up the correct libcurses. At the moment Im swithcing to Sun's compiler ... stefan ---------------------------------------------------------------------- Comment By: stefanparvu (sparvu) Date: 2004-04-13 01:48 Message: Logged In: YES user_id=1019660 More details found: Looks like configure is not able to work with Solaris's libcurses at all. I have tried in one system which does not have libncurses at all. configure is failing to work with Solaris's libcurses. checking term.h usability... no checking term.h presence... yes configure: WARNING: term.h: present but cannot be compiled configure: WARNING: term.h: check for missing prerequisite headers? configure: WARNING: term.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for term.h... yes >From config.log configure:4690: checking term.h usability configure:4703: gcc -c -g -O2 conftest.c >&5 In file included from configure:4775: /usr/include/term.h:1034: parse error before `bool' /usr/include/term.h:1034: warning: no semicolon at end of struct or union /usr/include/term.h:1035: warning: data definition has no type or storage class /usr/include/term.h:1060: parse error before `SGTTY' /usr/include/term.h:1060: warning: no semicolon at end of struct or union /usr/include/term.h:1081: parse error before `sgr_mode' /usr/include/term.h:1081: warning: data definition has no type or storage class /usr/include/term.h:1082: parse error before `sgr_faked' /usr/include/term.h:1082: warning: data definition has no type or storage class /usr/include/term.h:1092: parse error before `funckeystarter' /usr/include/term.h:1092: warning: data definition has no type or storage class /usr/include/term.h:1094: parse error before `_fl_rawmode' /usr/include/term.h:1097: warning: data definition has no type or storage class /usr/include/term.h:1101: parse error before `_input_queue' /usr/include/term.h:1101: warning: data definition has no type or storage class /usr/include/term.h:1108: parse error before `*' /usr/include/term.h:1108: warning: data definition has no type or storage class /usr/include/term.h:1111: parse error before `bit_vector' /usr/include/term.h:1111: warning: data definition has no type or storage class /usr/include/term.h:1115: parse error before `check_turn_off' /usr/include/term.h:1115: warning: data definition has no type or storage class /usr/include/term.h:1116: parse error before `non_faked_mode' /usr/include/term.h:1116: warning: data definition has no type or storage class /usr/include/term.h:1117: parse error before `_cur_pair' /usr/include/term.h:1117: warning: data definition has no type or storage class /usr/include/term.h:1118: parse error before `*' /usr/include/term.h:1118: warning: data definition has no type or storage class /usr/include/term.h:1120: parse error before `}' /usr/include/term.h:1207: parse error before `int' /usr/include/term.h:1207: `vidputs' declared as function returning a function /usr/include/term.h:1207: parse error before `)' configure:4706: $? = 1 --- stefan ---------------------------------------------------------------------- Comment By: stefanparvu (sparvu) Date: 2004-04-12 15:13 Message: Logged In: YES user_id=1019660 Regarding this problem looks like 'configure' does not pickup Solaris's curses library. I had to manually pass to configure command libncurses library LDFLAGS="-L/opt/sfw/lib -R/opt/sfw/lib -lncurses" CPPFLAGS="-I/optsfw/include" ./configure --prefix=/usr/local --with-threads --enable-shared Does this mean that python needs libncurses and can not work with Solaris curses library !? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933795&group_id=5470 From noreply at sourceforge.net Thu Aug 19 18:00:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 18:00:59 2004 Subject: [ python-Bugs-1012249 ] dictionary referencing error Message-ID: Bugs item #1012249, was opened at 2004-08-19 09:57 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: AMIT Consulting LLC (ckbcouture) Assigned to: Nobody/Anonymous (nobody) Summary: dictionary referencing error Initial Comment: When I write a class as such: class MyObject: myDict = {} ... Each new instance refers to the SAME dictionary, not a newly minted one. However, this does not hold true for other data types. This has forced me to place dictionary declarations in the __init__ method to ensure uniqueness. Unless this is intended for some obscure reason, it should be fixed. Thanks, Cameron ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 11:00 Message: Logged In: YES user_id=80475 That is the intended behavior. Attribute definitions inside the class definition but outside the method definitions are essentially class variables. They are useful because each instance does not need to have its own copy. For cases where an instance needs its own copy, your solution using __init__ was the right thing to do. In time, this will be obvious and all will feel as right as rain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 From noreply at sourceforge.net Thu Aug 19 18:09:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 18:09:40 2004 Subject: [ python-Bugs-1012249 ] dictionary referencing error Message-ID: Bugs item #1012249, was opened at 2004-08-19 10:57 Message generated for change (Comment added) made by ckbcouture You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: AMIT Consulting LLC (ckbcouture) Assigned to: Nobody/Anonymous (nobody) Summary: dictionary referencing error Initial Comment: When I write a class as such: class MyObject: myDict = {} ... Each new instance refers to the SAME dictionary, not a newly minted one. However, this does not hold true for other data types. This has forced me to place dictionary declarations in the __init__ method to ensure uniqueness. Unless this is intended for some obscure reason, it should be fixed. Thanks, Cameron ---------------------------------------------------------------------- >Comment By: AMIT Consulting LLC (ckbcouture) Date: 2004-08-19 12:09 Message: Logged In: YES user_id=1096248 The problem is that this only seems to work for dictionaries, tuples and lists. it DOES NOT work for numbers and strings. Try the following: class Test: mint = 1 mchar = "A" mdict = {} mlist = [] mtup = () def __init__( self ): self.mint += 1 self.mchar += self.mchar self.mdict[ self.mchar ] = self.mint self.mlist.append( self.mdict ) self.mtup += ( self.mlist, ) print self.mtup for i in range(10): Test() For me it outputs: ([{'AA': 2}],) ([{'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) Which means that it is working as you say for some, but not all data types. Is THAT intended? Thanks, Cameron ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 12:00 Message: Logged In: YES user_id=80475 That is the intended behavior. Attribute definitions inside the class definition but outside the method definitions are essentially class variables. They are useful because each instance does not need to have its own copy. For cases where an instance needs its own copy, your solution using __init__ was the right thing to do. In time, this will be obvious and all will feel as right as rain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 From noreply at sourceforge.net Thu Aug 19 18:20:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 18:20:23 2004 Subject: [ python-Bugs-1012249 ] dictionary referencing error Message-ID: Bugs item #1012249, was opened at 2004-08-19 10:57 Message generated for change (Comment added) made by ckbcouture You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: AMIT Consulting LLC (ckbcouture) Assigned to: Nobody/Anonymous (nobody) Summary: dictionary referencing error Initial Comment: When I write a class as such: class MyObject: myDict = {} ... Each new instance refers to the SAME dictionary, not a newly minted one. However, this does not hold true for other data types. This has forced me to place dictionary declarations in the __init__ method to ensure uniqueness. Unless this is intended for some obscure reason, it should be fixed. Thanks, Cameron ---------------------------------------------------------------------- >Comment By: AMIT Consulting LLC (ckbcouture) Date: 2004-08-19 12:20 Message: Logged In: YES user_id=1096248 The problem is that this only seems to work for dictionaries, tuples and lists. it DOES NOT work for numbers and strings. Try the following: class Test: mint = 1 mchar = "A" mdict = {} mlist = [] mtup = () def __init__( self ): self.mint += 1 self.mchar += self.mchar self.mdict[ self.mchar ] = self.mint self.mlist.append( self.mdict ) self.mtup += ( self.mlist, ) print self.mtup for i in range(10): Test() For me it outputs: ([{'AA': 2}],) ([{'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) Which means that it is working as you say for some, but not all data types. Is THAT intended? Thanks, Cameron ---------------------------------------------------------------------- Comment By: AMIT Consulting LLC (ckbcouture) Date: 2004-08-19 12:09 Message: Logged In: YES user_id=1096248 The problem is that this only seems to work for dictionaries, tuples and lists. it DOES NOT work for numbers and strings. Try the following: class Test: mint = 1 mchar = "A" mdict = {} mlist = [] mtup = () def __init__( self ): self.mint += 1 self.mchar += self.mchar self.mdict[ self.mchar ] = self.mint self.mlist.append( self.mdict ) self.mtup += ( self.mlist, ) print self.mtup for i in range(10): Test() For me it outputs: ([{'AA': 2}],) ([{'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) Which means that it is working as you say for some, but not all data types. Is THAT intended? Thanks, Cameron ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 12:00 Message: Logged In: YES user_id=80475 That is the intended behavior. Attribute definitions inside the class definition but outside the method definitions are essentially class variables. They are useful because each instance does not need to have its own copy. For cases where an instance needs its own copy, your solution using __init__ was the right thing to do. In time, this will be obvious and all will feel as right as rain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 From noreply at sourceforge.net Thu Aug 19 18:39:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 18:39:09 2004 Subject: [ python-Bugs-1012315 ] weakref.WeakValueDictionary should override .has_key() Message-ID: Bugs item #1012315, was opened at 2004-08-19 12:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012315&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: weakref.WeakValueDictionary should override .has_key() Initial Comment: .has_key() currently does not return the correct info for a weakref.WeakValueDictionary. When you call it some times tells you that a key exists even tho the value is no longer in RAM. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012315&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:08:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:09:07 2004 Subject: [ python-Bugs-1012315 ] weakref.WeakValueDictionary should override .has_key() Message-ID: Bugs item #1012315, was opened at 2004-08-19 11:39 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012315&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) >Assigned to: Raymond Hettinger (rhettinger) Summary: weakref.WeakValueDictionary should override .has_key() Initial Comment: .has_key() currently does not return the correct info for a weakref.WeakValueDictionary. When you call it some times tells you that a key exists even tho the value is no longer in RAM. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012315&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:14:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:14:12 2004 Subject: [ python-Bugs-1012249 ] dictionary referencing error Message-ID: Bugs item #1012249, was opened at 2004-08-19 09:57 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: AMIT Consulting LLC (ckbcouture) Assigned to: Nobody/Anonymous (nobody) Summary: dictionary referencing error Initial Comment: When I write a class as such: class MyObject: myDict = {} ... Each new instance refers to the SAME dictionary, not a newly minted one. However, this does not hold true for other data types. This has forced me to place dictionary declarations in the __init__ method to ensure uniqueness. Unless this is intended for some obscure reason, it should be fixed. Thanks, Cameron ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 12:14 Message: Logged In: YES user_id=80475 This is also the way it is supposed to be. At issue is whether the object is mutable or not. If mutable, something like .append() alters the object inplace (at the class level). If immutable, something like a = a + b reads a from the class level, adds b creating a newobject, and stores the new object, a, back at the instance level. Please work through the tutorial or make a newsgroup posting requesting better explanations. This isn't a bug, it is just something intrinsic to Python and is a minor step that everyone has to go through on the path to mastering the language. ---------------------------------------------------------------------- Comment By: AMIT Consulting LLC (ckbcouture) Date: 2004-08-19 11:20 Message: Logged In: YES user_id=1096248 The problem is that this only seems to work for dictionaries, tuples and lists. it DOES NOT work for numbers and strings. Try the following: class Test: mint = 1 mchar = "A" mdict = {} mlist = [] mtup = () def __init__( self ): self.mint += 1 self.mchar += self.mchar self.mdict[ self.mchar ] = self.mint self.mlist.append( self.mdict ) self.mtup += ( self.mlist, ) print self.mtup for i in range(10): Test() For me it outputs: ([{'AA': 2}],) ([{'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) Which means that it is working as you say for some, but not all data types. Is THAT intended? Thanks, Cameron ---------------------------------------------------------------------- Comment By: AMIT Consulting LLC (ckbcouture) Date: 2004-08-19 11:09 Message: Logged In: YES user_id=1096248 The problem is that this only seems to work for dictionaries, tuples and lists. it DOES NOT work for numbers and strings. Try the following: class Test: mint = 1 mchar = "A" mdict = {} mlist = [] mtup = () def __init__( self ): self.mint += 1 self.mchar += self.mchar self.mdict[ self.mchar ] = self.mint self.mlist.append( self.mdict ) self.mtup += ( self.mlist, ) print self.mtup for i in range(10): Test() For me it outputs: ([{'AA': 2}],) ([{'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) ([{'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}, {'AA': 2}],) Which means that it is working as you say for some, but not all data types. Is THAT intended? Thanks, Cameron ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 11:00 Message: Logged In: YES user_id=80475 That is the intended behavior. Attribute definitions inside the class definition but outside the method definitions are essentially class variables. They are useful because each instance does not need to have its own copy. For cases where an instance needs its own copy, your solution using __init__ was the right thing to do. In time, this will be obvious and all will feel as right as rain. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012249&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:29:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:29:51 2004 Subject: [ python-Bugs-1010098 ] CPU usage shoots up with asyncore Message-ID: Bugs item #1010098, was opened at 2004-08-16 10:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Thomas (thomasabc) >Assigned to: A.M. Kuchling (akuchling) Summary: CPU usage shoots up with asyncore Initial Comment: The CPU usage of a python application program using asyncore.py shoot up to 99% under Python 2.4a1. After a comparison, it was found out that the same program ran without such high CPU usage under Python 2.3.3 A simple couple of programs to narrow down the problem showed that a single loop() was accompanied by a large number of poll() with 2.4a1, whereas a single loop() had only 3 calls to poll() with 2.3.3. Please let me know if there is anything else I can do for you to analyse. A couple of python scripts are attached in a zip file for you as below: - Summary of the test scripts With these scripts, the test attempts to identify what function calls are called that might explain the high CPU usage observed. asyncore_test.py: Taken from the Python Library Reference 11.24.2 asynchat Example, the test program starts a server process to simulate client request process. http_test.py: This program simply establishes connection to the server and closes after 10 seconds. - Procedure 1. Start asyncore_test.py 2. Start http_test.py 3. Stop asyncore_test.py ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 12:29 Message: Logged In: YES user_id=80475 Andrew, what this due to your updates or was Martin's loop counter the cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:34:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:34:21 2004 Subject: [ python-Bugs-992017 ] code that generates a segfault on Python 2.1-2.3 Message-ID: Bugs item #992017, was opened at 2004-07-15 18:56 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Ted Bach (bachtor) Assigned to: Nobody/Anonymous (nobody) Summary: code that generates a segfault on Python 2.1-2.3 Initial Comment: On a Redhat Linux 9 based system, the following causes a segfault: """ In python, you can call any expression. """ class foo: def __init__(s,times=1): s.times = times def __call__(s): print s.times def __mul__(s,o): return foo(o) def __coerce__(s,o): if isinstance(o,int): return o,s (foo(3)*10)() # no segfault (10*foo(3))() # segfaults # prints 10 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-08-07 16:44 Message: Logged In: YES user_id=4771 Here is a shorter example: class foo: def __coerce__(self, other): return other, self foo()+1 # segfault: infinite recursion in C classobject.c seems hopelessly prone to infinite recursion in C: whenever an operation needs coercion, __coerce__ is called and the operator PyNumber_Xxx() is called again on the result. The most obvious cases of recursion are taken care of, but there are and will always be more convoluted ways to create this recursion. There might be a way to solve the problem cleanly but currently I only see the solution of adding a C recursion check (Py_EnterRecursiveCall / Py_LeaveRecursiveCall). ---------------------------------------------------------------------- Comment By: Dima Dorfman (ddorfman) Date: 2004-07-22 09:18 Message: Logged In: YES user_id=908995 This is not the same problem as bug #980352; this one is an infinite recusion in the instance code (deriving foo from object makes the example work). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-16 08:45 Message: Logged In: YES user_id=6656 Isn't this likely to be a dup of bug [ 980352 ] coercion results used dangerously ? I haven't thought about either very hard, but both involve __coerce__ and core dumps... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:44:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:44:27 2004 Subject: [ python-Bugs-953599 ] asyncore misses socket closes when poll is used Message-ID: Bugs item #953599, was opened at 2004-05-13 16:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=953599&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Shane Kerr (shane_kerr) Assigned to: A.M. Kuchling (akuchling) Summary: asyncore misses socket closes when poll is used Initial Comment: Problem: If the loop() function of asyncore is invoked with poll rather than select, the function readwrite() is used when I/O is available on a socket. However, this function does not check for hangup - provided by POLLHUP. If a socket is attempting to write, then POLLOUT never gets set, so the socket hangs. Because poll() is returning immediately, but the return value is never used, asyncore busy-loops, consuming all available CPU. Possible solutions: The easy solution is to check for POLLHUP in the readwrite() function: if flags & (select.POLLOUT | select.POLLHUP): obj.handle_write_event() This makes the poll work exactly like the select - the application raises a socket.error set to EPIPE. An alternate solution - possibly more graceful - is to invoke the handle_close() method of the object: if flags & select.POLLHUP: obj.handle_close() else: if flags & select.POLLIN: obj.handle_read_event() if flags & select.pollout: obj.handle_write_event() This is incompatible with the select model, but it means that the read and write logic is now the same for socket hangups - handle_close() is invoked. ---------------------------------------------------------------------- Comment By: Alexey Klimkin (klimkin) Date: 2004-07-02 08:56 Message: Logged In: YES user_id=410460 Perhaps, it would be better to raise exception: def readwrite(obj, flags): try: if flags & (select.POLLIN | select.POLLPRI): obj.handle_read_event() if flags & select.POLLOUT: obj.handle_write_event() if flags & (select.POLLERR | select.POLLHUP | select.POLLNVAL): obj.handle_expt_event() except ExitNow: raise except: obj.handle_error() ... def handle_expt_event(self): err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) assert(err != 0) raise socket.error, (err, errorcode[err]) Since asyncore closes socket in handle_error, this solves the problem too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=953599&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:45:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:45:31 2004 Subject: [ python-Bugs-940578 ] glob.glob inconsistent about broken symlinks Message-ID: Bugs item #940578, was opened at 2004-04-23 04:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: glob.glob inconsistent about broken symlinks Initial Comment: `glob.glob()` uses `os.listdir()`, which includes borken symlinks in the listing if the pattern contains shell metacharacters but uses `os.path.exists()` which is False for broken symlinks if the pattern is a fixed name. Thus: >>> os.symlink('broken', 'sym1') >>> os.symlink('broken', 'sym2') >>> import glob >>> glob.glob('sym*') ['sym1', 'sym2'] >>> glob.glob('sym1') [] >>> glob.glob('sym2') [] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 12:45 Message: Logged In: YES user_id=80475 Did you already fix this one? ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-04-24 15:32 Message: Logged In: YES user_id=36166 This bug exists in all versions of the module since its creation up to 2.4. The correct behaviour (judging by the shell's behaviour - that's the model for the module, isn't it), is to always include broken symlinks in the results. Several fixes for this bug are provided by patch 941486 (http://python.org/sf/941486). [They all include the testcase attached here.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:46:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:47:03 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-30 19:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 12:46 Message: Logged In: YES user_id=80475 Was this one fixed? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 03:04 Message: Logged In: YES user_id=1038590 New patch (#1007087) created with a test for this bug, as well as a fix for it (the fix simply removes the 'sequence of 1' shortcut). Checks for the unicode case as well, although unicode didn't have this bug (due to a different join implementation). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 02:00 Message: Logged In: YES user_id=1038590 Don't know about anyone else, but the shortcut in str.join that returns a reference to the *original* string in the case of a single item sequence strikes me as very bad ju-ju: >>> class mystr(str): pass ... >>> s1 = mystr('fred') >>> s1 'fred' >>> s1.mutable = 42 >>> s1.mutable 42 >>> s2 = ''.join([s1]) >>> s2.mutable 42 When I call join, I expect to get a *new* object back, not a reference to an old one (this is safe for standard strings, but not for subclasses which may have mutable state). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2004-08-07 17:17 Message: Logged In: YES user_id=34209 The point of the original bugreport is not that some operations return strings instead of subtypes. The point is that *one* operation *sometimes* returns subtypes. It's inconsistent and unexpected behaviour, and since you clearly don't write 'sep.join(seq)' for a common case of 'seq' being a single item, something you will only occasionally trigger. I don't have an emotional investment in this bug, it's just something that came up on #python. I also don't care which way it's fixed -- but treating the single-element-sequence case the same as the multiple-element-sequence seems logical to me. Regardless of how the multiple-element-sequence is handled exactly :) As for why I didn't write a patch myself, Michael, if I had time for that, I would've spent it writing a good decorator proposal >:-) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-08-07 10:48 Message: Logged In: YES user_id=7887 If this was considered a bug: >>> type(ms("a")+ms("b")) >>> type(ms("a")[:]) Are these bugs as well? I belive this is how the implementation was intended to be, even if not optimal for subclasses. I suggest closing this bug as invalid, and writing a PEP about the possible new subclass support change (for all classes), if there's enough interest. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-05 11:10 Message: Logged In: YES user_id=593130 Duh, my turn to forget. For any beginners reading this ... >>> class ms(str): pass ... >>> a=ms('a') >>> type(''.join((a,))) Expanding mhw's second point: >>> e=ms() >>> type(e) >>> import copy >>> e2=copy.copy(e) >>> type(e2) >>> e3=e[:] >>> type(e3) >>> id(e),id(e2),id(e3) (9494608, 9009936, 8577440) so [:] is not exactly an abbreviated synonym for copy(). Is this a butg? (I haven't rechecked the respective docs yet.) One reason I hesitate to call the OP's original observation a bug is that the whole sujbect of operations on subtype instances seems not completely baked. Knowing the result types in all cases may require experiments as well as doc reading. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 07:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-04 15:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 14:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 09:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:55:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:55:40 2004 Subject: [ python-Bugs-1005737 ] compile errors on _codecs_iso2022.c Message-ID: Bugs item #1005737, was opened at 2004-08-09 11:36 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: roadkill (dharma_roadkill) Assigned to: Hye-Shik Chang (perky) Summary: compile errors on _codecs_iso2022.c Initial Comment: Building Python-2.4a2 on uname -a OSF1 ***.tnzi.com V5.1 2650 alpha (HP Tru64 5.1B on alpha server) One of the modules won't compile correctly. I note with interest that another submitter to Bug Tracker had an intermittant core dump in the iso2022 area. Maybe this is related to that other problem. The Tru64 cc compiler is fairly sensitive and gives warnings/errors when other compilers would be silent but those warnings/errors are usually worth looking at! cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1053: In the initializer for iso2022_kr_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1058: In the initializer for iso2022_jp_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1064: In the initializer for iso2022_jp_1_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1070: In the initializer for iso2022_jp_2_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1077: In the initializer for iso2022_jp_2004_config, an array's element type is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1084: In the initializer for iso2022_jp_3_config, an array's element typ e is incomplete, which precludes its initialization. (incompelinit) cc: Error: /u13/home/doug/python/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, line 1091: In the initializer for iso2022_jp_ext_config, an array's element t ype is incomplete, which precludes its initialization. (incompelinit) ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-20 02:55 Message: Logged In: YES user_id=55188 Fixed in CVS. Thanks for the tests and reporting! Modules/cjkcodecs/README 1.3 Modules/cjkcodecs/_codecs_hk.c 1.2 Modules/cjkcodecs/_codecs_iso2022.c 1.3 Modules/cjkcodecs/cjkcodecs.h 1.5 Modules/cjkcodecs/multibytecodec.c 1.3 Misc/NEWS 1.1106 ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-18 23:56 Message: Logged In: YES user_id=200117 Sorry for the confusion, but it doesn't compile on HP-UX with the last patch. My post of 2004-08-12 16:57 was just correcting a typo in the previous post. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-18 22:52 Message: Logged In: YES user_id=55188 Thanks for testing. Do you mean that it compiles on HP-UX with the current patch? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-13 00:57 Message: Logged In: YES user_id=200117 Oops! that was a fresh install of Python-2.4a2... ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-13 00:55 Message: Logged In: YES user_id=200117 I did a fresh install of Python-2.2a2 and applied your new patch, but I'm still getting compile errors for line 200: building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. Here are lines 198-203 after applying the patch #if Py_UNICODE_SIZE == 2 if (length == 2) { ucs4_t u4in [2] = {(ucs4_t)IN1, (ucs4_t)IN2}; encoded = dsg->encoder(u4in, &length); } else encoded = dsg->encoder(&c, &length); One of my collegues says that you can't initialise one variable with another variable, when using the cc compiler. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 22:03 Message: Logged In: YES user_id=55188 Thanks for testing! I uploaded new patch fixed the problem. Can you both test the patch whether it compiles? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-12 16:37 Message: Logged In: YES user_id=200117 After applying the patch I am still getting two comple errors on HP-UX 11i building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 07:14 Message: Logged In: YES user_id=55188 The attached patch converts C99 usages to plain legacy C. Can you please test it on HP-UX whether the problem is resolved? ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2004-08-09 17:15 Message: Logged In: YES user_id=200117 I am getting slightly different errors on HP-UX 11i using the native C compiler 'cc'. building '_codecs_iso2022' extension cc -Ae -DNDEBUG +O2 -z +Onofltacc +ESlit +Oentrysched +Odataprefetch +Onolimit +DA2.0 +Z -I. - I/home/richardt/python-24/Python-2.4a2/./Include - I/opt/python/include -I/usr/local/include - I/home/richardt/python-24/Python-2.4a2/Include - I/home/richardt/python-24/Python-2.4a2 - c /home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c -o build/temp.hp-ux-B.11.11-9000/785-2.4/_codecs_iso2022.o cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 120: error 1578: Size of struct or union member is unknown. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 200: error 1521: Incorrect initialization. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1058: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1064: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1070: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1078: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1085: error 1523: Too many initializers. cc: "/home/richardt/python-24/Python- 2.4a2/Modules/cjkcodecs/_codecs_iso2022.c", line 1091: error 1523: Too many initializers. uname -a HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user license ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-09 14:10 Message: Logged In: YES user_id=55188 It seems that I used C99 grammar in that lines. Sorry. I'll fix it for C89 compilers soon. Thank you for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005737&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:58:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:58:13 2004 Subject: [ python-Bugs-1007249 ] SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Message-ID: Bugs item #1007249, was opened at 2004-08-11 22:11 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Maik Hertha (mhertha) Assigned to: Hye-Shik Chang (perky) Summary: SGI (IRIX 6.5.24) Error building _codecs_iso2022.c Initial Comment: This bug report is similar to #1005737 only a different platform. MIPSpro Compilers: Version 7.3.1.3m Error message: --- start cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1028 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 200 The expression used must have a constant value. ucs4_t u4in[2] = {IN1, IN2}; ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1053 There are too many initializers for a declared aggregate. { REGISTRY_KSX1001, REGISTRY_SENTINEL }, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1058 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0201_R, REGISTRY_JISX0208_O, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1064 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1070 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_KSX1001, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1077 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2004_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1084 There are too many initializers for a declared aggregate. { REGISTRY_JISX0213_2000_1_PAIRONLY, REGISTRY_JISX0208, ^ cc-1142 cc: ERROR File = /usr2/src/lang/python/Python-2.4a2/Modules/cjkcodecs/_codecs_iso2022.c, Line = 1091 There are too many initializers for a declared aggregate. { REGISTRY_JISX0208, REGISTRY_JISX0212, REGISTRY_JISX0201_R, ^ --- end The manpage for cc describes the differences between gcc and mipspro: .... * The gcc compiler is more lax about accepting non-static initializers, extra parentheses, and the use of non-compile-time constants. The MIPSpro compilers adhere more closely to the ANSI standard. .... I found no compiler-option to solve this for the MipsPro compiler. Seems to be a hard work to solve this :-(. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-20 02:58 Message: Logged In: YES user_id=55188 I think the error should be fixed in CVS now. If you still have a problem to compile it, please give me another comment. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-12 22:05 Message: Logged In: YES user_id=55188 Would you test a patch attached in Bug #1005737? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1007249&group_id=5470 From noreply at sourceforge.net Thu Aug 19 19:59:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 19:59:41 2004 Subject: [ python-Bugs-991834 ] Warning in cjkcodecs/iso2022common.h Message-ID: Bugs item #991834, was opened at 2004-07-16 04:27 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991834&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Hye-Shik Chang (perky) Summary: Warning in cjkcodecs/iso2022common.h Initial Comment: I get a warning (MacOSX 10.3, gcc 3.3) in cjkcodecs/ iso2022common.h about an uninitialized variable, and it looks bona-fide: /Users/jack/src/python/Modules/cjkcodecs/codecentry.h: In function `iso2022processesc': /Users/jack/src/python/Modules/cjkcodecs/iso2022common.h:186: warning: `esclen' might be used uninitialized in this function ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-20 02:59 Message: Logged In: YES user_id=55188 The file has disappeared about a month ago. :) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-07-23 21:27 Message: Logged In: YES user_id=55188 iso2022common.h gone away by importing CJKCodecs 1.1. Do you have any warnings still there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991834&group_id=5470 From noreply at sourceforge.net Thu Aug 19 20:22:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 20:22:53 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-30 20:08 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-19 14:22 Message: Logged In: YES user_id=31435 I think the patch is still awaiting review. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 13:46 Message: Logged In: YES user_id=80475 Was this one fixed? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 04:04 Message: Logged In: YES user_id=1038590 New patch (#1007087) created with a test for this bug, as well as a fix for it (the fix simply removes the 'sequence of 1' shortcut). Checks for the unicode case as well, although unicode didn't have this bug (due to a different join implementation). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 03:00 Message: Logged In: YES user_id=1038590 Don't know about anyone else, but the shortcut in str.join that returns a reference to the *original* string in the case of a single item sequence strikes me as very bad ju-ju: >>> class mystr(str): pass ... >>> s1 = mystr('fred') >>> s1 'fred' >>> s1.mutable = 42 >>> s1.mutable 42 >>> s2 = ''.join([s1]) >>> s2.mutable 42 When I call join, I expect to get a *new* object back, not a reference to an old one (this is safe for standard strings, but not for subclasses which may have mutable state). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2004-08-07 18:17 Message: Logged In: YES user_id=34209 The point of the original bugreport is not that some operations return strings instead of subtypes. The point is that *one* operation *sometimes* returns subtypes. It's inconsistent and unexpected behaviour, and since you clearly don't write 'sep.join(seq)' for a common case of 'seq' being a single item, something you will only occasionally trigger. I don't have an emotional investment in this bug, it's just something that came up on #python. I also don't care which way it's fixed -- but treating the single-element-sequence case the same as the multiple-element-sequence seems logical to me. Regardless of how the multiple-element-sequence is handled exactly :) As for why I didn't write a patch myself, Michael, if I had time for that, I would've spent it writing a good decorator proposal >:-) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-08-07 11:48 Message: Logged In: YES user_id=7887 If this was considered a bug: >>> type(ms("a")+ms("b")) >>> type(ms("a")[:]) Are these bugs as well? I belive this is how the implementation was intended to be, even if not optimal for subclasses. I suggest closing this bug as invalid, and writing a PEP about the possible new subclass support change (for all classes), if there's enough interest. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-05 12:10 Message: Logged In: YES user_id=593130 Duh, my turn to forget. For any beginners reading this ... >>> class ms(str): pass ... >>> a=ms('a') >>> type(''.join((a,))) Expanding mhw's second point: >>> e=ms() >>> type(e) >>> import copy >>> e2=copy.copy(e) >>> type(e2) >>> e3=e[:] >>> type(e3) >>> id(e),id(e2),id(e3) (9494608, 9009936, 8577440) so [:] is not exactly an abbreviated synonym for copy(). Is this a butg? (I haven't rechecked the respective docs yet.) One reason I hesitate to call the OP's original observation a bug is that the whole sujbect of operations on subtype instances seems not completely baked. Knowing the result types in all cases may require experiments as well as doc reading. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 08:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-04 16:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 15:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 10:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Thu Aug 19 21:40:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 21:40:48 2004 Subject: [ python-Bugs-1012435 ] ctrl-left/-right works incorectly with diacritics Message-ID: Bugs item #1012435, was opened at 2004-08-19 21:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012435&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Krzysztof Wilkosz (sophros) Assigned to: Nobody/Anonymous (nobody) Summary: ctrl-left/-right works incorectly with diacritics Initial Comment: When left- or right-going in line with ctrl-arrow (left/right) I have encountered problems: example word with polish (cp1250) diacritics: zaż?łć (last 4 letters might be unreadable) this keybord shortcut stops each time diacritic letter is encountered, not at the end of the word. It is frustrating as I have many strings and comments in Polish. I thing it might work bad also in the case of any other non-ASCII letters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012435&group_id=5470 From noreply at sourceforge.net Thu Aug 19 23:13:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 23:13:49 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-31 10:08 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-20 07:13 Message: Logged In: YES user_id=1038590 I've just assigned the relevant patch to Tim for review. The latest version should address his concerns with the original fix (which didn't use the optimised path, even when it was safe). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-20 04:22 Message: Logged In: YES user_id=31435 I think the patch is still awaiting review. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-20 03:46 Message: Logged In: YES user_id=80475 Was this one fixed? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 18:04 Message: Logged In: YES user_id=1038590 New patch (#1007087) created with a test for this bug, as well as a fix for it (the fix simply removes the 'sequence of 1' shortcut). Checks for the unicode case as well, although unicode didn't have this bug (due to a different join implementation). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 17:00 Message: Logged In: YES user_id=1038590 Don't know about anyone else, but the shortcut in str.join that returns a reference to the *original* string in the case of a single item sequence strikes me as very bad ju-ju: >>> class mystr(str): pass ... >>> s1 = mystr('fred') >>> s1 'fred' >>> s1.mutable = 42 >>> s1.mutable 42 >>> s2 = ''.join([s1]) >>> s2.mutable 42 When I call join, I expect to get a *new* object back, not a reference to an old one (this is safe for standard strings, but not for subclasses which may have mutable state). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2004-08-08 08:17 Message: Logged In: YES user_id=34209 The point of the original bugreport is not that some operations return strings instead of subtypes. The point is that *one* operation *sometimes* returns subtypes. It's inconsistent and unexpected behaviour, and since you clearly don't write 'sep.join(seq)' for a common case of 'seq' being a single item, something you will only occasionally trigger. I don't have an emotional investment in this bug, it's just something that came up on #python. I also don't care which way it's fixed -- but treating the single-element-sequence case the same as the multiple-element-sequence seems logical to me. Regardless of how the multiple-element-sequence is handled exactly :) As for why I didn't write a patch myself, Michael, if I had time for that, I would've spent it writing a good decorator proposal >:-) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-08-08 01:48 Message: Logged In: YES user_id=7887 If this was considered a bug: >>> type(ms("a")+ms("b")) >>> type(ms("a")[:]) Are these bugs as well? I belive this is how the implementation was intended to be, even if not optimal for subclasses. I suggest closing this bug as invalid, and writing a PEP about the possible new subclass support change (for all classes), if there's enough interest. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-06 02:10 Message: Logged In: YES user_id=593130 Duh, my turn to forget. For any beginners reading this ... >>> class ms(str): pass ... >>> a=ms('a') >>> type(''.join((a,))) Expanding mhw's second point: >>> e=ms() >>> type(e) >>> import copy >>> e2=copy.copy(e) >>> type(e2) >>> e3=e[:] >>> type(e3) >>> id(e),id(e2),id(e3) (9494608, 9009936, 8577440) so [:] is not exactly an abbreviated synonym for copy(). Is this a butg? (I haven't rechecked the respective docs yet.) One reason I hesitate to call the OP's original observation a bug is that the whole sujbect of operations on subtype instances seems not completely baked. Knowing the result types in all cases may require experiments as well as doc reading. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 22:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-05 06:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-05 05:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-03 00:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Thu Aug 19 23:49:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 19 23:49:35 2004 Subject: [ python-Bugs-1012315 ] weakref.WeakValueDictionary should override .has_key() Message-ID: Bugs item #1012315, was opened at 2004-08-19 11:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012315&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Raymond Hettinger (rhettinger) Summary: weakref.WeakValueDictionary should override .has_key() Initial Comment: .has_key() currently does not return the correct info for a weakref.WeakValueDictionary. When you call it some times tells you that a key exists even tho the value is no longer in RAM. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 16:49 Message: Logged In: YES user_id=80475 I loaded a fix into Py2.4. See Lib/weakref.py 1.25 What was there before should have worked fine but it is possible that values were being deleted by GC or threads after the internal has_key check and the return. The patch goes a step further and checks a lookedup object for a None value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012315&group_id=5470 From noreply at sourceforge.net Fri Aug 20 04:32:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 04:32:46 2004 Subject: [ python-Bugs-1010777 ] test_queue fails occasionally Message-ID: Bugs item #1010777, was opened at 2004-08-17 10:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Tim Peters (tim_one) Summary: test_queue fails occasionally Initial Comment: I guess this is some kind of race condition. I see test_queue fail about 5% of the time (judged by running ./python ../Lib/test/regrtest.py test_queue test_queue test_queue test_queue ... with a couple of hundred test_queue's, but I've seen it fail as part of a more normal test run too). It's always this failure: test test_queue failed -- blocking function '>' appeared not to block and then, at least sometimes, you get this traceback: Exception in thread Thread-3408: Traceback (most recent call last): File "/home/mwh/src/python/dist/src/Lib/threading.py", line 442, in __bootstrap self.run() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 23, in run self.fn(*self.args) File "/home/mwh/src/python/dist/src/Lib/Queue.py", line 129, in get item = self._get() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 58, in _get return Queue.Queue._get(self) AttributeError: 'NoneType' object has no attribute 'Queue' somewhat later, usually while a subsequent test is running. This is a debug build from CVS as of an hour or so back on Redhat Linux 9 (so, in particular, with the NPTL threading libray, not LinuxThreads). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-19 22:32 Message: Logged In: YES user_id=31435 OK, it looks like your particular primary failure mode is inevitable at times. If I boost the sleep in _TriggerThread.run (), it fails every time, in the way you describe, on my box. The difficulty appears to be one of test design. _doBlockingTest believes that no block_func passed to it can possibly return while the queue remains blocked, but the failing test is passing it a block_func that returns via raising FailingQueueException regardless of whether the queue is blocked. So what we see is just the result of a thread race in the test. But as Freud said, insight does not imply a cure . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-17 22:43 Message: Logged In: YES user_id=31435 FYI, Guido and I first noticed that test_queue sometimes fails a few years ago. It's apparently much more likely to fail on a non-Windows box, perhaps because Windows is happy to switch threads frequently. I ran it for half an hour today on a WinXP box, and it didn't fail at all. IIRC, it's not easy to fix - - there are threads, and some of the coordination is done via time.sleep() calls. I'll leave this assigned to me for a few more days, but it's unlikely I'll find time to "do something" about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 From noreply at sourceforge.net Fri Aug 20 05:30:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 05:30:31 2004 Subject: [ python-Bugs-1010777 ] test_queue fails occasionally Message-ID: Bugs item #1010777, was opened at 2004-08-17 10:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: test_queue fails occasionally Initial Comment: I guess this is some kind of race condition. I see test_queue fail about 5% of the time (judged by running ./python ../Lib/test/regrtest.py test_queue test_queue test_queue test_queue ... with a couple of hundred test_queue's, but I've seen it fail as part of a more normal test run too). It's always this failure: test test_queue failed -- blocking function '>' appeared not to block and then, at least sometimes, you get this traceback: Exception in thread Thread-3408: Traceback (most recent call last): File "/home/mwh/src/python/dist/src/Lib/threading.py", line 442, in __bootstrap self.run() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 23, in run self.fn(*self.args) File "/home/mwh/src/python/dist/src/Lib/Queue.py", line 129, in get item = self._get() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 58, in _get return Queue.Queue._get(self) AttributeError: 'NoneType' object has no attribute 'Queue' somewhat later, usually while a subsequent test is running. This is a debug build from CVS as of an hour or so back on Redhat Linux 9 (so, in particular, with the NPTL threading libray, not LinuxThreads). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-19 23:30 Message: Logged In: YES user_id=31435 Michael, please give current CVS a try. I believe I truly fixed the test race at the heart of your specific primary problem, and greatly decreased the likelihood of two other broad classes of sporadic race-related failures in the test driver. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-19 22:32 Message: Logged In: YES user_id=31435 OK, it looks like your particular primary failure mode is inevitable at times. If I boost the sleep in _TriggerThread.run (), it fails every time, in the way you describe, on my box. The difficulty appears to be one of test design. _doBlockingTest believes that no block_func passed to it can possibly return while the queue remains blocked, but the failing test is passing it a block_func that returns via raising FailingQueueException regardless of whether the queue is blocked. So what we see is just the result of a thread race in the test. But as Freud said, insight does not imply a cure . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-17 22:43 Message: Logged In: YES user_id=31435 FYI, Guido and I first noticed that test_queue sometimes fails a few years ago. It's apparently much more likely to fail on a non-Windows box, perhaps because Windows is happy to switch threads frequently. I ran it for half an hour today on a WinXP box, and it didn't fail at all. IIRC, it's not easy to fix - - there are threads, and some of the coordination is done via time.sleep() calls. I'll leave this assigned to me for a few more days, but it's unlikely I'll find time to "do something" about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 From noreply at sourceforge.net Fri Aug 20 07:31:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 07:31:32 2004 Subject: [ python-Bugs-1012692 ] Can't pipe input to a python program Message-ID: Bugs item #1012692, was opened at 2004-08-20 00:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald L. Rivest (rivest) Assigned to: Nobody/Anonymous (nobody) Summary: Can't pipe input to a python program Initial Comment: Details in attached file. Basically, I want to be able (in Windows) to pipe input as in: type spam.txt | eggs.py so that eggs can read the file spam.txt. But I am getting an Errno 9: Bad file descriptor error message. Thanks. Cheers, Ron Rivest rivest@mit.edu [Please reply to rivest@mit.edu as well...] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 From noreply at sourceforge.net Fri Aug 20 09:24:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 09:24:27 2004 Subject: [ python-Bugs-1011893 ] Cannot import PKZIP 2.50 created ZIP file Message-ID: Bugs item #1011893, was opened at 2004-08-19 03:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011893&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dennis Chuah (dennis_cs_chuah) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot import PKZIP 2.50 created ZIP file Initial Comment: Python 2.3.2 Windows platform Python is unable to import modules in ZIP files created by the PKZIP command line tool, version 2.50. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 09:24 Message: Logged In: YES user_id=21627 Can you please attach a small sample ZIP file that demonstrates the problem? I don't have the PKZIP command line tool. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011893&group_id=5470 From noreply at sourceforge.net Fri Aug 20 09:26:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 09:26:57 2004 Subject: [ python-Bugs-1010952 ] running test_codecmaps_* takes too much effort Message-ID: Bugs item #1010952, was opened at 2004-08-17 21:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Hye-Shik Chang (perky) Summary: running test_codecmaps_* takes too much effort Initial Comment: The only way I've found to actually run the codecmap tests is by running it over and over again, downloading the missing files when a test complains in between, until the tests no longer complains. E.g $ make test - test_codecmap_jp complains about a missing file - download this file $ make test - test_codecmap_jp complains about another missing filie - ... Another problem: it is completely unclear where I should place the downloaded files. I've worked around this by placing the files in Lib/test and patching test_multibytecodec_support to look for the files in os.path.dirname(__file__): cvs diff: Diffing . Index: test_multibytecodec_support.py ========================================= ========================== RCS file: /cvsroot/python/python/dist/src/Lib/test/ test_multibytecodec_support.py,v retrieving revision 1.5 diff -r1.5 test_multibytecodec_support.py 165a166 > self.mapfilename = os.path.join(os.path.dirname(__file__), self.mapfilename) It would be nice if there were a document that described what should be done to run these tests, adding the required files to CVS would be fine too :-) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 09:26 Message: Logged In: YES user_id=21627 Adding the files to the CVS is unacceptable, because they would then end up in the distribution, and their size is considered unacceptable for distribution (let alone copyright issues with these files). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-17 21:19 Message: Logged In: YES user_id=580910 test_normalization suffers from a simular problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010952&group_id=5470 From noreply at sourceforge.net Fri Aug 20 09:34:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 09:34:09 2004 Subject: [ python-Bugs-1009803 ] xmlrpclib, PEP291, "yield" Message-ID: Bugs item #1009803, was opened at 2004-08-16 06:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib, PEP291, "yield" Initial Comment: PEP 291 says that xmlrpclib should be 1.5.2 compatible. This patch: revision 1.31 date: 2003/10/31 13:49:36; author: loewis; state: Exp; lines: +66 -2 Patch #531629: Add multicall support. however, introduced code with the 'yield' keyword. This is completely and utterly non-1.5.2 compatible. Either the PEP (and the comment in the file) should be updated, or the code should be rewritten to not use yield. Martin? You checked in the patch, what's your opinion? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 09:34 Message: Logged In: YES user_id=21627 After discussion with /F, I have now bumped the minimum supported version to 2.1; fixed in xmlrpclib.py 1.34 and pep-0291.txt 1.11. Fredrik still has 1.5.2 installations he needs to support, but thinks he can manage maintenance on xmlrpclib for these on his own. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 From noreply at sourceforge.net Fri Aug 20 09:43:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 09:43:35 2004 Subject: [ python-Bugs-1009803 ] xmlrpclib, PEP291, "yield" Message-ID: Bugs item #1009803, was opened at 2004-08-16 14:28 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 Category: Python Library Group: None >Status: Open >Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib, PEP291, "yield" Initial Comment: PEP 291 says that xmlrpclib should be 1.5.2 compatible. This patch: revision 1.31 date: 2003/10/31 13:49:36; author: loewis; state: Exp; lines: +66 -2 Patch #531629: Add multicall support. however, introduced code with the 'yield' keyword. This is completely and utterly non-1.5.2 compatible. Either the PEP (and the comment in the file) should be updated, or the code should be rewritten to not use yield. Martin? You checked in the patch, what's your opinion? ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-20 17:43 Message: Logged In: YES user_id=29957 The code, however, still has 'yield' in it, and is therefore _not_ 2.1 compatible. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 17:34 Message: Logged In: YES user_id=21627 After discussion with /F, I have now bumped the minimum supported version to 2.1; fixed in xmlrpclib.py 1.34 and pep-0291.txt 1.11. Fredrik still has 1.5.2 installations he needs to support, but thinks he can manage maintenance on xmlrpclib for these on his own. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 From noreply at sourceforge.net Fri Aug 20 12:05:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 12:05:40 2004 Subject: [ python-Bugs-1010098 ] CPU usage shoots up with asyncore Message-ID: Bugs item #1010098, was opened at 2004-08-16 15:54 Message generated for change (Comment added) made by thomasabc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Thomas (thomasabc) Assigned to: A.M. Kuchling (akuchling) Summary: CPU usage shoots up with asyncore Initial Comment: The CPU usage of a python application program using asyncore.py shoot up to 99% under Python 2.4a1. After a comparison, it was found out that the same program ran without such high CPU usage under Python 2.3.3 A simple couple of programs to narrow down the problem showed that a single loop() was accompanied by a large number of poll() with 2.4a1, whereas a single loop() had only 3 calls to poll() with 2.3.3. Please let me know if there is anything else I can do for you to analyse. A couple of python scripts are attached in a zip file for you as below: - Summary of the test scripts With these scripts, the test attempts to identify what function calls are called that might explain the high CPU usage observed. asyncore_test.py: Taken from the Python Library Reference 11.24.2 asynchat Example, the test program starts a server process to simulate client request process. http_test.py: This program simply establishes connection to the server and closes after 10 seconds. - Procedure 1. Start asyncore_test.py 2. Start http_test.py 3. Stop asyncore_test.py ---------------------------------------------------------------------- >Comment By: Thomas (thomasabc) Date: 2004-08-20 10:05 Message: Logged In: YES user_id=1104845 Sorry, just to let you know that you press Ctrl+C to stop the script above at Step 3 to get an output displayed as shown in the file asyncore_comparison.txt below. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 17:29 Message: Logged In: YES user_id=80475 Andrew, what this due to your updates or was Martin's loop counter the cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 From noreply at sourceforge.net Fri Aug 20 13:35:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 13:35:33 2004 Subject: [ python-Bugs-940578 ] glob.glob inconsistent about broken symlinks Message-ID: Bugs item #940578, was opened at 2004-04-23 12:07 Message generated for change (Comment added) made by cben You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: glob.glob inconsistent about broken symlinks Initial Comment: `glob.glob()` uses `os.listdir()`, which includes borken symlinks in the listing if the pattern contains shell metacharacters but uses `os.path.exists()` which is False for broken symlinks if the pattern is a fixed name. Thus: >>> os.symlink('broken', 'sym1') >>> os.symlink('broken', 'sym2') >>> import glob >>> glob.glob('sym*') ['sym1', 'sym2'] >>> glob.glob('sym1') [] >>> glob.glob('sym2') [] ---------------------------------------------------------------------- >Comment By: Cherniavsky Beni (cben) Date: 2004-08-20 14:35 Message: Logged In: YES user_id=36166 What do you mean? Patch 941486 is there a long time already. Commit it (choose between the minimal fix and the more proper introduction of `os.path.lexists()`) and it'll be fixed. Then you could add patch 943206 if you like ;-). And I've refreshed both to apply cleanly against current trunk. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 20:45 Message: Logged In: YES user_id=80475 Did you already fix this one? ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-04-24 23:32 Message: Logged In: YES user_id=36166 This bug exists in all versions of the module since its creation up to 2.4. The correct behaviour (judging by the shell's behaviour - that's the model for the module, isn't it), is to always include broken symlinks in the results. Several fixes for this bug are provided by patch 941486 (http://python.org/sf/941486). [They all include the testcase attached here.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 From noreply at sourceforge.net Fri Aug 20 14:36:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 14:36:49 2004 Subject: [ python-Bugs-1008295 ] logging.getLevelName returns a number Message-ID: Bugs item #1008295, was opened at 2004-08-12 21:56 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paulo Eduardo Neves (neves) Assigned to: Vinay Sajip (vsajip) Summary: logging.getLevelName returns a number Initial Comment: logging.getLevelName function doc says that it returns the "textual representation of logging level", but if the argument is already the level name, the log level integer is returned. It should return the argument. The problem is that if I add my own levels, and call LoggerInstance.log( levelName, message ), the formatter will save the level number in the log, insted of the desired level name. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-08-20 12:36 Message: Logged In: YES user_id=308438 This is not a bug, it's by design. Current CVS throws an exception if raiseExceptions is set and you pass anything other than an integer as the log level. The CVS documentation has also been updated to clarify that the level passed in is the integer rather than the level name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008295&group_id=5470 From noreply at sourceforge.net Fri Aug 20 14:41:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 14:41:20 2004 Subject: [ python-Bugs-1010777 ] test_queue fails occasionally Message-ID: Bugs item #1010777, was opened at 2004-08-17 15:54 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 Category: Threads Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: test_queue fails occasionally Initial Comment: I guess this is some kind of race condition. I see test_queue fail about 5% of the time (judged by running ./python ../Lib/test/regrtest.py test_queue test_queue test_queue test_queue ... with a couple of hundred test_queue's, but I've seen it fail as part of a more normal test run too). It's always this failure: test test_queue failed -- blocking function '>' appeared not to block and then, at least sometimes, you get this traceback: Exception in thread Thread-3408: Traceback (most recent call last): File "/home/mwh/src/python/dist/src/Lib/threading.py", line 442, in __bootstrap self.run() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 23, in run self.fn(*self.args) File "/home/mwh/src/python/dist/src/Lib/Queue.py", line 129, in get item = self._get() File "/home/mwh/src/python/dist/src/Lib/test/test_queue.py", line 58, in _get return Queue.Queue._get(self) AttributeError: 'NoneType' object has no attribute 'Queue' somewhat later, usually while a subsequent test is running. This is a debug build from CVS as of an hour or so back on Redhat Linux 9 (so, in particular, with the NPTL threading libray, not LinuxThreads). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-20 13:41 Message: Logged In: YES user_id=6656 That seems to have done the trick! At least, I've run test_queue a couple of hundred times with no failure, and I'd have expected ~10 or so before I updated. After reading the checkin comments: I suspect you guessed as much, but system load was not a factor here. Closing. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-20 04:30 Message: Logged In: YES user_id=31435 Michael, please give current CVS a try. I believe I truly fixed the test race at the heart of your specific primary problem, and greatly decreased the likelihood of two other broad classes of sporadic race-related failures in the test driver. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-20 03:32 Message: Logged In: YES user_id=31435 OK, it looks like your particular primary failure mode is inevitable at times. If I boost the sleep in _TriggerThread.run (), it fails every time, in the way you describe, on my box. The difficulty appears to be one of test design. _doBlockingTest believes that no block_func passed to it can possibly return while the queue remains blocked, but the failing test is passing it a block_func that returns via raising FailingQueueException regardless of whether the queue is blocked. So what we see is just the result of a thread race in the test. But as Freud said, insight does not imply a cure . ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-18 03:43 Message: Logged In: YES user_id=31435 FYI, Guido and I first noticed that test_queue sometimes fails a few years ago. It's apparently much more likely to fail on a non-Windows box, perhaps because Windows is happy to switch threads frequently. I ran it for half an hour today on a WinXP box, and it didn't fail at all. IIRC, it's not easy to fix - - there are threads, and some of the coordination is done via time.sleep() calls. I'll leave this assigned to me for a few more days, but it's unlikely I'll find time to "do something" about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010777&group_id=5470 From noreply at sourceforge.net Fri Aug 20 17:09:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 17:09:08 2004 Subject: [ python-Feature Requests-1012952 ] Standard exceptions are hostile to Unicode Message-ID: Feature Requests item #1012952, was opened at 2004-08-20 17:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1012952&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marius Gedminas (mgedmin) Assigned to: Nobody/Anonymous (nobody) Summary: Standard exceptions are hostile to Unicode Initial Comment: >>> e = ValueError(u"\u2639") >>> str(e) ... UnicodeEncodeError: 'ascii' codec can't encode character u'\u2639' in position 0: ordinal not in range(128) >>> unicode(e) ... UnicodeEncodeError: 'ascii' codec can't encode character u'\u2639' in position 0: ordinal not in range(128) Please add a __unicode__ method to Exception. I suggest the following semantics: class UnicodeAwareException(Exception): def __unicode__(self): return u" ".join(map(unicode, self.args)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1012952&group_id=5470 From noreply at sourceforge.net Fri Aug 20 17:39:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 17:39:54 2004 Subject: [ python-Bugs-940578 ] glob.glob inconsistent about broken symlinks Message-ID: Bugs item #940578, was opened at 2004-04-23 11:07 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: glob.glob inconsistent about broken symlinks Initial Comment: `glob.glob()` uses `os.listdir()`, which includes borken symlinks in the listing if the pattern contains shell metacharacters but uses `os.path.exists()` which is False for broken symlinks if the pattern is a fixed name. Thus: >>> os.symlink('broken', 'sym1') >>> os.symlink('broken', 'sym2') >>> import glob >>> glob.glob('sym*') ['sym1', 'sym2'] >>> glob.glob('sym1') [] >>> glob.glob('sym2') [] ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-20 17:39 Message: Logged In: YES user_id=469548 I think that question was directed at me (Raymond assigned the bug to me). Well, I didn't... yet. I've added a comment to #941486. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-08-20 13:35 Message: Logged In: YES user_id=36166 What do you mean? Patch 941486 is there a long time already. Commit it (choose between the minimal fix and the more proper introduction of `os.path.lexists()`) and it'll be fixed. Then you could add patch 943206 if you like ;-). And I've refreshed both to apply cleanly against current trunk. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 19:45 Message: Logged In: YES user_id=80475 Did you already fix this one? ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-04-24 22:32 Message: Logged In: YES user_id=36166 This bug exists in all versions of the module since its creation up to 2.4. The correct behaviour (judging by the shell's behaviour - that's the model for the module, isn't it), is to always include broken symlinks in the results. Several fixes for this bug are provided by patch 941486 (http://python.org/sf/941486). [They all include the testcase attached here.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 From noreply at sourceforge.net Fri Aug 20 19:26:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 19:26:43 2004 Subject: [ python-Bugs-832159 ] C++ extensions using SWIG and MinGW Message-ID: Bugs item #832159, was opened at 2003-10-28 22:27 Message generated for change (Comment added) made by furrykef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832159&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Allen Chan (alydar) Assigned to: Nobody/Anonymous (nobody) Summary: C++ extensions using SWIG and MinGW Initial Comment: Using the following three files: -- begin files ----- /* hello.cpp */ #include <stdio.h> void hello() { printf("hello world\n"); } ------------------ /* hello.i */ %module hello extern void hello(); ------------------ # setup.py import distutils from distutils.core import setup, Extension setup(name = "Hello World", version = "1.0", ext_modules = [Extension("_hello", ["hello.i","hello.cpp"])]) -- end files ------- executing the command: "python setup.py build_ext -cmingw32 --swig-cpp -f" creates the following output: -- begin output -- running build_ext building '_hello' extension swigging hello.i to hello_wrap.cpp ... [ snipped ] ... cc -mno-cygwin -shared -s build\temp.win32-2.3 \Release\hello_wrap.o build\temp.w in32-2.3\Release\hello.o build\temp.win32-2.3 \Release\_hello.def -LC:\p\Python23 \libs -LC:\p\Python23\PCBuild -lpython23 -o build\lib.win32-2.3\_hello.pyd error: command 'cc' failed: No such file or directory -- end output -- It appears that unixccompiler.py defaults compiler_cxx to use "cc" and then uses it for the linking, and cygwinccompiler.py does not override the compiler_cxx entry. If the self.set_executable() call in the __init__*( function of the Mingw32Compiler class also sets compiler_cxx to use "g++", then the extension build will work. ---------------------------------------------------------------------- Comment By: Kef Li Eric MARCVS X (furrykef) Date: 2004-08-20 12:26 Message: Logged In: YES user_id=536129 ARGH! This bug is still in Python 2.3.4 and should have been fixed A LONG TIME AGO! What am I supposed to do, have my users fix their distutils by hand? Sorry to be so gripy, but jeez. It tells you how to freaking fix it... ---------------------------------------------------------------------- Comment By: David Rushby (woodsplitter) Date: 2004-02-11 17:18 Message: Logged In: YES user_id=414645 I also encountered this bug while trying to build a C++ extension with no SWIG involved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832159&group_id=5470 From noreply at sourceforge.net Fri Aug 20 20:42:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 20:42:52 2004 Subject: [ python-Bugs-940578 ] glob.glob inconsistent about broken symlinks Message-ID: Bugs item #940578, was opened at 2004-04-23 04:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: glob.glob inconsistent about broken symlinks Initial Comment: `glob.glob()` uses `os.listdir()`, which includes borken symlinks in the listing if the pattern contains shell metacharacters but uses `os.path.exists()` which is False for broken symlinks if the pattern is a fixed name. Thus: >>> os.symlink('broken', 'sym1') >>> os.symlink('broken', 'sym2') >>> import glob >>> glob.glob('sym*') ['sym1', 'sym2'] >>> glob.glob('sym1') [] >>> glob.glob('sym2') [] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-20 13:42 Message: Logged In: YES user_id=80475 Sorry, my question was meant for Johannes who recently committed something symlink related. If his patch did not fix your issue, he is still the one who will need to review and apply the patch (I'm on Windows and don't have symlinks). ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-20 10:39 Message: Logged In: YES user_id=469548 I think that question was directed at me (Raymond assigned the bug to me). Well, I didn't... yet. I've added a comment to #941486. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-08-20 06:35 Message: Logged In: YES user_id=36166 What do you mean? Patch 941486 is there a long time already. Commit it (choose between the minimal fix and the more proper introduction of `os.path.lexists()`) and it'll be fixed. Then you could add patch 943206 if you like ;-). And I've refreshed both to apply cleanly against current trunk. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 12:45 Message: Logged In: YES user_id=80475 Did you already fix this one? ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-04-24 15:32 Message: Logged In: YES user_id=36166 This bug exists in all versions of the module since its creation up to 2.4. The correct behaviour (judging by the shell's behaviour - that's the model for the module, isn't it), is to always include broken symlinks in the results. Several fixes for this bug are provided by patch 941486 (http://python.org/sf/941486). [They all include the testcase attached here.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 From noreply at sourceforge.net Fri Aug 20 23:29:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 20 23:29:19 2004 Subject: [ python-Bugs-1009803 ] xmlrpclib, PEP291, "yield" Message-ID: Bugs item #1009803, was opened at 2004-08-16 06:28 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Martin v. L?wis (loewis) Summary: xmlrpclib, PEP291, "yield" Initial Comment: PEP 291 says that xmlrpclib should be 1.5.2 compatible. This patch: revision 1.31 date: 2003/10/31 13:49:36; author: loewis; state: Exp; lines: +66 -2 Patch #531629: Add multicall support. however, introduced code with the 'yield' keyword. This is completely and utterly non-1.5.2 compatible. Either the PEP (and the comment in the file) should be updated, or the code should be rewritten to not use yield. Martin? You checked in the patch, what's your opinion? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-20 09:43 Message: Logged In: YES user_id=29957 The code, however, still has 'yield' in it, and is therefore _not_ 2.1 compatible. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 09:34 Message: Logged In: YES user_id=21627 After discussion with /F, I have now bumped the minimum supported version to 2.1; fixed in xmlrpclib.py 1.34 and pep-0291.txt 1.11. Fredrik still has 1.5.2 installations he needs to support, but thinks he can manage maintenance on xmlrpclib for these on his own. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 From noreply at sourceforge.net Sat Aug 21 03:02:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 03:02:27 2004 Subject: [ python-Bugs-1012435 ] ctrl-left/-right works incorectly with diacritics Message-ID: Bugs item #1012435, was opened at 2004-08-19 15:40 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012435&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Krzysztof Wilkosz (sophros) >Assigned to: Kurt B. Kaiser (kbk) Summary: ctrl-left/-right works incorectly with diacritics Initial Comment: When left- or right-going in line with ctrl-arrow (left/right) I have encountered problems: example word with polish (cp1250) diacritics: zaż?łć (last 4 letters might be unreadable) this keybord shortcut stops each time diacritic letter is encountered, not at the end of the word. It is frustrating as I have many strings and comments in Polish. I thing it might work bad also in the case of any other non-ASCII letters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012435&group_id=5470 From noreply at sourceforge.net Sat Aug 21 04:29:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 04:29:16 2004 Subject: [ python-Bugs-1013239 ] Python Tutorial 3.1.4 List example Message-ID: Bugs item #1013239, was opened at 2004-08-20 21:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Elizibeth Thompson (elsiebeth) Assigned to: Nobody/Anonymous (nobody) Summary: Python Tutorial 3.1.4 List example Initial Comment: In chapter 3.1.4, there is an example of making and using a list. One of the examples is: >>> a = ['spam', 'eggs', 100, 1234] >>> a[1:-1] ['eggs', 100] I didn't type this into Python, but I think that it should be: >>> a[1:-1] ['eggs', 1234] Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 From noreply at sourceforge.net Sat Aug 21 04:32:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 04:32:59 2004 Subject: [ python-Bugs-1013239 ] Python Tutorial 3.1.4 List example Message-ID: Bugs item #1013239, was opened at 2004-08-20 21:29 Message generated for change (Settings changed) made by elsiebeth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Elizibeth Thompson (elsiebeth) Assigned to: Nobody/Anonymous (nobody) Summary: Python Tutorial 3.1.4 List example Initial Comment: In chapter 3.1.4, there is an example of making and using a list. One of the examples is: >>> a = ['spam', 'eggs', 100, 1234] >>> a[1:-1] ['eggs', 100] I didn't type this into Python, but I think that it should be: >>> a[1:-1] ['eggs', 1234] Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 From noreply at sourceforge.net Sat Aug 21 04:33:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 04:33:56 2004 Subject: [ python-Bugs-1013239 ] Python Tutorial 3.1.4 List example Message-ID: Bugs item #1013239, was opened at 2004-08-20 21:29 Message generated for change (Settings changed) made by elsiebeth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 >Category: Documentation Group: None Status: Open Resolution: None Priority: 1 Submitted By: Elizibeth Thompson (elsiebeth) Assigned to: Nobody/Anonymous (nobody) Summary: Python Tutorial 3.1.4 List example Initial Comment: In chapter 3.1.4, there is an example of making and using a list. One of the examples is: >>> a = ['spam', 'eggs', 100, 1234] >>> a[1:-1] ['eggs', 100] I didn't type this into Python, but I think that it should be: >>> a[1:-1] ['eggs', 1234] Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 From noreply at sourceforge.net Sat Aug 21 06:28:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 06:28:41 2004 Subject: [ python-Bugs-1013239 ] Python Tutorial 3.1.4 List example Message-ID: Bugs item #1013239, was opened at 2004-08-21 11:29 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Wont Fix Priority: 1 Submitted By: Elizibeth Thompson (elsiebeth) Assigned to: Nobody/Anonymous (nobody) Summary: Python Tutorial 3.1.4 List example Initial Comment: In chapter 3.1.4, there is an example of making and using a list. One of the examples is: >>> a = ['spam', 'eggs', 100, 1234] >>> a[1:-1] ['eggs', 100] I didn't type this into Python, but I think that it should be: >>> a[1:-1] ['eggs', 1234] Thanks. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-08-21 13:28 Message: Logged In: YES user_id=55188 No. ['eggs', 100] is correct. [1:-1] means not 1 and -1 but from 1 to -1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 From noreply at sourceforge.net Sat Aug 21 13:31:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 13:31:15 2004 Subject: [ python-Bugs-878453 ] optparse indents without respect to $COLUMNS Message-ID: Bugs item #878453, was opened at 2004-01-16 19:50 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878453&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 4 Submitted By: Ian Bicking (ianbicking) Assigned to: Greg Ward (gward) Summary: optparse indents without respect to $COLUMNS Initial Comment: optparse should pay attention to the $COLUMNS environmental variable if it is available. optparse.IndentedHelpFormatter.__init__ should take None as the default for width, and do something like: if width is None: width = os.environ.get('COLUMNS', 80) Better if it's put in HelpFormatter, so that IndentedHelpFormatter and TitledHelpFormatter both act the same. (Python 2.3.3, FreeBSD) ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-21 13:31 Message: Logged In: YES user_id=469548 Closing: seems like Greg's been hustling. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2004-07-24 22:23 Message: Logged In: YES user_id=14422 OK, just checked in a fix in the Optik CVS: lib/help.py rev 1.13 test/test_optik.py rev rev 1.29 Marking this bug fixed but still open, since it's not in Python's CVS yet. If I hustle, I should be able to get it into Python 2.4... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878453&group_id=5470 From noreply at sourceforge.net Sat Aug 21 17:05:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 17:05:08 2004 Subject: [ python-Bugs-1013418 ] Win XP DEP prevents Python call to 'C' DLL Message-ID: Bugs item #1013418, was opened at 2004-08-21 10:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ajhewitt (ajhewitt) Assigned to: Nobody/Anonymous (nobody) Summary: Win XP DEP prevents Python call to 'C' DLL Initial Comment: Following Mark Hammond's description in "Python Programming on Win32" I built his sample 'C' program, Hello.c which is called from Hellouse.py. The environment in which the DLL file was built is Visual Studio 2003 .NET and Windows XP SP2. When an attempt was made to run the example program hellouse.py, the program aborted with a "Data buffer overflow - program is corrupt" message from XP. I then moved the program files to Windows 2000 (just moved the library and python file) and the program executed correctly (as shown in Mark's book)! I then moved the program to a Windows XP SP1 based system and the program again executed as expected. I then poked around on the XP SP2 box and discovered a new "feature" called Data Execution Prevention. You can see this feature by right clicking on the "My Computer" icon and then clicking on "Properties" and "Advanced". I tried adding Python 2.3 (python and pythonw) to the exceptions list but that didn't help. I don't see any problem executing pure Python programs on the XP SP2 system. -Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 From noreply at sourceforge.net Sat Aug 21 17:09:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 17:09:26 2004 Subject: [ python-Bugs-1012692 ] Can't pipe input to a python program Message-ID: Bugs item #1012692, was opened at 2004-08-20 07:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald L. Rivest (rivest) Assigned to: Nobody/Anonymous (nobody) Summary: Can't pipe input to a python program Initial Comment: Details in attached file. Basically, I want to be able (in Windows) to pipe input as in: type spam.txt | eggs.py so that eggs can read the file spam.txt. But I am getting an Errno 9: Bad file descriptor error message. Thanks. Cheers, Ron Rivest rivest@mit.edu [Please reply to rivest@mit.edu as well...] ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 17:09 Message: Logged In: YES user_id=21627 What shell is this in? I cannot reproduce this in a cmd.exe window. However, that you report the version as "Windows 5.1 (Build 2600)" and not "Microsoft Windows XP [Version 5.1.2600]" (as ver.exe does), and that you use just ">" as the prompt suggests you might be using a different command interpreter. Can you please add print sys.stdin.fileno() into the script? On my system, it gives "0". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 From noreply at sourceforge.net Sat Aug 21 17:14:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 17:14:52 2004 Subject: [ python-Bugs-1005936 ] Index entries with "_" are wrong in pdf file Message-ID: Bugs item #1005936, was opened at 2004-08-09 08:41 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005936&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeff Epler (jepler) >Assigned to: Neal Norwitz (nnorwitz) Summary: Index entries with "_" are wrong in pdf file Initial Comment: "make pdf". Open lib.pdf in acrobat reader, or another pdf viewer with the "bookmarks" feature. Open the "Python Language Services" item. Section 18.8 (in CVS) will read "pyprotect unhbox voidb@x kern 0.6emvbox {hrule width.55em}compile --- Compile Python source files" It should read simply "py_compile --- Compile Python source files"---If you visit that section, that's the title shown. I only know enough LaTeX to get myself hurt, but it looks like "_" was converted into a special sequence, and the step that produces the index used the expanded version. It's a fix that would feel icky, but if this sequence "protect ....55em}" was the same everywhere, simply replacing that string with "_" when generating the index would probably get the right results. I first noticed this problem in dist.pdf where many of the module names contained underscores. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-21 11:14 Message: Logged In: YES user_id=33168 Checked in patch as: * Doc/texinputs/python.sty 1.110 * Misc/NEWS 1.1108 ---------------------------------------------------------------------- Comment By: Dave Watson (docwatson) Date: 2004-08-14 19:58 Message: Logged In: YES user_id=1094771 a patch has been submitted for this bug (#1009373) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-09 08:45 Message: Logged In: YES user_id=2772 This also affects older versions of the documentation, for instance the entries for __builtin__, __main__ and __future__ in Python-letter-2.3.4.zip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005936&group_id=5470 From noreply at sourceforge.net Sat Aug 21 17:25:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 17:25:21 2004 Subject: [ python-Bugs-1013418 ] Win XP DEP prevents Python call to 'C' DLL Message-ID: Bugs item #1013418, was opened at 2004-08-21 17:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ajhewitt (ajhewitt) Assigned to: Nobody/Anonymous (nobody) Summary: Win XP DEP prevents Python call to 'C' DLL Initial Comment: Following Mark Hammond's description in "Python Programming on Win32" I built his sample 'C' program, Hello.c which is called from Hellouse.py. The environment in which the DLL file was built is Visual Studio 2003 .NET and Windows XP SP2. When an attempt was made to run the example program hellouse.py, the program aborted with a "Data buffer overflow - program is corrupt" message from XP. I then moved the program files to Windows 2000 (just moved the library and python file) and the program executed correctly (as shown in Mark's book)! I then moved the program to a Windows XP SP1 based system and the program again executed as expected. I then poked around on the XP SP2 box and discovered a new "feature" called Data Execution Prevention. You can see this feature by right clicking on the "My Computer" icon and then clicking on "Properties" and "Advanced". I tried adding Python 2.3 (python and pythonw) to the exceptions list but that didn't help. I don't see any problem executing pure Python programs on the XP SP2 system. -Alex ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 17:25 Message: Logged In: YES user_id=21627 Do you want us to resolve the problem somehow? If so, please attach the sample code, so we can reproduce it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 From noreply at sourceforge.net Sat Aug 21 17:48:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 17:49:08 2004 Subject: [ python-Bugs-1009803 ] xmlrpclib, PEP291, "yield" Message-ID: Bugs item #1009803, was opened at 2004-08-16 13:28 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 7 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Martin v. L?wis (loewis) Summary: xmlrpclib, PEP291, "yield" Initial Comment: PEP 291 says that xmlrpclib should be 1.5.2 compatible. This patch: revision 1.31 date: 2003/10/31 13:49:36; author: loewis; state: Exp; lines: +66 -2 Patch #531629: Add multicall support. however, introduced code with the 'yield' keyword. This is completely and utterly non-1.5.2 compatible. Either the PEP (and the comment in the file) should be updated, or the code should be rewritten to not use yield. Martin? You checked in the patch, what's your opinion? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-08-22 00:48 Message: Logged In: YES user_id=671362 Should I close bug #842600 as a duplicate? (Although it was submitted last November.) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-20 16:43 Message: Logged In: YES user_id=29957 The code, however, still has 'yield' in it, and is therefore _not_ 2.1 compatible. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 16:34 Message: Logged In: YES user_id=21627 After discussion with /F, I have now bumped the minimum supported version to 2.1; fixed in xmlrpclib.py 1.34 and pep-0291.txt 1.11. Fredrik still has 1.5.2 installations he needs to support, but thinks he can manage maintenance on xmlrpclib for these on his own. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 From noreply at sourceforge.net Sat Aug 21 19:43:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 19:43:44 2004 Subject: [ python-Bugs-1012692 ] Can't pipe input to a python program Message-ID: Bugs item #1012692, was opened at 2004-08-20 00:31 Message generated for change (Comment added) made by rivest You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald L. Rivest (rivest) Assigned to: Nobody/Anonymous (nobody) Summary: Can't pipe input to a python program Initial Comment: Details in attached file. Basically, I want to be able (in Windows) to pipe input as in: type spam.txt | eggs.py so that eggs can read the file spam.txt. But I am getting an Errno 9: Bad file descriptor error message. Thanks. Cheers, Ron Rivest rivest@mit.edu [Please reply to rivest@mit.edu as well...] ---------------------------------------------------------------------- >Comment By: Ronald L. Rivest (rivest) Date: 2004-08-21 12:43 Message: Logged In: YES user_id=1090045 If I print out sys.stdin.fileno(), I get -1 . Ver.exe outputs: Microsoft Windows XP [Version 5.1.2600] This is indeed the standard command interpreter; I set the prompt envinronment variable to output just ">". Thanks... Ron Rivest ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 10:09 Message: Logged In: YES user_id=21627 What shell is this in? I cannot reproduce this in a cmd.exe window. However, that you report the version as "Windows 5.1 (Build 2600)" and not "Microsoft Windows XP [Version 5.1.2600]" (as ver.exe does), and that you use just ">" as the prompt suggests you might be using a different command interpreter. Can you please add print sys.stdin.fileno() into the script? On my system, it gives "0". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 From noreply at sourceforge.net Sat Aug 21 20:49:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 20:49:36 2004 Subject: [ python-Bugs-1012692 ] Can't pipe input to a python program Message-ID: Bugs item #1012692, was opened at 2004-08-20 01:31 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 Category: Windows >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Ronald L. Rivest (rivest) >Assigned to: Tim Peters (tim_one) Summary: Can't pipe input to a python program Initial Comment: Details in attached file. Basically, I want to be able (in Windows) to pipe input as in: type spam.txt | eggs.py so that eggs can read the file spam.txt. But I am getting an Errno 9: Bad file descriptor error message. Thanks. Cheers, Ron Rivest rivest@mit.edu [Please reply to rivest@mit.edu as well...] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-21 14:49 Message: Logged In: YES user_id=31435 I see the same on my Win XP Pro SP1 box, but I expected to. The problem is in cmd.exe (the native XP shell), and both MS shells (command.com and cmd.exe) have had multiple bugs with I/O redirection forever. This somewhat confused MS KB article describes the current state for cmd.exe systems, in part incorrectly: "STDIN/STDOUT Redirection May Not Work If Started from a File Association" http://support.microsoft.com/default.aspx?kbid=321788 It works fine if you change the "eggs.py" part of your command line to "python eggs.py", where "python" is some string that resolves to your Python executable, or even to a .bat script that runs python.exe explicitly. For example, I have a py.bat on my PATH, containing just \python23\python.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 and then type spam.txt | py eggs.py works fine. The point is that it doesn't work if Python gets started via .py *association*; any other way of getting Python started works fine. Since this has nothing to do with Python (same thing if you use, e.g., Perl), I'm closing this as 3rd Party, Won't Fix. BTW, the KB article above claims the problem was fixed in XP SP1. It does indeed appear to have been fixed for stdout redirection, but not for stdin. You could also use Cygwin on Windows, whose default bash shell has sane behavior in this respect. Martin, it's sure curious that it works for you! My ver output is also "Microsoft Windows XP [Version 5.1.2600]". Is that enough to distinguish Home from Pro versions? I have Pro here. What do you have? Is yours a German flavor of XP? I'll note that I get one more line of output than Ron reported (the first output line, about "a nonexistent pipe"): C:\Code\python\PCbuild>type tcap.txt | eggs.py The process tried to write to a nonexistent pipe. Traceback (most recent call last): File "C:\Code\python\PCbuild\eggs.py", line 4, in ? text = sys.stdin.read() IOError: [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Ronald L. Rivest (rivest) Date: 2004-08-21 13:43 Message: Logged In: YES user_id=1090045 If I print out sys.stdin.fileno(), I get -1 . Ver.exe outputs: Microsoft Windows XP [Version 5.1.2600] This is indeed the standard command interpreter; I set the prompt envinronment variable to output just ">". Thanks... Ron Rivest ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 11:09 Message: Logged In: YES user_id=21627 What shell is this in? I cannot reproduce this in a cmd.exe window. However, that you report the version as "Windows 5.1 (Build 2600)" and not "Microsoft Windows XP [Version 5.1.2600]" (as ver.exe does), and that you use just ">" as the prompt suggests you might be using a different command interpreter. Can you please add print sys.stdin.fileno() into the script? On my system, it gives "0". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 From noreply at sourceforge.net Sat Aug 21 21:08:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 21:08:20 2004 Subject: [ python-Bugs-1013418 ] Win XP DEP prevents Python call to 'C' DLL Message-ID: Bugs item #1013418, was opened at 2004-08-21 10:05 Message generated for change (Comment added) made by ajhewitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ajhewitt (ajhewitt) Assigned to: Nobody/Anonymous (nobody) Summary: Win XP DEP prevents Python call to 'C' DLL Initial Comment: Following Mark Hammond's description in "Python Programming on Win32" I built his sample 'C' program, Hello.c which is called from Hellouse.py. The environment in which the DLL file was built is Visual Studio 2003 .NET and Windows XP SP2. When an attempt was made to run the example program hellouse.py, the program aborted with a "Data buffer overflow - program is corrupt" message from XP. I then moved the program files to Windows 2000 (just moved the library and python file) and the program executed correctly (as shown in Mark's book)! I then moved the program to a Windows XP SP1 based system and the program again executed as expected. I then poked around on the XP SP2 box and discovered a new "feature" called Data Execution Prevention. You can see this feature by right clicking on the "My Computer" icon and then clicking on "Properties" and "Advanced". I tried adding Python 2.3 (python and pythonw) to the exceptions list but that didn't help. I don't see any problem executing pure Python programs on the XP SP2 system. -Alex ---------------------------------------------------------------------- >Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 14:08 Message: Logged In: YES user_id=1108513 The problem will definitely need to be resolved. I did find a workaround - disabling XP SP2's "Data Execution Prevention" by editing the boot.ini file and changing "noexecute:XXXX" to "execute". This will degrade XP's security but only to the extent that it was vulnerable prior to SP2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 10:25 Message: Logged In: YES user_id=21627 Do you want us to resolve the problem somehow? If so, please attach the sample code, so we can reproduce it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 From noreply at sourceforge.net Sat Aug 21 21:09:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 21:09:57 2004 Subject: [ python-Bugs-1013418 ] Win XP DEP prevents Python call to 'C' DLL Message-ID: Bugs item #1013418, was opened at 2004-08-21 10:05 Message generated for change (Comment added) made by ajhewitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ajhewitt (ajhewitt) Assigned to: Nobody/Anonymous (nobody) Summary: Win XP DEP prevents Python call to 'C' DLL Initial Comment: Following Mark Hammond's description in "Python Programming on Win32" I built his sample 'C' program, Hello.c which is called from Hellouse.py. The environment in which the DLL file was built is Visual Studio 2003 .NET and Windows XP SP2. When an attempt was made to run the example program hellouse.py, the program aborted with a "Data buffer overflow - program is corrupt" message from XP. I then moved the program files to Windows 2000 (just moved the library and python file) and the program executed correctly (as shown in Mark's book)! I then moved the program to a Windows XP SP1 based system and the program again executed as expected. I then poked around on the XP SP2 box and discovered a new "feature" called Data Execution Prevention. You can see this feature by right clicking on the "My Computer" icon and then clicking on "Properties" and "Advanced". I tried adding Python 2.3 (python and pythonw) to the exceptions list but that didn't help. I don't see any problem executing pure Python programs on the XP SP2 system. -Alex ---------------------------------------------------------------------- >Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 14:09 Message: Logged In: YES user_id=1108513 Here's the Python program that calls the 'C' function... -Alex ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 14:08 Message: Logged In: YES user_id=1108513 The problem will definitely need to be resolved. I did find a workaround - disabling XP SP2's "Data Execution Prevention" by editing the boot.ini file and changing "noexecute:XXXX" to "execute". This will degrade XP's security but only to the extent that it was vulnerable prior to SP2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 10:25 Message: Logged In: YES user_id=21627 Do you want us to resolve the problem somehow? If so, please attach the sample code, so we can reproduce it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 From noreply at sourceforge.net Sat Aug 21 21:50:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 21:50:32 2004 Subject: [ python-Bugs-1012692 ] Can't pipe input to a python program Message-ID: Bugs item #1012692, was opened at 2004-08-20 00:31 Message generated for change (Comment added) made by rivest You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 Category: Windows Group: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Ronald L. Rivest (rivest) Assigned to: Tim Peters (tim_one) Summary: Can't pipe input to a python program Initial Comment: Details in attached file. Basically, I want to be able (in Windows) to pipe input as in: type spam.txt | eggs.py so that eggs can read the file spam.txt. But I am getting an Errno 9: Bad file descriptor error message. Thanks. Cheers, Ron Rivest rivest@mit.edu [Please reply to rivest@mit.edu as well...] ---------------------------------------------------------------------- >Comment By: Ronald L. Rivest (rivest) Date: 2004-08-21 14:50 Message: Logged In: YES user_id=1090045 Thanks to tim_one! Your analysis of the situation does seem correct, and your proposed fix (to pipe to "python eggs.py" rather than just to "eggs.py") works fine! I agree that the "3rd Pary; Won't Fix" designation is appropriate. Thanks again! Cheers, Ronald L. Rivest ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-21 13:49 Message: Logged In: YES user_id=31435 I see the same on my Win XP Pro SP1 box, but I expected to. The problem is in cmd.exe (the native XP shell), and both MS shells (command.com and cmd.exe) have had multiple bugs with I/O redirection forever. This somewhat confused MS KB article describes the current state for cmd.exe systems, in part incorrectly: "STDIN/STDOUT Redirection May Not Work If Started from a File Association" http://support.microsoft.com/default.aspx?kbid=321788 It works fine if you change the "eggs.py" part of your command line to "python eggs.py", where "python" is some string that resolves to your Python executable, or even to a .bat script that runs python.exe explicitly. For example, I have a py.bat on my PATH, containing just \python23\python.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 and then type spam.txt | py eggs.py works fine. The point is that it doesn't work if Python gets started via .py *association*; any other way of getting Python started works fine. Since this has nothing to do with Python (same thing if you use, e.g., Perl), I'm closing this as 3rd Party, Won't Fix. BTW, the KB article above claims the problem was fixed in XP SP1. It does indeed appear to have been fixed for stdout redirection, but not for stdin. You could also use Cygwin on Windows, whose default bash shell has sane behavior in this respect. Martin, it's sure curious that it works for you! My ver output is also "Microsoft Windows XP [Version 5.1.2600]". Is that enough to distinguish Home from Pro versions? I have Pro here. What do you have? Is yours a German flavor of XP? I'll note that I get one more line of output than Ron reported (the first output line, about "a nonexistent pipe"): C:\Code\python\PCbuild>type tcap.txt | eggs.py The process tried to write to a nonexistent pipe. Traceback (most recent call last): File "C:\Code\python\PCbuild\eggs.py", line 4, in ? text = sys.stdin.read() IOError: [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Ronald L. Rivest (rivest) Date: 2004-08-21 12:43 Message: Logged In: YES user_id=1090045 If I print out sys.stdin.fileno(), I get -1 . Ver.exe outputs: Microsoft Windows XP [Version 5.1.2600] This is indeed the standard command interpreter; I set the prompt envinronment variable to output just ">". Thanks... Ron Rivest ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 10:09 Message: Logged In: YES user_id=21627 What shell is this in? I cannot reproduce this in a cmd.exe window. However, that you report the version as "Windows 5.1 (Build 2600)" and not "Microsoft Windows XP [Version 5.1.2600]" (as ver.exe does), and that you use just ">" as the prompt suggests you might be using a different command interpreter. Can you please add print sys.stdin.fileno() into the script? On my system, it gives "0". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 From noreply at sourceforge.net Sat Aug 21 22:03:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 22:03:43 2004 Subject: [ python-Bugs-1013239 ] Python Tutorial 3.1.4 List example Message-ID: Bugs item #1013239, was opened at 2004-08-20 21:29 Message generated for change (Comment added) made by elsiebeth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 Category: Documentation Group: None Status: Closed Resolution: Wont Fix Priority: 1 Submitted By: Elizibeth Thompson (elsiebeth) Assigned to: Nobody/Anonymous (nobody) Summary: Python Tutorial 3.1.4 List example Initial Comment: In chapter 3.1.4, there is an example of making and using a list. One of the examples is: >>> a = ['spam', 'eggs', 100, 1234] >>> a[1:-1] ['eggs', 100] I didn't type this into Python, but I think that it should be: >>> a[1:-1] ['eggs', 1234] Thanks. ---------------------------------------------------------------------- >Comment By: Elizibeth Thompson (elsiebeth) Date: 2004-08-21 15:03 Message: Logged In: YES user_id=914980 Sorry 'bout that. :) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-08-20 23:28 Message: Logged In: YES user_id=55188 No. ['eggs', 100] is correct. [1:-1] means not 1 and -1 but from 1 to -1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013239&group_id=5470 From noreply at sourceforge.net Sat Aug 21 22:22:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 21 22:22:27 2004 Subject: [ python-Bugs-1013525 ] xml.dom documentation omits createDocument, ...DocumentType Message-ID: Bugs item #1013525, was opened at 2004-08-21 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013525&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: xml.dom documentation omits createDocument, ...DocumentType Initial Comment: http://www.python.org/doc/2.3.4/lib/dom- implementation-objects.html mentions that DOM L2 Core methods exist on DomImplementation objects to create Document and DocumentType objects, but does not say what the methods are, nor does it adequately document the one method that is documented: hasFeature(). The documentation should be updated to say what hasFeature does with its arguments and what it returns. Documentation for the createDocument() and createDocumentType() methods should be added to this page as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013525&group_id=5470 From noreply at sourceforge.net Sun Aug 22 01:01:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 01:01:14 2004 Subject: [ python-Bugs-1010098 ] CPU usage shoots up with asyncore Message-ID: Bugs item #1010098, was opened at 2004-08-16 11:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Thomas (thomasabc) Assigned to: A.M. Kuchling (akuchling) Summary: CPU usage shoots up with asyncore Initial Comment: The CPU usage of a python application program using asyncore.py shoot up to 99% under Python 2.4a1. After a comparison, it was found out that the same program ran without such high CPU usage under Python 2.3.3 A simple couple of programs to narrow down the problem showed that a single loop() was accompanied by a large number of poll() with 2.4a1, whereas a single loop() had only 3 calls to poll() with 2.3.3. Please let me know if there is anything else I can do for you to analyse. A couple of python scripts are attached in a zip file for you as below: - Summary of the test scripts With these scripts, the test attempts to identify what function calls are called that might explain the high CPU usage observed. asyncore_test.py: Taken from the Python Library Reference 11.24.2 asynchat Example, the test program starts a server process to simulate client request process. http_test.py: This program simply establishes connection to the server and closes after 10 seconds. - Procedure 1. Start asyncore_test.py 2. Start http_test.py 3. Stop asyncore_test.py ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-21 19:01 Message: Logged In: YES user_id=31435 I can confirm the primary symptom on WinXP. For the 10 seconds http_test.py runs, CPU is nailed to the wall under current CVS Python, but is a trickle under 2.3.4. asyncore appears to be irrelevant. "The problem" is that the socket associated with __main__.http_request_handler always comes back in the w set from select.select() under current Python, but the select times out under 2.3.4. More detail: under current Python, dumping some prints in asyncore.poll() delivers a huge number of repetitions of this info: socket map is {1940: <__main__.http_request_handler connected 127.0.0.1:3455 at 0x9da800>, 1948: <__main__.AsyncHTTPServer listening :40004 at 0x9d7fa8>} r, w, e passed in is [1940, 1948] [1940, 1948] [1940, 1948] r, w, e returned is [], [1940], [] Under 2.3.4, there are only a few lines of output total -- select() doesn't believe the sockets passed to it are ready to read or ready to write. So the difference is in socket behavior, or in how the layers around asyncore here are using sockets. ---------------------------------------------------------------------- Comment By: Thomas (thomasabc) Date: 2004-08-20 06:05 Message: Logged In: YES user_id=1104845 Sorry, just to let you know that you press Ctrl+C to stop the script above at Step 3 to get an output displayed as shown in the file asyncore_comparison.txt below. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 13:29 Message: Logged In: YES user_id=80475 Andrew, what this due to your updates or was Martin's loop counter the cause? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010098&group_id=5470 From noreply at sourceforge.net Sun Aug 22 03:08:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 03:08:37 2004 Subject: [ python-Bugs-944119 ] Signal reception problem. FreeBSD 4.8 and 4.9 after forkpty Message-ID: Bugs item #944119, was opened at 2004-04-29 11:05 Message generated for change (Comment added) made by lukem You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944119&group_id=5470 Category: None Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Steve Levis (levis501) Assigned to: Nobody/Anonymous (nobody) Summary: Signal reception problem. FreeBSD 4.8 and 4.9 after forkpty Initial Comment: The attached python file reproduces a bug whereby Python does not receive alarm signals from FreeBSD 4.9. This also appears to be the case in FreeBSD 4.8, and may be related to the addition of HyperThreading in FreeBSD 4.8. If Python (either 2.2.3 or 2.3.3) is configured with -?without-threads before compiling, the bug does not exist. ---------------------------------------------------------------------- Comment By: Luke Mewburn (lukem) Date: 2004-08-22 11:08 Message: Logged In: YES user_id=135998 Please try the patch I provided in patch 975056; it fixes up various signal lossage on NetBSD & FreeBSD caused by python's intermixed use of signal(3) and sigaction(3). python wants non-SA_RESTART-able signals, yet signal(3) on *BSD traditionally sets SA_RESTART, and the mechanism that python uses to unset SA_RESTART when using sigaction(3) is flawed. It's quite possible that the os.read() non-interruptability you're noticing on FreeBSD is being caused by this issue. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-05-23 17:58 Message: Logged In: YES user_id=250749 There are a few things I haven't been able to figure out with this problem, but I think this is what's going on: - on FreeBSD the read(2) call is not interruptable, as ptys appear not to be considered "slow devices" by the kernel (whether this behavior is *BSD specific I don't really know; ordinary files and pipes aresimilarly affected so forkpty() is just the messenger here); - Python's signal handling is documented to behave such that signal handlers only get invoked between Python VM opcodes. As the os.read() call is a single VM instruction, the nett effect is that the signal handler will not execute until the os.read() call/instruction completes... which it never does. This also affects other signals, such as SIGINT :-( The signal handler being invoked between opcodes explains why the C version works and the Python version doesn't. Using select.select() (or select.poll()) is one way of avoiding this trap, as both select(2) and poll(2) are interruptable (in addition to supporting timeouts directly). I expect this approach would also be considered to be generally portable. I haven't dug into why a single-threaded build avoids the Python VM opcode scheduling - I can only speculate that because the VM doesn't have any thread locking, it can actually execute the signal handler while the os.read() call is still pending. I don't expect there to be a practical solution to this, and so I'm suggesting that the bug be closed as "Won't fix" (read "Can't fix"). ---------------------------------------------------------------------- Comment By: Steve Levis (levis501) Date: 2004-05-19 05:55 Message: Logged In: YES user_id=309698 I've uploaded failure_demo.c, which can be compiled with gcc -o failure_demo failure_demo.c -lutil. Written in C, the signal is properly delivered, and the test does not fail on either FreeBSD 4.7 or 4.9. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-05-18 19:05 Message: Logged In: YES user_id=250749 Hmm... are you in a position to write a C test case for this? The reason I ask is that I have seen other signal related problems involving a Python interpreter built --with-threads on FreeBSD 4.x which were traced back to issues with libc_r, and I suspect that this problem is similar. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-05-18 19:03 Message: Logged In: YES user_id=250749 Hmm... are you in a position to write a C test case for this? The reason I ask is that I have seen other signal related problems involving a Python interpreter built --with-threads on FreeBSD 4.x which were traced back to issues with libc_r, and I suspect that this problem is similar. ---------------------------------------------------------------------- Comment By: Steve Levis (levis501) Date: 2004-05-06 03:08 Message: Logged In: YES user_id=309698 Ooops, again! I ran on the standard kernel but had python compiled --without-threads, so of course it worked. So, to make a long story short, the bug exists -- ignore my last post. ---------------------------------------------------------------------- Comment By: Steve Levis (levis501) Date: 2004-05-06 02:59 Message: Logged In: YES user_id=309698 I was apparently not running on a standard FreeBSD kernel. It's working now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944119&group_id=5470 From noreply at sourceforge.net Sun Aug 22 08:55:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 08:55:58 2004 Subject: [ python-Bugs-1012692 ] Can't pipe input to a python program Message-ID: Bugs item #1012692, was opened at 2004-08-20 07:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 Category: Windows Group: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Ronald L. Rivest (rivest) Assigned to: Tim Peters (tim_one) Summary: Can't pipe input to a python program Initial Comment: Details in attached file. Basically, I want to be able (in Windows) to pipe input as in: type spam.txt | eggs.py so that eggs can read the file spam.txt. But I am getting an Errno 9: Bad file descriptor error message. Thanks. Cheers, Ron Rivest rivest@mit.edu [Please reply to rivest@mit.edu as well...] ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 08:55 Message: Logged In: YES user_id=21627 It worked for me since I didn't reproduce Ron's actions precisely :-( I automatically did type spam.txt | \python23\python.exe eggs.py since on that system, I had deleted the .py extension, so merely typing "eggs.py" wouldn't have worked, anyway... ---------------------------------------------------------------------- Comment By: Ronald L. Rivest (rivest) Date: 2004-08-21 21:50 Message: Logged In: YES user_id=1090045 Thanks to tim_one! Your analysis of the situation does seem correct, and your proposed fix (to pipe to "python eggs.py" rather than just to "eggs.py") works fine! I agree that the "3rd Pary; Won't Fix" designation is appropriate. Thanks again! Cheers, Ronald L. Rivest ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-21 20:49 Message: Logged In: YES user_id=31435 I see the same on my Win XP Pro SP1 box, but I expected to. The problem is in cmd.exe (the native XP shell), and both MS shells (command.com and cmd.exe) have had multiple bugs with I/O redirection forever. This somewhat confused MS KB article describes the current state for cmd.exe systems, in part incorrectly: "STDIN/STDOUT Redirection May Not Work If Started from a File Association" http://support.microsoft.com/default.aspx?kbid=321788 It works fine if you change the "eggs.py" part of your command line to "python eggs.py", where "python" is some string that resolves to your Python executable, or even to a .bat script that runs python.exe explicitly. For example, I have a py.bat on my PATH, containing just \python23\python.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 and then type spam.txt | py eggs.py works fine. The point is that it doesn't work if Python gets started via .py *association*; any other way of getting Python started works fine. Since this has nothing to do with Python (same thing if you use, e.g., Perl), I'm closing this as 3rd Party, Won't Fix. BTW, the KB article above claims the problem was fixed in XP SP1. It does indeed appear to have been fixed for stdout redirection, but not for stdin. You could also use Cygwin on Windows, whose default bash shell has sane behavior in this respect. Martin, it's sure curious that it works for you! My ver output is also "Microsoft Windows XP [Version 5.1.2600]". Is that enough to distinguish Home from Pro versions? I have Pro here. What do you have? Is yours a German flavor of XP? I'll note that I get one more line of output than Ron reported (the first output line, about "a nonexistent pipe"): C:\Code\python\PCbuild>type tcap.txt | eggs.py The process tried to write to a nonexistent pipe. Traceback (most recent call last): File "C:\Code\python\PCbuild\eggs.py", line 4, in ? text = sys.stdin.read() IOError: [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Ronald L. Rivest (rivest) Date: 2004-08-21 19:43 Message: Logged In: YES user_id=1090045 If I print out sys.stdin.fileno(), I get -1 . Ver.exe outputs: Microsoft Windows XP [Version 5.1.2600] This is indeed the standard command interpreter; I set the prompt envinronment variable to output just ">". Thanks... Ron Rivest ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 17:09 Message: Logged In: YES user_id=21627 What shell is this in? I cannot reproduce this in a cmd.exe window. However, that you report the version as "Windows 5.1 (Build 2600)" and not "Microsoft Windows XP [Version 5.1.2600]" (as ver.exe does), and that you use just ">" as the prompt suggests you might be using a different command interpreter. Can you please add print sys.stdin.fileno() into the script? On my system, it gives "0". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 From noreply at sourceforge.net Sun Aug 22 09:06:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 09:06:54 2004 Subject: [ python-Bugs-1013418 ] Win XP DEP prevents Python call to 'C' DLL Message-ID: Bugs item #1013418, was opened at 2004-08-21 17:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ajhewitt (ajhewitt) Assigned to: Nobody/Anonymous (nobody) Summary: Win XP DEP prevents Python call to 'C' DLL Initial Comment: Following Mark Hammond's description in "Python Programming on Win32" I built his sample 'C' program, Hello.c which is called from Hellouse.py. The environment in which the DLL file was built is Visual Studio 2003 .NET and Windows XP SP2. When an attempt was made to run the example program hellouse.py, the program aborted with a "Data buffer overflow - program is corrupt" message from XP. I then moved the program files to Windows 2000 (just moved the library and python file) and the program executed correctly (as shown in Mark's book)! I then moved the program to a Windows XP SP1 based system and the program again executed as expected. I then poked around on the XP SP2 box and discovered a new "feature" called Data Execution Prevention. You can see this feature by right clicking on the "My Computer" icon and then clicking on "Properties" and "Advanced". I tried adding Python 2.3 (python and pythonw) to the exceptions list but that didn't help. I don't see any problem executing pure Python programs on the XP SP2 system. -Alex ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 09:06 Message: Logged In: YES user_id=21627 Thanks. I cannot reproduce this at the moment (and I'm uncertain whether reproducing it requires an Athlon 64/Opteron processor), however, mere code inspection shows a potential problem of data buffer overflows. In the message function, you have char result[64]; so this can accommodate 64 characters. If the string you are passing is too long, the buffer will overflow, which might happen when you pass the string "module " + hello.__file__. As a quick work-around, please try to increase the result size to, say, char result[10000]; and see whether that makes the problem go away. If so, then a) this is a proper bug, and XP has helped to find it, and b) it is not a bug in Python, but in your code, and c) the proper solution is to either use a variable-sized buffer instead of a fixed-size one, or to check whether the buffer is large enough before copying into it. ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 21:09 Message: Logged In: YES user_id=1108513 Here's the Python program that calls the 'C' function... -Alex ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 21:08 Message: Logged In: YES user_id=1108513 The problem will definitely need to be resolved. I did find a workaround - disabling XP SP2's "Data Execution Prevention" by editing the boot.ini file and changing "noexecute:XXXX" to "execute". This will degrade XP's security but only to the extent that it was vulnerable prior to SP2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 17:25 Message: Logged In: YES user_id=21627 Do you want us to resolve the problem somehow? If so, please attach the sample code, so we can reproduce it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 From noreply at sourceforge.net Sun Aug 22 09:10:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 09:10:44 2004 Subject: [ python-Bugs-842600 ] xmlrpclib and backward compatibility Message-ID: Bugs item #842600, was opened at 2003-11-15 05:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842600&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib and backward compatibility Initial Comment: This bug is related to patch #531629 "Add multicall support to xmlrpclib" http://www.python.org/sf/531629 His applied patch includes 'yield' statement. Is this OK? I think xmlrpclib.py needs to keep compatible with older Python. On the top of xmlrpclib.py there is a note: # this version is designed to work with Python 1.5.2 or newer. I attached a patch to avoid 'yield' but this is a quick fix. I'm not sure if this is the right approach. There should be a better solution. I've also changed the coding style of the previous change to be consistent with other parts of this script. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 09:10 Message: Logged In: YES user_id=21627 Closed as a duplicate of #1009803. The patch attached really doesn't work, as it raises the exceptions out of order. I'm working on a proper patch to restore 2.1 compatbility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-19 20:43 Message: Logged In: YES user_id=21627 Assigning to Fredrik, as he is listed as the maintainer in PEP 291. My proposal would be to drop xmlrpclib from PEP 291, and closing this report as "Won't fix". I don't see the need for this backwards compatibility. Fredrik, if you consider compatibility with 1.5.2 still desirable, please indicate so, and assign it back to me so I can fix the new feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842600&group_id=5470 From noreply at sourceforge.net Sun Aug 22 09:18:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 09:18:30 2004 Subject: [ python-Bugs-1012692 ] Can't pipe input to a python program Message-ID: Bugs item #1012692, was opened at 2004-08-20 01:31 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 Category: Windows Group: 3rd Party Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Ronald L. Rivest (rivest) Assigned to: Tim Peters (tim_one) Summary: Can't pipe input to a python program Initial Comment: Details in attached file. Basically, I want to be able (in Windows) to pipe input as in: type spam.txt | eggs.py so that eggs can read the file spam.txt. But I am getting an Errno 9: Bad file descriptor error message. Thanks. Cheers, Ron Rivest rivest@mit.edu [Please reply to rivest@mit.edu as well...] ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-22 03:18 Message: Logged In: YES user_id=31435 Ah, that would explain it . It's still curious that the KB article specifically lists the bug as being in XP Pro, but doesn't mention XP home. Then again, there are several inaccuracies in that article ... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 02:55 Message: Logged In: YES user_id=21627 It worked for me since I didn't reproduce Ron's actions precisely :-( I automatically did type spam.txt | \python23\python.exe eggs.py since on that system, I had deleted the .py extension, so merely typing "eggs.py" wouldn't have worked, anyway... ---------------------------------------------------------------------- Comment By: Ronald L. Rivest (rivest) Date: 2004-08-21 15:50 Message: Logged In: YES user_id=1090045 Thanks to tim_one! Your analysis of the situation does seem correct, and your proposed fix (to pipe to "python eggs.py" rather than just to "eggs.py") works fine! I agree that the "3rd Pary; Won't Fix" designation is appropriate. Thanks again! Cheers, Ronald L. Rivest ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-21 14:49 Message: Logged In: YES user_id=31435 I see the same on my Win XP Pro SP1 box, but I expected to. The problem is in cmd.exe (the native XP shell), and both MS shells (command.com and cmd.exe) have had multiple bugs with I/O redirection forever. This somewhat confused MS KB article describes the current state for cmd.exe systems, in part incorrectly: "STDIN/STDOUT Redirection May Not Work If Started from a File Association" http://support.microsoft.com/default.aspx?kbid=321788 It works fine if you change the "eggs.py" part of your command line to "python eggs.py", where "python" is some string that resolves to your Python executable, or even to a .bat script that runs python.exe explicitly. For example, I have a py.bat on my PATH, containing just \python23\python.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 and then type spam.txt | py eggs.py works fine. The point is that it doesn't work if Python gets started via .py *association*; any other way of getting Python started works fine. Since this has nothing to do with Python (same thing if you use, e.g., Perl), I'm closing this as 3rd Party, Won't Fix. BTW, the KB article above claims the problem was fixed in XP SP1. It does indeed appear to have been fixed for stdout redirection, but not for stdin. You could also use Cygwin on Windows, whose default bash shell has sane behavior in this respect. Martin, it's sure curious that it works for you! My ver output is also "Microsoft Windows XP [Version 5.1.2600]". Is that enough to distinguish Home from Pro versions? I have Pro here. What do you have? Is yours a German flavor of XP? I'll note that I get one more line of output than Ron reported (the first output line, about "a nonexistent pipe"): C:\Code\python\PCbuild>type tcap.txt | eggs.py The process tried to write to a nonexistent pipe. Traceback (most recent call last): File "C:\Code\python\PCbuild\eggs.py", line 4, in ? text = sys.stdin.read() IOError: [Errno 9] Bad file descriptor ---------------------------------------------------------------------- Comment By: Ronald L. Rivest (rivest) Date: 2004-08-21 13:43 Message: Logged In: YES user_id=1090045 If I print out sys.stdin.fileno(), I get -1 . Ver.exe outputs: Microsoft Windows XP [Version 5.1.2600] This is indeed the standard command interpreter; I set the prompt envinronment variable to output just ">". Thanks... Ron Rivest ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 11:09 Message: Logged In: YES user_id=21627 What shell is this in? I cannot reproduce this in a cmd.exe window. However, that you report the version as "Windows 5.1 (Build 2600)" and not "Microsoft Windows XP [Version 5.1.2600]" (as ver.exe does), and that you use just ">" as the prompt suggests you might be using a different command interpreter. Can you please add print sys.stdin.fileno() into the script? On my system, it gives "0". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012692&group_id=5470 From noreply at sourceforge.net Sun Aug 22 13:46:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 13:46:34 2004 Subject: [ python-Bugs-1013760 ] Error in Chapter 4 of Tutorial Message-ID: Bugs item #1013760, was opened at 2004-08-22 15:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013760&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alexey Peshehonov (frodnix) Assigned to: Nobody/Anonymous (nobody) Summary: Error in Chapter 4 of Tutorial Initial Comment: Your sample is >>> fib while in reality it prints >>> fib ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013760&group_id=5470 From noreply at sourceforge.net Sun Aug 22 16:10:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 16:10:52 2004 Subject: [ python-Bugs-1013800 ] No documentation for PyFunction_* (C-Api) Message-ID: Bugs item #1013800, was opened at 2004-08-22 16:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013800&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Henning G?nther (der_eq) Assigned to: Nobody/Anonymous (nobody) Summary: No documentation for PyFunction_* (C-Api) Initial Comment: I'm missing documentation for the PyFunction_* api-calls. They don't appear in the documentation but in http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Objects/funcobject.c?rev=2.66&view=log ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013800&group_id=5470 From noreply at sourceforge.net Sun Aug 22 16:52:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 16:52:26 2004 Subject: [ python-Bugs-818315 ] Shared object modules in Windows have no __file__. Message-ID: Bugs item #818315, was opened at 2003-10-05 17:44 Message generated for change (Settings changed) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818315&group_id=5470 >Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Shared object modules in Windows have no __file__. Initial Comment: The subject basically says it. Whether it's math.so, operator.so, anything -- in *nix it has an __file__, in Windows it doesn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818315&group_id=5470 From noreply at sourceforge.net Sun Aug 22 17:28:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 17:28:20 2004 Subject: [ python-Bugs-1013760 ] Error in Chapter 4 of Tutorial Message-ID: Bugs item #1013760, was opened at 2004-08-22 06:46 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013760&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alexey Peshehonov (frodnix) Assigned to: Nobody/Anonymous (nobody) Summary: Error in Chapter 4 of Tutorial Initial Comment: Your sample is >>> fib while in reality it prints >>> fib ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-22 10:28 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013760&group_id=5470 From noreply at sourceforge.net Sun Aug 22 18:05:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 18:05:46 2004 Subject: [ python-Bugs-1009803 ] xmlrpclib, PEP291, "yield" Message-ID: Bugs item #1009803, was opened at 2004-08-16 06:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Martin v. L?wis (loewis) Summary: xmlrpclib, PEP291, "yield" Initial Comment: PEP 291 says that xmlrpclib should be 1.5.2 compatible. This patch: revision 1.31 date: 2003/10/31 13:49:36; author: loewis; state: Exp; lines: +66 -2 Patch #531629: Add multicall support. however, introduced code with the 'yield' keyword. This is completely and utterly non-1.5.2 compatible. Either the PEP (and the comment in the file) should be updated, or the code should be rewritten to not use yield. Martin? You checked in the patch, what's your opinion? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 18:05 Message: Logged In: YES user_id=21627 This is now fixed in xmlrpclib.py 1.35. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-08-21 17:48 Message: Logged In: YES user_id=671362 Should I close bug #842600 as a duplicate? (Although it was submitted last November.) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-20 09:43 Message: Logged In: YES user_id=29957 The code, however, still has 'yield' in it, and is therefore _not_ 2.1 compatible. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 09:34 Message: Logged In: YES user_id=21627 After discussion with /F, I have now bumped the minimum supported version to 2.1; fixed in xmlrpclib.py 1.34 and pep-0291.txt 1.11. Fredrik still has 1.5.2 installations he needs to support, but thinks he can manage maintenance on xmlrpclib for these on his own. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009803&group_id=5470 From noreply at sourceforge.net Sun Aug 22 19:32:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 19:32:31 2004 Subject: [ python-Bugs-1013882 ] tarfile.open with mode w|bz2 Message-ID: Bugs item #1013882, was opened at 2004-08-22 19:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013882&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.open with mode w|bz2 Initial Comment: tarfile.open with mode='w|bz2' only creates empty files. How to reproduce: 1. Create a file 'test' with some random content. 2. Execute the following Python code: import tarfile gz = tarfile.open('test.tar.gz', 'w|gz') gz.add('test') gz.close() bz2 = tarfile.open('test.tar.bz2', 'w|bz2') bz2.add('test') bz2.close() 3. Look at test.tar.* test.tar.gz has been created correctly, but test.tar.bz2 is empty (0 bytes). Reproducible with both Python 2.3.3 and Python 2.4a2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013882&group_id=5470 From noreply at sourceforge.net Sun Aug 22 19:39:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 19:40:02 2004 Subject: [ python-Bugs-1013418 ] Win XP DEP prevents Python call to 'C' DLL Message-ID: Bugs item #1013418, was opened at 2004-08-21 10:05 Message generated for change (Comment added) made by ajhewitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: ajhewitt (ajhewitt) Assigned to: Nobody/Anonymous (nobody) Summary: Win XP DEP prevents Python call to 'C' DLL Initial Comment: Following Mark Hammond's description in "Python Programming on Win32" I built his sample 'C' program, Hello.c which is called from Hellouse.py. The environment in which the DLL file was built is Visual Studio 2003 .NET and Windows XP SP2. When an attempt was made to run the example program hellouse.py, the program aborted with a "Data buffer overflow - program is corrupt" message from XP. I then moved the program files to Windows 2000 (just moved the library and python file) and the program executed correctly (as shown in Mark's book)! I then moved the program to a Windows XP SP1 based system and the program again executed as expected. I then poked around on the XP SP2 box and discovered a new "feature" called Data Execution Prevention. You can see this feature by right clicking on the "My Computer" icon and then clicking on "Properties" and "Advanced". I tried adding Python 2.3 (python and pythonw) to the exceptions list but that didn't help. I don't see any problem executing pure Python programs on the XP SP2 system. -Alex ---------------------------------------------------------------------- >Comment By: ajhewitt (ajhewitt) Date: 2004-08-22 12:39 Message: Logged In: YES user_id=1108513 Bingo! That fixed it. Thanks for looking. I probably should have caught that myself but I assumed (and we know what assume does ;^)) that the code was fully vetted and correct. I'll report that to the author of the book (Mark Hammond) and see that it get's added to the errata. Unfortunately, you may see more of these "bugs" because XP SP2 is now checking for this kind of thing. BTW, according to the documentation that Microsoft adds to this new feature, there are two types of implementation. One is the software only implementation (that's what I had on my system) and the second would require an AMD 64/Opteron processor. I don't own one of those (yet). You can close this one as a program/user error. Thanks for checking, -Alex ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 02:06 Message: Logged In: YES user_id=21627 Thanks. I cannot reproduce this at the moment (and I'm uncertain whether reproducing it requires an Athlon 64/Opteron processor), however, mere code inspection shows a potential problem of data buffer overflows. In the message function, you have char result[64]; so this can accommodate 64 characters. If the string you are passing is too long, the buffer will overflow, which might happen when you pass the string "module " + hello.__file__. As a quick work-around, please try to increase the result size to, say, char result[10000]; and see whether that makes the problem go away. If so, then a) this is a proper bug, and XP has helped to find it, and b) it is not a bug in Python, but in your code, and c) the proper solution is to either use a variable-sized buffer instead of a fixed-size one, or to check whether the buffer is large enough before copying into it. ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 14:09 Message: Logged In: YES user_id=1108513 Here's the Python program that calls the 'C' function... -Alex ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 14:08 Message: Logged In: YES user_id=1108513 The problem will definitely need to be resolved. I did find a workaround - disabling XP SP2's "Data Execution Prevention" by editing the boot.ini file and changing "noexecute:XXXX" to "execute". This will degrade XP's security but only to the extent that it was vulnerable prior to SP2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 10:25 Message: Logged In: YES user_id=21627 Do you want us to resolve the problem somehow? If so, please attach the sample code, so we can reproduce it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 From noreply at sourceforge.net Sun Aug 22 20:57:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 20:57:39 2004 Subject: [ python-Bugs-1013908 ] Error in representation of complex numbers Message-ID: Bugs item #1013908, was opened at 2004-08-22 13:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013908&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. L?wis (loewis) Summary: Error in representation of complex numbers Initial Comment: >>> 1-2j (1+-2j) This was introduced in Objects/complexobject.c 2.71 checked in by MvL on June 8, 2004. It is causing the doctests to fail on some of my apps. Recommend introducing an alternate path when the imaginary component is negative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013908&group_id=5470 From noreply at sourceforge.net Sun Aug 22 22:54:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 22:54:38 2004 Subject: [ python-Bugs-1013418 ] Win XP DEP prevents Python call to 'C' DLL Message-ID: Bugs item #1013418, was opened at 2004-08-21 17:05 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: ajhewitt (ajhewitt) Assigned to: Nobody/Anonymous (nobody) Summary: Win XP DEP prevents Python call to 'C' DLL Initial Comment: Following Mark Hammond's description in "Python Programming on Win32" I built his sample 'C' program, Hello.c which is called from Hellouse.py. The environment in which the DLL file was built is Visual Studio 2003 .NET and Windows XP SP2. When an attempt was made to run the example program hellouse.py, the program aborted with a "Data buffer overflow - program is corrupt" message from XP. I then moved the program files to Windows 2000 (just moved the library and python file) and the program executed correctly (as shown in Mark's book)! I then moved the program to a Windows XP SP1 based system and the program again executed as expected. I then poked around on the XP SP2 box and discovered a new "feature" called Data Execution Prevention. You can see this feature by right clicking on the "My Computer" icon and then clicking on "Properties" and "Advanced". I tried adding Python 2.3 (python and pythonw) to the exceptions list but that didn't help. I don't see any problem executing pure Python programs on the XP SP2 system. -Alex ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-22 19:39 Message: Logged In: YES user_id=1108513 Bingo! That fixed it. Thanks for looking. I probably should have caught that myself but I assumed (and we know what assume does ;^)) that the code was fully vetted and correct. I'll report that to the author of the book (Mark Hammond) and see that it get's added to the errata. Unfortunately, you may see more of these "bugs" because XP SP2 is now checking for this kind of thing. BTW, according to the documentation that Microsoft adds to this new feature, there are two types of implementation. One is the software only implementation (that's what I had on my system) and the second would require an AMD 64/Opteron processor. I don't own one of those (yet). You can close this one as a program/user error. Thanks for checking, -Alex ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 09:06 Message: Logged In: YES user_id=21627 Thanks. I cannot reproduce this at the moment (and I'm uncertain whether reproducing it requires an Athlon 64/Opteron processor), however, mere code inspection shows a potential problem of data buffer overflows. In the message function, you have char result[64]; so this can accommodate 64 characters. If the string you are passing is too long, the buffer will overflow, which might happen when you pass the string "module " + hello.__file__. As a quick work-around, please try to increase the result size to, say, char result[10000]; and see whether that makes the problem go away. If so, then a) this is a proper bug, and XP has helped to find it, and b) it is not a bug in Python, but in your code, and c) the proper solution is to either use a variable-sized buffer instead of a fixed-size one, or to check whether the buffer is large enough before copying into it. ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 21:09 Message: Logged In: YES user_id=1108513 Here's the Python program that calls the 'C' function... -Alex ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 21:08 Message: Logged In: YES user_id=1108513 The problem will definitely need to be resolved. I did find a workaround - disabling XP SP2's "Data Execution Prevention" by editing the boot.ini file and changing "noexecute:XXXX" to "execute". This will degrade XP's security but only to the extent that it was vulnerable prior to SP2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 17:25 Message: Logged In: YES user_id=21627 Do you want us to resolve the problem somehow? If so, please attach the sample code, so we can reproduce it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 From noreply at sourceforge.net Sun Aug 22 23:10:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 23:10:19 2004 Subject: [ python-Bugs-1013908 ] Error in representation of complex numbers Message-ID: Bugs item #1013908, was opened at 2004-08-22 20:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013908&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Martin v. L?wis (loewis) Summary: Error in representation of complex numbers Initial Comment: >>> 1-2j (1+-2j) This was introduced in Objects/complexobject.c 2.71 checked in by MvL on June 8, 2004. It is causing the doctests to fail on some of my apps. Recommend introducing an alternate path when the imaginary component is negative. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 23:10 Message: Logged In: YES user_id=21627 Fixed in test_complex.py 1.15 complexobject.c 2.72 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013908&group_id=5470 From noreply at sourceforge.net Sun Aug 22 23:30:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 22 23:31:02 2004 Subject: [ python-Bugs-1013882 ] tarfile.open with mode w|bz2 Message-ID: Bugs item #1013882, was opened at 2004-08-22 19:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013882&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.open with mode w|bz2 Initial Comment: tarfile.open with mode='w|bz2' only creates empty files. How to reproduce: 1. Create a file 'test' with some random content. 2. Execute the following Python code: import tarfile gz = tarfile.open('test.tar.gz', 'w|gz') gz.add('test') gz.close() bz2 = tarfile.open('test.tar.bz2', 'w|bz2') bz2.add('test') bz2.close() 3. Look at test.tar.* test.tar.gz has been created correctly, but test.tar.bz2 is empty (0 bytes). Reproducible with both Python 2.3.3 and Python 2.4a2. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 23:30 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in tarfile.py 1.18 test_tarfile.py 1.14 tarfile.py 1.8.12.3 NEWS 1.831.4.145 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013882&group_id=5470 From noreply at sourceforge.net Mon Aug 23 01:01:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 01:01:13 2004 Subject: [ python-Bugs-1011893 ] Problems importing packages in ZIP file Message-ID: Bugs item #1011893, was opened at 2004-08-19 13:17 Message generated for change (Comment added) made by dennis_cs_chuah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011893&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dennis Chuah (dennis_cs_chuah) Assigned to: Nobody/Anonymous (nobody) >Summary: Problems importing packages in ZIP file Initial Comment: Python 2.3.2 Windows platform Python is unable to import modules in ZIP files created by the PKZIP command line tool, version 2.50. ---------------------------------------------------------------------- >Comment By: Dennis Chuah (dennis_cs_chuah) Date: 2004-08-23 11:01 Message: Logged In: YES user_id=700058 More information. It would appear that the problem is not PKZIP's command line archiver as it also happens with ZIP archives created with the zipfile module. Rather the problem has something to do with packages in ZIP file. To reproduce this problem: 1. Create a sub-directory under c:\Python23 (or whereever you installed Python) named test. 2. Unzip the files from the ZIP archive into the directory. 3. Start the command line interpretor and enter: from test import testing Should display "test" 4. Exit the command line interpretor. 5. Delete all *.pyc files from the test directory. 6. Restart the interpretor and enter the following: import zipfile z = zipfile.PyZipFile ('test2.zip', 'w', zipfile.ZIP_DEFLATED) z.writepy ('test') z.close() It should have created a test2.zip archive. 7. Exit the interpretor. 8. Verify that test2.zip contains two pyc files inside the test folder. 9. Restart the interpretor and enter the following: import sys sys.path.append ('c:\Python23\test2.zip') from test import testing You should get: Traceback (most recent call last): File "", line 1, in ? ImportError: cannot import name testing Now, if you created a ZIP archive, with the PY files, it imports fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 19:24 Message: Logged In: YES user_id=21627 Can you please attach a small sample ZIP file that demonstrates the problem? I don't have the PKZIP command line tool. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011893&group_id=5470 From noreply at sourceforge.net Mon Aug 23 01:02:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 01:02:47 2004 Subject: [ python-Bugs-1011893 ] Problems importing packages in ZIP file Message-ID: Bugs item #1011893, was opened at 2004-08-19 13:17 Message generated for change (Comment added) made by dennis_cs_chuah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011893&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dennis Chuah (dennis_cs_chuah) Assigned to: Nobody/Anonymous (nobody) Summary: Problems importing packages in ZIP file Initial Comment: Python 2.3.2 Windows platform Python is unable to import modules in ZIP files created by the PKZIP command line tool, version 2.50. ---------------------------------------------------------------------- >Comment By: Dennis Chuah (dennis_cs_chuah) Date: 2004-08-23 11:02 Message: Logged In: YES user_id=700058 Changed summary to better reflect what the problem is. ---------------------------------------------------------------------- Comment By: Dennis Chuah (dennis_cs_chuah) Date: 2004-08-23 11:01 Message: Logged In: YES user_id=700058 More information. It would appear that the problem is not PKZIP's command line archiver as it also happens with ZIP archives created with the zipfile module. Rather the problem has something to do with packages in ZIP file. To reproduce this problem: 1. Create a sub-directory under c:\Python23 (or whereever you installed Python) named test. 2. Unzip the files from the ZIP archive into the directory. 3. Start the command line interpretor and enter: from test import testing Should display "test" 4. Exit the command line interpretor. 5. Delete all *.pyc files from the test directory. 6. Restart the interpretor and enter the following: import zipfile z = zipfile.PyZipFile ('test2.zip', 'w', zipfile.ZIP_DEFLATED) z.writepy ('test') z.close() It should have created a test2.zip archive. 7. Exit the interpretor. 8. Verify that test2.zip contains two pyc files inside the test folder. 9. Restart the interpretor and enter the following: import sys sys.path.append ('c:\Python23\test2.zip') from test import testing You should get: Traceback (most recent call last): File "", line 1, in ? ImportError: cannot import name testing Now, if you created a ZIP archive, with the PY files, it imports fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-20 19:24 Message: Logged In: YES user_id=21627 Can you please attach a small sample ZIP file that demonstrates the problem? I don't have the PKZIP command line tool. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011893&group_id=5470 From noreply at sourceforge.net Mon Aug 23 02:24:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 02:24:09 2004 Subject: [ python-Bugs-1013418 ] Win XP DEP prevents Python call to 'C' DLL Message-ID: Bugs item #1013418, was opened at 2004-08-21 10:05 Message generated for change (Comment added) made by ajhewitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: ajhewitt (ajhewitt) Assigned to: Nobody/Anonymous (nobody) Summary: Win XP DEP prevents Python call to 'C' DLL Initial Comment: Following Mark Hammond's description in "Python Programming on Win32" I built his sample 'C' program, Hello.c which is called from Hellouse.py. The environment in which the DLL file was built is Visual Studio 2003 .NET and Windows XP SP2. When an attempt was made to run the example program hellouse.py, the program aborted with a "Data buffer overflow - program is corrupt" message from XP. I then moved the program files to Windows 2000 (just moved the library and python file) and the program executed correctly (as shown in Mark's book)! I then moved the program to a Windows XP SP1 based system and the program again executed as expected. I then poked around on the XP SP2 box and discovered a new "feature" called Data Execution Prevention. You can see this feature by right clicking on the "My Computer" icon and then clicking on "Properties" and "Advanced". I tried adding Python 2.3 (python and pythonw) to the exceptions list but that didn't help. I don't see any problem executing pure Python programs on the XP SP2 system. -Alex ---------------------------------------------------------------------- >Comment By: ajhewitt (ajhewitt) Date: 2004-08-22 19:24 Message: Logged In: YES user_id=1108513 This code actually came from the Oreilly book "Programming Python 2nd Edition" by Mark Lutz. I'll still let them know there's a problem. -Alex P.S. The code is the "simple C extention module" around page 1,000. ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-22 12:39 Message: Logged In: YES user_id=1108513 Bingo! That fixed it. Thanks for looking. I probably should have caught that myself but I assumed (and we know what assume does ;^)) that the code was fully vetted and correct. I'll report that to the author of the book (Mark Hammond) and see that it get's added to the errata. Unfortunately, you may see more of these "bugs" because XP SP2 is now checking for this kind of thing. BTW, according to the documentation that Microsoft adds to this new feature, there are two types of implementation. One is the software only implementation (that's what I had on my system) and the second would require an AMD 64/Opteron processor. I don't own one of those (yet). You can close this one as a program/user error. Thanks for checking, -Alex ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-22 02:06 Message: Logged In: YES user_id=21627 Thanks. I cannot reproduce this at the moment (and I'm uncertain whether reproducing it requires an Athlon 64/Opteron processor), however, mere code inspection shows a potential problem of data buffer overflows. In the message function, you have char result[64]; so this can accommodate 64 characters. If the string you are passing is too long, the buffer will overflow, which might happen when you pass the string "module " + hello.__file__. As a quick work-around, please try to increase the result size to, say, char result[10000]; and see whether that makes the problem go away. If so, then a) this is a proper bug, and XP has helped to find it, and b) it is not a bug in Python, but in your code, and c) the proper solution is to either use a variable-sized buffer instead of a fixed-size one, or to check whether the buffer is large enough before copying into it. ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 14:09 Message: Logged In: YES user_id=1108513 Here's the Python program that calls the 'C' function... -Alex ---------------------------------------------------------------------- Comment By: ajhewitt (ajhewitt) Date: 2004-08-21 14:08 Message: Logged In: YES user_id=1108513 The problem will definitely need to be resolved. I did find a workaround - disabling XP SP2's "Data Execution Prevention" by editing the boot.ini file and changing "noexecute:XXXX" to "execute". This will degrade XP's security but only to the extent that it was vulnerable prior to SP2. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-21 10:25 Message: Logged In: YES user_id=21627 Do you want us to resolve the problem somehow? If so, please attach the sample code, so we can reproduce it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1013418&group_id=5470 From noreply at sourceforge.net Mon Aug 23 03:39:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 03:39:49 2004 Subject: [ python-Bugs-1014022 ] mimetypes add_type has bogus self parameter Message-ID: Bugs item #1014022, was opened at 2004-08-22 18:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Wells (cliffwells18) Assigned to: Nobody/Anonymous (nobody) Summary: mimetypes add_type has bogus self parameter Initial Comment: Python 2.3.3 mimetypes module defines the following function: def add_type(self, type, ext, strict=True) This is incorrect as there should be no "self" argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 From noreply at sourceforge.net Mon Aug 23 03:48:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 03:48:55 2004 Subject: [ python-Bugs-1014022 ] mimetypes add_type has bogus self parameter Message-ID: Bugs item #1014022, was opened at 2004-08-22 18:39 Message generated for change (Comment added) made by cliffwells18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Wells (cliffwells18) Assigned to: Nobody/Anonymous (nobody) Summary: mimetypes add_type has bogus self parameter Initial Comment: Python 2.3.3 mimetypes module defines the following function: def add_type(self, type, ext, strict=True) This is incorrect as there should be no "self" argument. ---------------------------------------------------------------------- >Comment By: Cliff Wells (cliffwells18) Date: 2004-08-22 18:48 Message: Logged In: YES user_id=340357 Actually, the real problem appears to be that mimetypes.init() isn't called automatically as the documentation suggests. import mimetypes mimetypes.add_type('text/xml', '.rss') doesn't work but import mimetypes mimetypes.init() mimetypes.add_type('text/xml', '.rss') does. From http://www.python.org/doc/current/lib/module-mimetypes.html: "The functions described below provide the primary interface for this module. If the module has not been initialized, they will call init() if they rely on the information init() sets up." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 From noreply at sourceforge.net Mon Aug 23 10:15:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 10:15:32 2004 Subject: [ python-Bugs-1014022 ] mimetypes add_type has bogus self parameter Message-ID: Bugs item #1014022, was opened at 2004-08-23 03:39 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Wells (cliffwells18) Assigned to: Nobody/Anonymous (nobody) Summary: mimetypes add_type has bogus self parameter Initial Comment: Python 2.3.3 mimetypes module defines the following function: def add_type(self, type, ext, strict=True) This is incorrect as there should be no "self" argument. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-08-23 10:15 Message: Logged In: YES user_id=89016 The problem with the bogus self parameter has already been fixed in CVS (both on the trunk (revision 1.30) and on the maintainance branch (revision 1.28.8.2 which went into release 2.3.4). The global add_type() *does* call init(). Can you check whether your problem is gone with 2.3.4? ---------------------------------------------------------------------- Comment By: Cliff Wells (cliffwells18) Date: 2004-08-23 03:48 Message: Logged In: YES user_id=340357 Actually, the real problem appears to be that mimetypes.init() isn't called automatically as the documentation suggests. import mimetypes mimetypes.add_type('text/xml', '.rss') doesn't work but import mimetypes mimetypes.init() mimetypes.add_type('text/xml', '.rss') does. From http://www.python.org/doc/current/lib/module-mimetypes.html: "The functions described below provide the primary interface for this module. If the module has not been initialized, they will call init() if they rely on the information init() sets up." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 From noreply at sourceforge.net Mon Aug 23 10:16:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 10:16:40 2004 Subject: [ python-Bugs-1014022 ] mimetypes add_type has bogus self parameter Message-ID: Bugs item #1014022, was opened at 2004-08-23 03:39 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cliff Wells (cliffwells18) >Assigned to: Walter D?rwald (doerwalter) Summary: mimetypes add_type has bogus self parameter Initial Comment: Python 2.3.3 mimetypes module defines the following function: def add_type(self, type, ext, strict=True) This is incorrect as there should be no "self" argument. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-08-23 10:15 Message: Logged In: YES user_id=89016 The problem with the bogus self parameter has already been fixed in CVS (both on the trunk (revision 1.30) and on the maintainance branch (revision 1.28.8.2 which went into release 2.3.4). The global add_type() *does* call init(). Can you check whether your problem is gone with 2.3.4? ---------------------------------------------------------------------- Comment By: Cliff Wells (cliffwells18) Date: 2004-08-23 03:48 Message: Logged In: YES user_id=340357 Actually, the real problem appears to be that mimetypes.init() isn't called automatically as the documentation suggests. import mimetypes mimetypes.add_type('text/xml', '.rss') doesn't work but import mimetypes mimetypes.init() mimetypes.add_type('text/xml', '.rss') does. From http://www.python.org/doc/current/lib/module-mimetypes.html: "The functions described below provide the primary interface for this module. If the module has not been initialized, they will call init() if they rely on the information init() sets up." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014022&group_id=5470 From noreply at sourceforge.net Mon Aug 23 11:33:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 11:33:06 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 11:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Mon Aug 23 12:04:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 12:04:59 2004 Subject: [ python-Bugs-1014230 ] optparse: parser.remove_option("-h") inconsistency Message-ID: Bugs item #1014230, was opened at 2004-08-23 12:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014230&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: strop (strop) Assigned to: Nobody/Anonymous (nobody) Summary: optparse: parser.remove_option("-h") inconsistency Initial Comment: remove_option("-h") method of OptionParser has a strange behaviour : it can't be removed from 2 different OptionParser objects. It may be due to the fact that the help option seems to be a unique object. Even if this can be "solved" by addind add_help_option=0 to OptionParser constructor parameters, it seems to be an inconsistency wrt remove_option method ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014230&group_id=5470 From noreply at sourceforge.net Mon Aug 23 13:00:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 13:00:16 2004 Subject: [ python-Bugs-967334 ] Cmd in thread segfaults after Ctrl-C Message-ID: Bugs item #967334, was opened at 2004-06-06 00:11 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967334&group_id=5470 Category: Threads Group: Python 2.3 >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Kevin M. Turner (acapnotic) Assigned to: Michael Hudson (mwh) Summary: Cmd in thread segfaults after Ctrl-C Initial Comment: With Cmd.cmdloop running in a thread, saying Ctrl-C will make Python segfault. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-23 12:00 Message: Logged In: YES user_id=6656 Closing as threatened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:45 Message: Logged In: YES user_id=6656 Usual deal; two months of inactivity. Two more weeks and this will be closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-06-13 22:15 Message: Logged In: YES user_id=33168 This works for me on Linux. What OS are you using? Are you using any non-standard extension modules? What version of Python? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=967334&group_id=5470 From noreply at sourceforge.net Mon Aug 23 13:00:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 13:00:38 2004 Subject: [ python-Bugs-970334 ] 2.3.4 fails build on solaris 10 - complexobject.c Message-ID: Bugs item #970334, was opened at 2004-06-10 13:46 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 Category: Build Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: JD Bronson (lonebandit) Assigned to: Michael Hudson (mwh) Summary: 2.3.4 fails build on solaris 10 - complexobject.c Initial Comment: this has been an ongoing issue: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/classobject.o Objects/classobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/cobject.o Objects/cobject.c gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c Objects/complexobject.c: In function `complex_pow': Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus Objects/complexobject.c:469: error: invalid operands to binary == Objects/complexobject.c:469: error: wrong type argument to unary minus make: *** [Objects/complexobject.o] Error 1 ..It fails at that point with no workaround. Jeff ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-23 12:00 Message: Logged In: YES user_id=6656 Closing as threatened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:43 Message: Logged In: YES user_id=6656 Given that this has sat here for two months without activity, I propose closing it in another fortnight. Assigning to me on the off-chance this makes me more likely to remember :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-10 16:08 Message: Logged In: YES user_id=31435 See comments about Py_HUGE_VAL in pyport.h. Possible that this platform defines C's HUGE_VAL incorrectly, in which case config for this platfrom needs to set Py_HUGE_VAL to a correct expansion. You could also try compiling complexobject.c without optimization. In at least one prior case, the platform HUGE_VAL was correct, but expanded to such a hairy expression that it confused the platform C compiler when optimization was cranked up. Finally, you didn't say which version of gcc and its libraries you're using. It's possible that another version would work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=970334&group_id=5470 From noreply at sourceforge.net Mon Aug 23 13:36:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 13:37:14 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 10:33 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Raymond Hettinger (rhettinger) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-08-23 12:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Mon Aug 23 18:07:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 23 18:08:09 2004 Subject: [ python-Bugs-1014215 ] Unspecific errors with metaclass Message-ID: Bugs item #1014215, was opened at 2004-08-23 04:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Michael Hudson (mwh) Summary: Unspecific errors with metaclass Initial Comment: Metaclass errors give only unspecific tracebacks. The attached sample, with Python 2.3: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Cannot create a consistent method resolution order (MRO) for bases X, Y With Python 2.4, it prints: Traceback (most recent call last): File "mc.py", line 10, in ? class Z(X, Y): TypeError: Error when calling the metaclass. Make sure the base arguments are valid. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 11:07 Message: Logged In: YES user_id=80475 Since 2.398 only replaces one type error with another, it's really just about the contest of the error message. Feel free to remove or clarify the new message. The core issue is that the lower level routines don't know enough to create an informative error message and yet the high level routines don't want to mask the information that was available at the lower level. Without considerable effort, some of the error messages will be completely opaque and uninformative, cryptic, or misleading (bug 963956 being a prime example). My preference is to opt for the higher level message, but tastes vary. If you want to go for the gold, one possibility is to capture the text of the lower level TypeError and append it to the high level message. The resulting messages may be scary but at least they'll point a specific cause and be suggestive of how to fix it. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-23 06:36 Message: Logged In: YES user_id=6656 Argh argh argh. This is a result of fixing bug #963956. While the fix was well- intentioned, I don't know if it's really the right thing... I suspect putting a more informative message in module_new might suffice. Raymond's way of fixing the bug also neatly (and presumbably accidentally) sidestepped the tests that attempted to make sure you got a decent error message for this. Raymond, what do you think? I don't think the check in ceval.c:build_class can survive as is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470 From noreply at sourceforge.net Tue Aug 24 00:05:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 00:05:46 2004 Subject: [ python-Bugs-1014761 ] Missing urllib.urlretrieve docs Message-ID: Bugs item #1014761, was opened at 2004-08-23 17:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014761&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: Missing urllib.urlretrieve docs Initial Comment: urllib.urlretrieve docs give no description for the reporthook argument ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014761&group_id=5470 From noreply at sourceforge.net Tue Aug 24 00:26:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 00:26:20 2004 Subject: [ python-Bugs-1014770 ] Misc/NEWS no valid reStructuredText Message-ID: Bugs item #1014770, was opened at 2004-08-24 00:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014770&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: Misc/NEWS no valid reStructuredText Initial Comment: Misc/NEWS (in both Python 2.4a1 and 2.4a2) is not valid reStructuredText, but NEWS.help says it should be. Processing it with Docutils gives several errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014770&group_id=5470 From noreply at sourceforge.net Tue Aug 24 00:35:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 00:35:38 2004 Subject: [ python-Bugs-1014775 ] Misc/NEWS.help Message-ID: Bugs item #1014775, was opened at 2004-08-24 00:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014775&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: Misc/NEWS.help Initial Comment: Misc/NEWS.help needs to be updated because of changes in Docutils. Attached an updated version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014775&group_id=5470 From noreply at sourceforge.net Tue Aug 24 01:25:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 01:25:35 2004 Subject: [ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves Message-ID: Bugs item #1001011, was opened at 2004-07-30 19:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 Category: Type/class unification Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: str.join([ str-subtype-instance ]) misbehaves Initial Comment: Joining a list of string subtype instances usually results in a single string instance: >>> class mystr(str): pass >>> type("".join([mystr("a"), mystr("b")])) But if the list only contains one object that is a string subtype instance, that instance is returned unchanged: >>> type("".join([mystr("a")])) This can have odd effects, for instance when the result of "".join(lst) is used as the returnvalue of a __str__ hook. "".join should perhaps return the type of the joining string, but definately vary its type based on the *number* of items its joining. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-23 18:25 Message: Logged In: YES user_id=80475 Fixed. See: Objects/stringobject.c 2.225 Lib/test/test_string.py 1.26 ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-19 16:13 Message: Logged In: YES user_id=1038590 I've just assigned the relevant patch to Tim for review. The latest version should address his concerns with the original fix (which didn't use the optimised path, even when it was safe). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-19 13:22 Message: Logged In: YES user_id=31435 I think the patch is still awaiting review. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 12:46 Message: Logged In: YES user_id=80475 Was this one fixed? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 03:04 Message: Logged In: YES user_id=1038590 New patch (#1007087) created with a test for this bug, as well as a fix for it (the fix simply removes the 'sequence of 1' shortcut). Checks for the unicode case as well, although unicode didn't have this bug (due to a different join implementation). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-08-11 02:00 Message: Logged In: YES user_id=1038590 Don't know about anyone else, but the shortcut in str.join that returns a reference to the *original* string in the case of a single item sequence strikes me as very bad ju-ju: >>> class mystr(str): pass ... >>> s1 = mystr('fred') >>> s1 'fred' >>> s1.mutable = 42 >>> s1.mutable 42 >>> s2 = ''.join([s1]) >>> s2.mutable 42 When I call join, I expect to get a *new* object back, not a reference to an old one (this is safe for standard strings, but not for subclasses which may have mutable state). ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2004-08-07 17:17 Message: Logged In: YES user_id=34209 The point of the original bugreport is not that some operations return strings instead of subtypes. The point is that *one* operation *sometimes* returns subtypes. It's inconsistent and unexpected behaviour, and since you clearly don't write 'sep.join(seq)' for a common case of 'seq' being a single item, something you will only occasionally trigger. I don't have an emotional investment in this bug, it's just something that came up on #python. I also don't care which way it's fixed -- but treating the single-element-sequence case the same as the multiple-element-sequence seems logical to me. Regardless of how the multiple-element-sequence is handled exactly :) As for why I didn't write a patch myself, Michael, if I had time for that, I would've spent it writing a good decorator proposal >:-) ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2004-08-07 10:48 Message: Logged In: YES user_id=7887 If this was considered a bug: >>> type(ms("a")+ms("b")) >>> type(ms("a")[:]) Are these bugs as well? I belive this is how the implementation was intended to be, even if not optimal for subclasses. I suggest closing this bug as invalid, and writing a PEP about the possible new subclass support change (for all classes), if there's enough interest. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-05 11:10 Message: Logged In: YES user_id=593130 Duh, my turn to forget. For any beginners reading this ... >>> class ms(str): pass ... >>> a=ms('a') >>> type(''.join((a,))) Expanding mhw's second point: >>> e=ms() >>> type(e) >>> import copy >>> e2=copy.copy(e) >>> type(e2) >>> e3=e[:] >>> type(e3) >>> id(e),id(e2),id(e3) (9494608, 9009936, 8577440) so [:] is not exactly an abbreviated synonym for copy(). Is this a butg? (I haven't rechecked the respective docs yet.) One reason I hesitate to call the OP's original observation a bug is that the whole sujbect of operations on subtype instances seems not completely baked. Knowing the result types in all cases may require experiments as well as doc reading. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-05 07:04 Message: Logged In: YES user_id=6656 A clue for Terry: think about what "(a)" isn't :-) I initially agreed that this was a bug because, e.g. str_subclass()[:] returns a str. Isn't this the same sort of thing? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-08-04 15:28 Message: Logged In: YES user_id=38388 I agree with Terry. The result type is defined by the semantics or the list elements and the length of the list: len(list) > 1: sep.join(list) := list[0] + sep + ... + sep + list[n] len(list) == 1: sep.join(list) := list[0] len(list) == 0: sep.join(list) := sep[:0] ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 14:39 Message: Logged In: YES user_id=593130 This behavior does not, to me, clearly violate the current doc: "Return a string which is the concatenation of the strings in the sequence seq" where string is bytestring or Unicodestring. If one takes 'string' narrowly, then your subclass instances should be rejected as input. If one takes 'string' more broadly as isinstance(s,basestring) then your subclass should be equally acceptible as input or output. If neither consistent interpretation of 'string' is meant, then there is a doc bug, or at least an underspecification. Workaround 0: if len(seq) == 1: ... Workaround 1. map(str, seq)) to force str out. *However*, in playing around (in 2.2), I discovered: >>> type(''.join((a))) >>> type(''.join([a])) >>> type(''.join({a:None})) Having the type of the join of a singleton depend on the type (mutability?) of the singleton wrapper is definitely disquieting. Workaround 2: tuple(seq) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-02 09:25 Message: Logged In: YES user_id=6656 What are you asking? I agree it's a bug. I'm sure you're competent to write a patch :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001011&group_id=5470 From noreply at sourceforge.net Tue Aug 24 12:26:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 12:26:36 2004 Subject: [ python-Bugs-1015140 ] "article id" in description of NNTP objects Message-ID: Bugs item #1015140, was opened at 2004-08-24 12:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: "article id" in description of NNTP objects Initial Comment: lib/nntp-objects.html uses the term "article id" several times. This term is ambiguous though. Either "article number" or "message id" should be used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 From noreply at sourceforge.net Tue Aug 24 15:32:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 15:32:28 2004 Subject: [ python-Bugs-1015249 ] cgi.FieldStorage.__len__ eventually throws TypeError Message-ID: Bugs item #1015249, was opened at 2004-08-24 15:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015249&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Ames (yxcv) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage.__len__ eventually throws TypeError Initial Comment: This makes it hazardous to do the following: fs = cgi.FieldStorage(...) if fs: ... Suggestions: 1) Fix __len__; sorry, but I don't know how. 2) Create FieldStorage.__nonzero__; a hack. 3) ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015249&group_id=5470 From noreply at sourceforge.net Tue Aug 24 15:41:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 15:41:40 2004 Subject: [ python-Bugs-1015254 ] Create cgi.FieldStorage._get_new_instance method as factory Message-ID: Bugs item #1015254, was opened at 2004-08-24 15:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015254&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Andreas Ames (yxcv) Assigned to: Nobody/Anonymous (nobody) Summary: Create cgi.FieldStorage._get_new_instance method as factory Initial Comment: and use this factory method instead of calling self.__class__ or FieldStorage.FieldStorageClass in FieldStorage.read_multi directly. This would allow people deriving from FieldStorage to customize the list of parameters given to the constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015254&group_id=5470 From noreply at sourceforge.net Tue Aug 24 17:00:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 17:00:32 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 08:30 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-08-24 11:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Tue Aug 24 17:04:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 17:04:17 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 08:30 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-08-24 11:04 Message: Logged In: YES user_id=7733 The alternative is the following change in Docutils. Unfortunately, it requires access to internal implementation details marked with single leading underscores. diff -u -r1.64 frontend.py --- docutils/frontend.py 24 Jul 2004 14:13:38 -0000 1.64 +++ docutils/frontend.py 24 Aug 2004 15:01:32 -0000 @@ -637,6 +637,22 @@ section_dict[option] = self.get(section, option, raw=1) return section_dict + def set(self, section, option, value): + """ + Set an option. + + Overrides stdlib ConfigParser's set() method to allow non-string + values. Required for compatibility with Python 2.4. + """ + if not section or section == CP.DEFAULTSECT: + sectdict = self._defaults + else: + try: + sectdict = self._sections[section] + except KeyError: + raise CP.NoSectionError(section) + sectdict[self.optionxform(option)] = value + class ConfigDeprecationWarning(DeprecationWarning): """Warning for deprecated configuration file features.""" ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Tue Aug 24 17:10:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 17:10:06 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 08:30 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-08-24 11:10 Message: Logged In: YES user_id=7733 Also see the python-dev thread at . The third message in the thread was garbled due to a GPG problem; reproduced below. [Fred L. Drake, Jr.] > David has (properly) been asking me to look into this, and i've > managed not to have enough time. Sorry, David! I thought a python-dev nudge might get you off your keister ;-) > The ConfigParser documentation was certainly too vague, but the > problem, as I see it, is that the module was never intended to store > non-string values. BUT ConfigParser *did* allow non-strings to be stored, for internal use only (can't write them out, of course). And changing it *did* break code. I think a doc change acknowledging that ability but qualifying it ("for internal use only, can't be used to write out config files or interpolate values") would have been a better fix. The change in rev. 1.65 makes ConfigParser.py *less* useful. When I used ConfigParser in Docutils, I wasn't being especially clever when I used it to set non-string values. It will take a lot more cleverness post-rev-1.65 to enable that functionality. Of course, the fix to Docutils is pretty simple: just override ConfigParser.set with the older version. But that depends on private implementation details (self._defaults, self._sections). This is *much* more dangerous and impossible to future-proof against. > I think allowing them is just asking for still more trouble from > that module down the road. Has there been any trouble until now? Why "fix" something that wasn't really broke? The original bug report (http://www.python.org/sf/810843) was really only asking for clarification. It ends with: Nonetheless, I was shocked to see what I thought was a straightforward use of ConfigParser throw off errors. Imagine developers' shock now that we can't do what we want at all! Docutils is not the only project using ConfigParser to store non-strings. I wouldn't be surprised to see other code breaking, which we probably wouldn't find out about until after 2.4-final. > Sure, the module could be made happy by reverting the patch you > cite, but happy-by-accident is a very fragile state to be in. So let's remove the accident, and make the happiness official! >> The comment for bug 810843 says "This is documented behavior", but >> I couldn't find any such documentation pre-dating this change. > > This may have been a bug in my memory. Now that the memory bug is fixed, how about reconsidering the resultant decision? I'll write a doc patch ASAP. -- David Goodger ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:04 Message: Logged In: YES user_id=7733 The alternative is the following change in Docutils. Unfortunately, it requires access to internal implementation details marked with single leading underscores. diff -u -r1.64 frontend.py --- docutils/frontend.py 24 Jul 2004 14:13:38 -0000 1.64 +++ docutils/frontend.py 24 Aug 2004 15:01:32 -0000 @@ -637,6 +637,22 @@ section_dict[option] = self.get(section, option, raw=1) return section_dict + def set(self, section, option, value): + """ + Set an option. + + Overrides stdlib ConfigParser's set() method to allow non-string + values. Required for compatibility with Python 2.4. + """ + if not section or section == CP.DEFAULTSECT: + sectdict = self._defaults + else: + try: + sectdict = self._sections[section] + except KeyError: + raise CP.NoSectionError(section) + sectdict[self.optionxform(option)] = value + class ConfigDeprecationWarning(DeprecationWarning): """Warning for deprecated configuration file features.""" ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Tue Aug 24 17:14:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 17:14:58 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 08:30 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-08-24 11:14 Message: Logged In: YES user_id=7733 I strongly feel that the 2.3 behavior should be restored, and documented, before 2.4b1. I will do the doc change. I have updated the bug report with links and discussions. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:10 Message: Logged In: YES user_id=7733 Also see the python-dev thread at . The third message in the thread was garbled due to a GPG problem; reproduced below. [Fred L. Drake, Jr.] > David has (properly) been asking me to look into this, and i've > managed not to have enough time. Sorry, David! I thought a python-dev nudge might get you off your keister ;-) > The ConfigParser documentation was certainly too vague, but the > problem, as I see it, is that the module was never intended to store > non-string values. BUT ConfigParser *did* allow non-strings to be stored, for internal use only (can't write them out, of course). And changing it *did* break code. I think a doc change acknowledging that ability but qualifying it ("for internal use only, can't be used to write out config files or interpolate values") would have been a better fix. The change in rev. 1.65 makes ConfigParser.py *less* useful. When I used ConfigParser in Docutils, I wasn't being especially clever when I used it to set non-string values. It will take a lot more cleverness post-rev-1.65 to enable that functionality. Of course, the fix to Docutils is pretty simple: just override ConfigParser.set with the older version. But that depends on private implementation details (self._defaults, self._sections). This is *much* more dangerous and impossible to future-proof against. > I think allowing them is just asking for still more trouble from > that module down the road. Has there been any trouble until now? Why "fix" something that wasn't really broke? The original bug report (http://www.python.org/sf/810843) was really only asking for clarification. It ends with: Nonetheless, I was shocked to see what I thought was a straightforward use of ConfigParser throw off errors. Imagine developers' shock now that we can't do what we want at all! Docutils is not the only project using ConfigParser to store non-strings. I wouldn't be surprised to see other code breaking, which we probably wouldn't find out about until after 2.4-final. > Sure, the module could be made happy by reverting the patch you > cite, but happy-by-accident is a very fragile state to be in. So let's remove the accident, and make the happiness official! >> The comment for bug 810843 says "This is documented behavior", but >> I couldn't find any such documentation pre-dating this change. > > This may have been a bug in my memory. Now that the memory bug is fixed, how about reconsidering the resultant decision? I'll write a doc patch ASAP. -- David Goodger ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:04 Message: Logged In: YES user_id=7733 The alternative is the following change in Docutils. Unfortunately, it requires access to internal implementation details marked with single leading underscores. diff -u -r1.64 frontend.py --- docutils/frontend.py 24 Jul 2004 14:13:38 -0000 1.64 +++ docutils/frontend.py 24 Aug 2004 15:01:32 -0000 @@ -637,6 +637,22 @@ section_dict[option] = self.get(section, option, raw=1) return section_dict + def set(self, section, option, value): + """ + Set an option. + + Overrides stdlib ConfigParser's set() method to allow non-string + values. Required for compatibility with Python 2.4. + """ + if not section or section == CP.DEFAULTSECT: + sectdict = self._defaults + else: + try: + sectdict = self._sections[section] + except KeyError: + raise CP.NoSectionError(section) + sectdict[self.optionxform(option)] = value + class ConfigDeprecationWarning(DeprecationWarning): """Warning for deprecated configuration file features.""" ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Tue Aug 24 18:10:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 18:10:27 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 07:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 11:10 Message: Logged In: YES user_id=80475 Perhaps, the set() method should coerce to a string rather than test for it. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 10:14 Message: Logged In: YES user_id=7733 I strongly feel that the 2.3 behavior should be restored, and documented, before 2.4b1. I will do the doc change. I have updated the bug report with links and discussions. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 10:10 Message: Logged In: YES user_id=7733 Also see the python-dev thread at . The third message in the thread was garbled due to a GPG problem; reproduced below. [Fred L. Drake, Jr.] > David has (properly) been asking me to look into this, and i've > managed not to have enough time. Sorry, David! I thought a python-dev nudge might get you off your keister ;-) > The ConfigParser documentation was certainly too vague, but the > problem, as I see it, is that the module was never intended to store > non-string values. BUT ConfigParser *did* allow non-strings to be stored, for internal use only (can't write them out, of course). And changing it *did* break code. I think a doc change acknowledging that ability but qualifying it ("for internal use only, can't be used to write out config files or interpolate values") would have been a better fix. The change in rev. 1.65 makes ConfigParser.py *less* useful. When I used ConfigParser in Docutils, I wasn't being especially clever when I used it to set non-string values. It will take a lot more cleverness post-rev-1.65 to enable that functionality. Of course, the fix to Docutils is pretty simple: just override ConfigParser.set with the older version. But that depends on private implementation details (self._defaults, self._sections). This is *much* more dangerous and impossible to future-proof against. > I think allowing them is just asking for still more trouble from > that module down the road. Has there been any trouble until now? Why "fix" something that wasn't really broke? The original bug report (http://www.python.org/sf/810843) was really only asking for clarification. It ends with: Nonetheless, I was shocked to see what I thought was a straightforward use of ConfigParser throw off errors. Imagine developers' shock now that we can't do what we want at all! Docutils is not the only project using ConfigParser to store non-strings. I wouldn't be surprised to see other code breaking, which we probably wouldn't find out about until after 2.4-final. > Sure, the module could be made happy by reverting the patch you > cite, but happy-by-accident is a very fragile state to be in. So let's remove the accident, and make the happiness official! >> The comment for bug 810843 says "This is documented behavior", but >> I couldn't find any such documentation pre-dating this change. > > This may have been a bug in my memory. Now that the memory bug is fixed, how about reconsidering the resultant decision? I'll write a doc patch ASAP. -- David Goodger ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 10:04 Message: Logged In: YES user_id=7733 The alternative is the following change in Docutils. Unfortunately, it requires access to internal implementation details marked with single leading underscores. diff -u -r1.64 frontend.py --- docutils/frontend.py 24 Jul 2004 14:13:38 -0000 1.64 +++ docutils/frontend.py 24 Aug 2004 15:01:32 -0000 @@ -637,6 +637,22 @@ section_dict[option] = self.get(section, option, raw=1) return section_dict + def set(self, section, option, value): + """ + Set an option. + + Overrides stdlib ConfigParser's set() method to allow non-string + values. Required for compatibility with Python 2.4. + """ + if not section or section == CP.DEFAULTSECT: + sectdict = self._defaults + else: + try: + sectdict = self._sections[section] + except KeyError: + raise CP.NoSectionError(section) + sectdict[self.optionxform(option)] = value + class ConfigDeprecationWarning(DeprecationWarning): """Warning for deprecated configuration file features.""" ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 10:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Tue Aug 24 21:44:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 21:44:19 2004 Subject: [ python-Bugs-1015517 ] readline broken Message-ID: Bugs item #1015517, was opened at 2004-08-24 21:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015517&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Martin v. L?wis (loewis) Summary: readline broken Initial Comment: The readline module seems to broken in current CVS (see the attached build log). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015517&group_id=5470 From noreply at sourceforge.net Tue Aug 24 23:39:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 23:39:13 2004 Subject: [ python-Bugs-902501 ] Encodings: koi8-u.py -- errata in decoding map Message-ID: Bugs item #902501, was opened at 2004-02-23 08:37 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902501&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Alexander Belchenko (bialix) Assigned to: M.-A. Lemburg (lemburg) Summary: Encodings: koi8-u.py -- errata in decoding map Initial Comment: File koi8-u.py in /Lib/encodings/koi8-u.py has errata. Decoding map dictionary update for ukrainian letter "CYRILLIC CAPITAL LETTER UKRAINIAN IE" is *** 0x00b4: 0x0403, # CYRILLIC CAPITAL LETTER UKRAINIAN IE *** Must be Unicode representation - 0x0404 instead of 0x0403. Reference: RFC2319 (look at ftp://ftp.lucky.net/pub/koi8-u/RFC2319.txt and ftp://ftp.unicode.org/Public/4.0-Update1/UnicodeData-4.0.1d3b.txt) Other cyrilic decoding map is correct. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2004-08-24 23:39 Message: Logged In: YES user_id=60903 fixed in the 2.3 branch as well: Lib/encodings/koi8_u.py 1.1.18.1 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-23 10:05 Message: Logged In: YES user_id=38388 Thanks. Checking in koi8_u.py; /cvsroot/python/python/dist/src/Lib/encodings/koi8_u.py,v <-- koi8_u.py new revision: 1.2; previous revision: 1.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902501&group_id=5470 From noreply at sourceforge.net Tue Aug 24 23:48:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 24 23:48:59 2004 Subject: [ python-Bugs-991962 ] Building with --disable-toolbox-glue fails Message-ID: Bugs item #991962, was opened at 2004-07-15 15:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Building with --disable-toolbox-glue fails Initial Comment: Building with --disable-toolbox-glue fails, because setup.py still tries to build lots of MacOSX extension modules (which fails). There's a define USE_TOOLBOX_OBJECT_GLUE in pyconfig.h that shows whether we're building with or without toolbox glue, but distutils needs to look at that. If it can, otherwise we need a flag in the Makefile too. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-24 14:48 Message: Logged In: YES user_id=357491 Attached is a diff for setup.py that leaves out the Mac directories from compilation and skips building all Mac-specific modules if --disable- toolbox-glue is specified. If anyone thinks I am missing a step (didn't bother checking for --disable-framework since I doubt it can build without the toolbox glue being enabled) then please say so. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-16 16:16 Message: Logged In: YES user_id=357491 Can we add ``"--disable-toolbox-glue" not in distutils.sysconfig.get_config_var("CONFIG_ARGS")`` as part of the conditional? That should prevent unneeded compiling. If that does work the question becomes whether that should be part of the conditional for all the modules in setup.py or only some of them. Personally I say get rid all of them since if you are building with -- disable-toolbox-glue I would suspect you want a simple UNIX version of Python and not really have anything to do with OS X-specific features. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:32 Message: Logged In: YES user_id=357491 It seems like we need some way to either have access in Python to what the arguments to Configure were or what macro defs pyconfig.h comes up with. That would be enough info to find out if compiling with toolbox glue we turned off. Otherwise I don't know how Distutils could possibly get access without somehow parsing pyconfig.h to look to see what is set and what isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 From noreply at sourceforge.net Wed Aug 25 03:20:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 03:20:34 2004 Subject: [ python-Bugs-1015517 ] readline broken Message-ID: Bugs item #1015517, was opened at 2004-08-24 15:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015517&group_id=5470 Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Neal Norwitz (nnorwitz) Summary: readline broken Initial Comment: The readline module seems to broken in current CVS (see the attached build log). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-24 21:20 Message: Logged In: YES user_id=33168 Walter, I think I fixed this problem. Let me know if it doesn't work for you since I can't test it. Checked in as: Modules/readline.c 2.77 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015517&group_id=5470 From noreply at sourceforge.net Wed Aug 25 05:34:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 05:34:06 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 08:30 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-08-24 23:34 Message: Logged In: YES user_id=7733 [rhettinger] > Perhaps, the set() method should coerce to a string rather > than test for it. Perhaps. But regardless of whether it's a test or coercion, if it's in RawConfigParser.set, it prevents non-string use. Perhaps ConfigParser.set should extend RawConfigParser.set with the string test or coercion, leaving RawConfigParser.set as it was before rev 1.65. That may be the best solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 12:10 Message: Logged In: YES user_id=80475 Perhaps, the set() method should coerce to a string rather than test for it. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:14 Message: Logged In: YES user_id=7733 I strongly feel that the 2.3 behavior should be restored, and documented, before 2.4b1. I will do the doc change. I have updated the bug report with links and discussions. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:10 Message: Logged In: YES user_id=7733 Also see the python-dev thread at . The third message in the thread was garbled due to a GPG problem; reproduced below. [Fred L. Drake, Jr.] > David has (properly) been asking me to look into this, and i've > managed not to have enough time. Sorry, David! I thought a python-dev nudge might get you off your keister ;-) > The ConfigParser documentation was certainly too vague, but the > problem, as I see it, is that the module was never intended to store > non-string values. BUT ConfigParser *did* allow non-strings to be stored, for internal use only (can't write them out, of course). And changing it *did* break code. I think a doc change acknowledging that ability but qualifying it ("for internal use only, can't be used to write out config files or interpolate values") would have been a better fix. The change in rev. 1.65 makes ConfigParser.py *less* useful. When I used ConfigParser in Docutils, I wasn't being especially clever when I used it to set non-string values. It will take a lot more cleverness post-rev-1.65 to enable that functionality. Of course, the fix to Docutils is pretty simple: just override ConfigParser.set with the older version. But that depends on private implementation details (self._defaults, self._sections). This is *much* more dangerous and impossible to future-proof against. > I think allowing them is just asking for still more trouble from > that module down the road. Has there been any trouble until now? Why "fix" something that wasn't really broke? The original bug report (http://www.python.org/sf/810843) was really only asking for clarification. It ends with: Nonetheless, I was shocked to see what I thought was a straightforward use of ConfigParser throw off errors. Imagine developers' shock now that we can't do what we want at all! Docutils is not the only project using ConfigParser to store non-strings. I wouldn't be surprised to see other code breaking, which we probably wouldn't find out about until after 2.4-final. > Sure, the module could be made happy by reverting the patch you > cite, but happy-by-accident is a very fragile state to be in. So let's remove the accident, and make the happiness official! >> The comment for bug 810843 says "This is documented behavior", but >> I couldn't find any such documentation pre-dating this change. > > This may have been a bug in my memory. Now that the memory bug is fixed, how about reconsidering the resultant decision? I'll write a doc patch ASAP. -- David Goodger ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:04 Message: Logged In: YES user_id=7733 The alternative is the following change in Docutils. Unfortunately, it requires access to internal implementation details marked with single leading underscores. diff -u -r1.64 frontend.py --- docutils/frontend.py 24 Jul 2004 14:13:38 -0000 1.64 +++ docutils/frontend.py 24 Aug 2004 15:01:32 -0000 @@ -637,6 +637,22 @@ section_dict[option] = self.get(section, option, raw=1) return section_dict + def set(self, section, option, value): + """ + Set an option. + + Overrides stdlib ConfigParser's set() method to allow non-string + values. Required for compatibility with Python 2.4. + """ + if not section or section == CP.DEFAULTSECT: + sectdict = self._defaults + else: + try: + sectdict = self._sections[section] + except KeyError: + raise CP.NoSectionError(section) + sectdict[self.optionxform(option)] = value + class ConfigDeprecationWarning(DeprecationWarning): """Warning for deprecated configuration file features.""" ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Wed Aug 25 05:34:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 05:34:59 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 08:30 Message generated for change (Settings changed) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 23:34 Message: Logged In: YES user_id=7733 [rhettinger] > Perhaps, the set() method should coerce to a string rather > than test for it. Perhaps. But regardless of whether it's a test or coercion, if it's in RawConfigParser.set, it prevents non-string use. Perhaps ConfigParser.set should extend RawConfigParser.set with the string test or coercion, leaving RawConfigParser.set as it was before rev 1.65. That may be the best solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 12:10 Message: Logged In: YES user_id=80475 Perhaps, the set() method should coerce to a string rather than test for it. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:14 Message: Logged In: YES user_id=7733 I strongly feel that the 2.3 behavior should be restored, and documented, before 2.4b1. I will do the doc change. I have updated the bug report with links and discussions. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:10 Message: Logged In: YES user_id=7733 Also see the python-dev thread at . The third message in the thread was garbled due to a GPG problem; reproduced below. [Fred L. Drake, Jr.] > David has (properly) been asking me to look into this, and i've > managed not to have enough time. Sorry, David! I thought a python-dev nudge might get you off your keister ;-) > The ConfigParser documentation was certainly too vague, but the > problem, as I see it, is that the module was never intended to store > non-string values. BUT ConfigParser *did* allow non-strings to be stored, for internal use only (can't write them out, of course). And changing it *did* break code. I think a doc change acknowledging that ability but qualifying it ("for internal use only, can't be used to write out config files or interpolate values") would have been a better fix. The change in rev. 1.65 makes ConfigParser.py *less* useful. When I used ConfigParser in Docutils, I wasn't being especially clever when I used it to set non-string values. It will take a lot more cleverness post-rev-1.65 to enable that functionality. Of course, the fix to Docutils is pretty simple: just override ConfigParser.set with the older version. But that depends on private implementation details (self._defaults, self._sections). This is *much* more dangerous and impossible to future-proof against. > I think allowing them is just asking for still more trouble from > that module down the road. Has there been any trouble until now? Why "fix" something that wasn't really broke? The original bug report (http://www.python.org/sf/810843) was really only asking for clarification. It ends with: Nonetheless, I was shocked to see what I thought was a straightforward use of ConfigParser throw off errors. Imagine developers' shock now that we can't do what we want at all! Docutils is not the only project using ConfigParser to store non-strings. I wouldn't be surprised to see other code breaking, which we probably wouldn't find out about until after 2.4-final. > Sure, the module could be made happy by reverting the patch you > cite, but happy-by-accident is a very fragile state to be in. So let's remove the accident, and make the happiness official! >> The comment for bug 810843 says "This is documented behavior", but >> I couldn't find any such documentation pre-dating this change. > > This may have been a bug in my memory. Now that the memory bug is fixed, how about reconsidering the resultant decision? I'll write a doc patch ASAP. -- David Goodger ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:04 Message: Logged In: YES user_id=7733 The alternative is the following change in Docutils. Unfortunately, it requires access to internal implementation details marked with single leading underscores. diff -u -r1.64 frontend.py --- docutils/frontend.py 24 Jul 2004 14:13:38 -0000 1.64 +++ docutils/frontend.py 24 Aug 2004 15:01:32 -0000 @@ -637,6 +637,22 @@ section_dict[option] = self.get(section, option, raw=1) return section_dict + def set(self, section, option, value): + """ + Set an option. + + Overrides stdlib ConfigParser's set() method to allow non-string + values. Required for compatibility with Python 2.4. + """ + if not section or section == CP.DEFAULTSECT: + sectdict = self._defaults + else: + try: + sectdict = self._sections[section] + except KeyError: + raise CP.NoSectionError(section) + sectdict[self.optionxform(option)] = value + class ConfigDeprecationWarning(DeprecationWarning): """Warning for deprecated configuration file features.""" ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Wed Aug 25 07:50:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 07:50:04 2004 Subject: [ python-Bugs-1015792 ] __setitem__ for __dict__ ignored Message-ID: Bugs item #1015792, was opened at 2004-08-25 11:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015792&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Viktor A Danilov (vdanilov) Assigned to: Nobody/Anonymous (nobody) Summary: __setitem__ for __dict__ ignored Initial Comment: In python 2.3.3 this code cause assertion: class d(dict): _is_setted = None def __setitem__(self, k, v): self._is_setted = 1 class test: def __init__(self): self.__dict__ = d() t = test() t.x = 2 assert t.__dict__._is_setted == 1, 'no `__setitem__` calls' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015792&group_id=5470 From noreply at sourceforge.net Wed Aug 25 08:26:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 08:26:33 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 11:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 >Status: Open >Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 08:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 20:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 12:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 09:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 06:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 20:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 20:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 10:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 17:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 17:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 19:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 19:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 16:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 18:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 04:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 21:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 12:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 04:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 20:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 13:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 14:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 09:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 20:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 02:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 00:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 16:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 08:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 01:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 19:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 20:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Wed Aug 25 08:30:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 08:30:44 2004 Subject: [ python-Bugs-1015792 ] __setitem__ for __dict__ ignored Message-ID: Bugs item #1015792, was opened at 2004-08-25 00:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015792&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Viktor A Danilov (vdanilov) Assigned to: Nobody/Anonymous (nobody) Summary: __setitem__ for __dict__ ignored Initial Comment: In python 2.3.3 this code cause assertion: class d(dict): _is_setted = None def __setitem__(self, k, v): self._is_setted = 1 class test: def __init__(self): self.__dict__ = d() t = test() t.x = 2 assert t.__dict__._is_setted == 1, 'no `__setitem__` calls' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-25 01:30 Message: Logged In: YES user_id=80475 Underneath the hood, test's setattr is accessing the dictionary directly instead of going through its __setattr__ slot. While this one is fixable, I'm not sure it's really a bug. There are no documentation promises that things like setattr won't make direct accesses to the underlying dictionary. Python's implementation has tons of direct access code -- the reasons include clarity, speed, avoidance of hard to debug code paths, or just not having been looked at in this way. In any case, I would not have expected old style classes like 'test' to know about new style subclasses. For the use cases modeled after the OP's code, overiding setattr in 'test' is likely the way to go. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015792&group_id=5470 From noreply at sourceforge.net Wed Aug 25 10:11:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 10:11:57 2004 Subject: [ python-Bugs-991962 ] Building with --disable-toolbox-glue fails Message-ID: Bugs item #991962, was opened at 2004-07-16 00:20 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Building with --disable-toolbox-glue fails Initial Comment: Building with --disable-toolbox-glue fails, because setup.py still tries to build lots of MacOSX extension modules (which fails). There's a define USE_TOOLBOX_OBJECT_GLUE in pyconfig.h that shows whether we're building with or without toolbox glue, but distutils needs to look at that. If it can, otherwise we need a flag in the Makefile too. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2004-08-25 10:11 Message: Logged In: YES user_id=45365 It works for me! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-24 23:48 Message: Logged In: YES user_id=357491 Attached is a diff for setup.py that leaves out the Mac directories from compilation and skips building all Mac-specific modules if --disable- toolbox-glue is specified. If anyone thinks I am missing a step (didn't bother checking for --disable-framework since I doubt it can build without the toolbox glue being enabled) then please say so. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-17 01:16 Message: Logged In: YES user_id=357491 Can we add ``"--disable-toolbox-glue" not in distutils.sysconfig.get_config_var("CONFIG_ARGS")`` as part of the conditional? That should prevent unneeded compiling. If that does work the question becomes whether that should be part of the conditional for all the modules in setup.py or only some of them. Personally I say get rid all of them since if you are building with -- disable-toolbox-glue I would suspect you want a simple UNIX version of Python and not really have anything to do with OS X-specific features. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 21:32 Message: Logged In: YES user_id=357491 It seems like we need some way to either have access in Python to what the arguments to Configure were or what macro defs pyconfig.h comes up with. That would be enough info to find out if compiling with toolbox glue we turned off. Otherwise I don't know how Distutils could possibly get access without somehow parsing pyconfig.h to look to see what is set and what isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 From noreply at sourceforge.net Wed Aug 25 11:39:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 11:39:47 2004 Subject: [ python-Bugs-1015517 ] readline broken Message-ID: Bugs item #1015517, was opened at 2004-08-24 21:44 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015517&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Neal Norwitz (nnorwitz) Summary: readline broken Initial Comment: The readline module seems to broken in current CVS (see the attached build log). ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-08-25 11:39 Message: Logged In: YES user_id=89016 readline.c compiles again. Thanks for the quick fix! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 03:20 Message: Logged In: YES user_id=33168 Walter, I think I fixed this problem. Let me know if it doesn't work for you since I can't test it. Checked in as: Modules/readline.c 2.77 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015517&group_id=5470 From noreply at sourceforge.net Wed Aug 25 14:25:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 14:25:17 2004 Subject: [ python-Bugs-1015937 ] os.system segmentation fault Message-ID: Bugs item #1015937, was opened at 2004-08-25 09:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: os.system segmentation fault Initial Comment: System used: Linux Fedora Core 2. Python version: Python 2.3.3 (#1, May 7 2004, 10:31:40) ------------------------------------------------ Depending on the build used for Java, its invocation through os.system within a thread causes a segmentation fault. The attached short program illustrates this problem. Any Java class 'DoNothing.class' (also attached) in the current directory will do. Notice that only the second one of the two builds 04 and 05 causes this problem. It migh be a Java problem but I tried the same thing with pthreads in C, and no problems occured. -- Tomasz Kowaltowski ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 From noreply at sourceforge.net Wed Aug 25 18:09:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 18:10:00 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2004-08-25 16:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 06:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 18:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 10:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 05:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 04:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 17:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 16:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 16:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 08:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 16:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 16:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 18:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 18:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 15:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 17:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 03:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 19:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 10:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 02:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 18:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 11:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 12:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 07:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 18:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 00:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 22:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 14:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 06:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 17:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 18:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 12:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Wed Aug 25 18:26:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 18:26:53 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2004-08-25 16:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 16:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 06:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 18:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 10:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 05:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 04:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 17:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 16:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 16:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 08:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 16:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 16:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 18:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 18:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 15:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 17:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 03:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 19:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 10:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 02:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 18:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 11:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 12:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 07:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 18:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 00:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 22:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 14:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 06:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 17:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 18:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 12:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Wed Aug 25 18:59:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 18:59:32 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Wed Aug 25 19:30:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 19:30:51 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2004-08-25 17:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 16:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 16:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 06:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 18:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 10:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 05:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 04:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 17:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 16:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 16:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 08:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 16:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 16:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 18:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 18:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 15:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 17:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 03:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 19:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 10:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 02:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 18:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 11:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 12:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 07:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 18:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 13:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 00:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 22:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 14:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 06:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 23:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 17:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 18:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 12:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Wed Aug 25 20:05:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 20:05:20 2004 Subject: [ python-Bugs-1016181 ] "reversed" gives its name as "reverse" in docstring Message-ID: Bugs item #1016181, was opened at 2004-08-25 19:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016181&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hamish Lawson (hamishlawson) Assigned to: Nobody/Anonymous (nobody) Summary: "reversed" gives its name as "reverse" in docstring Initial Comment: The new "reversed" builtin incorrectly gives its name as "reverse" in its docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016181&group_id=5470 From noreply at sourceforge.net Wed Aug 25 21:42:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 21:42:21 2004 Subject: [ python-Bugs-1016181 ] "reversed" gives its name as "reverse" in docstring Message-ID: Bugs item #1016181, was opened at 2004-08-25 13:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016181&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hamish Lawson (hamishlawson) Assigned to: Nobody/Anonymous (nobody) Summary: "reversed" gives its name as "reverse" in docstring Initial Comment: The new "reversed" builtin incorrectly gives its name as "reverse" in its docstring. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-25 14:42 Message: Logged In: YES user_id=80475 Fixed. Thanks for the bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016181&group_id=5470 From noreply at sourceforge.net Wed Aug 25 21:45:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 21:46:37 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 11:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) >Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 21:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 19:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 18:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 18:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 18:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 08:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 20:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 12:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 09:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 07:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 06:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 20:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 20:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 19:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 18:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 18:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 10:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 17:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 17:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 19:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 19:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 16:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 18:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-31 04:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 21:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 12:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-23 04:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 20:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 13:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 14:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 09:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 20:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 02:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 00:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 16:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 08:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 01:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 19:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 20:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Wed Aug 25 22:30:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 22:30:49 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Wed Aug 25 22:34:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 25 22:34:47 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Aug 26 00:02:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 00:02:32 2004 Subject: [ python-Bugs-1015937 ] os.system segmentation fault Message-ID: Bugs item #1015937, was opened at 2004-08-25 08:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: os.system segmentation fault Initial Comment: System used: Linux Fedora Core 2. Python version: Python 2.3.3 (#1, May 7 2004, 10:31:40) ------------------------------------------------ Depending on the build used for Java, its invocation through os.system within a thread causes a segmentation fault. The attached short program illustrates this problem. Any Java class 'DoNothing.class' (also attached) in the current directory will do. Notice that only the second one of the two builds 04 and 05 causes this problem. It migh be a Java problem but I tried the same thing with pthreads in C, and no problems occured. -- Tomasz Kowaltowski ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 18:02 Message: Logged In: YES user_id=33168 This sounds like an environment problem. I'm guessing that the stack is being blown and the kernel is killing the process. It's java that's dying, not python, correct? I don't have _05. _04 works fine for me one Fedora 1. Can you use strace or gdb to try to determine what's happening? I'm not sure if anyone will be able to reproduce this problem. Can you also try starting java with options to lower the the memory consumption, e.g., -Xss -Xmx. >From your shell you can also try raising stack size, etc with ulimit. This may get java to run ok. -s changes the stack size. BTW, what does ulimit -a report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 From noreply at sourceforge.net Thu Aug 26 02:04:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 02:04:20 2004 Subject: [ python-Bugs-1015937 ] os.system segmentation fault Message-ID: Bugs item #1015937, was opened at 2004-08-25 09:25 Message generated for change (Comment added) made by kowaltowski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: os.system segmentation fault Initial Comment: System used: Linux Fedora Core 2. Python version: Python 2.3.3 (#1, May 7 2004, 10:31:40) ------------------------------------------------ Depending on the build used for Java, its invocation through os.system within a thread causes a segmentation fault. The attached short program illustrates this problem. Any Java class 'DoNothing.class' (also attached) in the current directory will do. Notice that only the second one of the two builds 04 and 05 causes this problem. It migh be a Java problem but I tried the same thing with pthreads in C, and no problems occured. -- Tomasz Kowaltowski ---------------------------------------------------------------------- >Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-25 21:04 Message: Logged In: YES user_id=185428 I tried all these things. Adding 'strace' to the command line to be executed reports a segmentation fault which was already expected because of the error code 11 printed by the Python test program. 'ulimit -a' reports everything that counts unlimited. I also tried Java memory options without any success. You are right -- it is the java that is dying not Python, but it only happens under this unusual circumstance. It seems to me that if it were an environment problem it would happen within any call of os.system. It happens however only within Python threads: I tested both packages 'thread' and 'threading' and they both had the same behavior. It does not happen if no threads are envolved, or if threads are programmed in C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 19:02 Message: Logged In: YES user_id=33168 This sounds like an environment problem. I'm guessing that the stack is being blown and the kernel is killing the process. It's java that's dying, not python, correct? I don't have _05. _04 works fine for me one Fedora 1. Can you use strace or gdb to try to determine what's happening? I'm not sure if anyone will be able to reproduce this problem. Can you also try starting java with options to lower the the memory consumption, e.g., -Xss -Xmx. >From your shell you can also try raising stack size, etc with ulimit. This may get java to run ok. -s changes the stack size. BTW, what does ulimit -a report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 From noreply at sourceforge.net Thu Aug 26 04:23:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 04:23:48 2004 Subject: [ python-Bugs-991962 ] Building with --disable-toolbox-glue fails Message-ID: Bugs item #991962, was opened at 2004-07-15 15:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 Category: Macintosh >Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Brett Cannon (bcannon) Summary: Building with --disable-toolbox-glue fails Initial Comment: Building with --disable-toolbox-glue fails, because setup.py still tries to build lots of MacOSX extension modules (which fails). There's a define USE_TOOLBOX_OBJECT_GLUE in pyconfig.h that shows whether we're building with or without toolbox glue, but distutils needs to look at that. If it can, otherwise we need a flag in the Makefile too. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-25 19:23 Message: Logged In: YES user_id=357491 rev. 1.199 on HEAD has the fix. I didn't backport to 2.3 since more work needs to be done to get Modules/_localemodule.c to compile without the toolbox glue. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-08-25 01:11 Message: Logged In: YES user_id=45365 It works for me! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-24 14:48 Message: Logged In: YES user_id=357491 Attached is a diff for setup.py that leaves out the Mac directories from compilation and skips building all Mac-specific modules if --disable- toolbox-glue is specified. If anyone thinks I am missing a step (didn't bother checking for --disable-framework since I doubt it can build without the toolbox glue being enabled) then please say so. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-16 16:16 Message: Logged In: YES user_id=357491 Can we add ``"--disable-toolbox-glue" not in distutils.sysconfig.get_config_var("CONFIG_ARGS")`` as part of the conditional? That should prevent unneeded compiling. If that does work the question becomes whether that should be part of the conditional for all the modules in setup.py or only some of them. Personally I say get rid all of them since if you are building with -- disable-toolbox-glue I would suspect you want a simple UNIX version of Python and not really have anything to do with OS X-specific features. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:32 Message: Logged In: YES user_id=357491 It seems like we need some way to either have access in Python to what the arguments to Configure were or what macro defs pyconfig.h comes up with. That would be enough info to find out if compiling with toolbox glue we turned off. Otherwise I don't know how Distutils could possibly get access without somehow parsing pyconfig.h to look to see what is set and what isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991962&group_id=5470 From noreply at sourceforge.net Thu Aug 26 06:37:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 06:37:43 2004 Subject: [ python-Bugs-1015937 ] os.system segmentation fault Message-ID: Bugs item #1015937, was opened at 2004-08-25 08:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: os.system segmentation fault Initial Comment: System used: Linux Fedora Core 2. Python version: Python 2.3.3 (#1, May 7 2004, 10:31:40) ------------------------------------------------ Depending on the build used for Java, its invocation through os.system within a thread causes a segmentation fault. The attached short program illustrates this problem. Any Java class 'DoNothing.class' (also attached) in the current directory will do. Notice that only the second one of the two builds 04 and 05 causes this problem. It migh be a Java problem but I tried the same thing with pthreads in C, and no problems occured. -- Tomasz Kowaltowski ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-26 00:37 Message: Logged In: YES user_id=33168 There's another possibility, but I'm not sure if it would affect your build or not. It's possible to set a smaller stack size when creating a thread. This would mean that THREAD_STACK_SIZE is set. If you look in ./Python/thread_pthread.h you will see the references. THREAD_STACK_SIZE is not set on my box. In your C test, did you pass NULL for the attributes or did you do pthread_attr_init(). It's possible that is the difference between your C test and python. You might try mucking in ./Python/thread_pthread.h to see if you can determine what is happening. ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-25 20:04 Message: Logged In: YES user_id=185428 I tried all these things. Adding 'strace' to the command line to be executed reports a segmentation fault which was already expected because of the error code 11 printed by the Python test program. 'ulimit -a' reports everything that counts unlimited. I also tried Java memory options without any success. You are right -- it is the java that is dying not Python, but it only happens under this unusual circumstance. It seems to me that if it were an environment problem it would happen within any call of os.system. It happens however only within Python threads: I tested both packages 'thread' and 'threading' and they both had the same behavior. It does not happen if no threads are envolved, or if threads are programmed in C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 18:02 Message: Logged In: YES user_id=33168 This sounds like an environment problem. I'm guessing that the stack is being blown and the kernel is killing the process. It's java that's dying, not python, correct? I don't have _05. _04 works fine for me one Fedora 1. Can you use strace or gdb to try to determine what's happening? I'm not sure if anyone will be able to reproduce this problem. Can you also try starting java with options to lower the the memory consumption, e.g., -Xss -Xmx. >From your shell you can also try raising stack size, etc with ulimit. This may get java to run ok. -s changes the stack size. BTW, what does ulimit -a report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 From noreply at sourceforge.net Thu Aug 26 06:43:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 06:43:34 2004 Subject: [ python-Bugs-1015792 ] __setitem__ for __dict__ ignored Message-ID: Bugs item #1015792, was opened at 2004-08-25 01:50 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015792&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Viktor A Danilov (vdanilov) Assigned to: Nobody/Anonymous (nobody) Summary: __setitem__ for __dict__ ignored Initial Comment: In python 2.3.3 this code cause assertion: class d(dict): _is_setted = None def __setitem__(self, k, v): self._is_setted = 1 class test: def __init__(self): self.__dict__ = d() t = test() t.x = 2 assert t.__dict__._is_setted == 1, 'no `__setitem__` calls' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-26 00:43 Message: Logged In: YES user_id=33168 I agree with Raymond. I think this pretty much the design and should not be fixed. Therefore, I'm closing this report. Viktor, if you disagree, you might try discussing this on comp.lang.python or brining up this issue on python-dev. Feel free to comment here if you would like clarifications. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-25 02:30 Message: Logged In: YES user_id=80475 Underneath the hood, test's setattr is accessing the dictionary directly instead of going through its __setattr__ slot. While this one is fixable, I'm not sure it's really a bug. There are no documentation promises that things like setattr won't make direct accesses to the underlying dictionary. Python's implementation has tons of direct access code -- the reasons include clarity, speed, avoidance of hard to debug code paths, or just not having been looked at in this way. In any case, I would not have expected old style classes like 'test' to know about new style subclasses. For the use cases modeled after the OP's code, overiding setattr in 'test' is likely the way to go. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015792&group_id=5470 From noreply at sourceforge.net Thu Aug 26 09:14:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 09:14:31 2004 Subject: [ python-Bugs-1016563 ] urllib2 bug in proxy auth Message-ID: Bugs item #1016563, was opened at 2004-08-26 09:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Mussenbrock (mussenbrock) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 bug in proxy auth Initial Comment: in urllib2.py: line 502 should be: ... user_pass = base64.encodestring('%s:%s' % (unquote (user), unquote(password))).strip() the '.strip()' is missing in the current version ("2.1"). this makes an additonal '\n' at the end of user_pass. So there will be an empty line in the http header, which is buggy. (see also line 645, where the .strip() is right in place!). Best regards, Christoph ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016563&group_id=5470 From noreply at sourceforge.net Thu Aug 26 11:11:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 11:11:53 2004 Subject: [ python-Bugs-1016626 ] distutils support for swig is under par Message-ID: Bugs item #1016626, was opened at 2004-08-26 11:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016626&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Nobody/Anonymous (nobody) Summary: distutils support for swig is under par Initial Comment: To my delight there is support for swig built into distutils. However a few problems exist with the support. - there is no way to specify any extra flags to the swig command (I need -I/usr/include -DHAVE_LONG_LONG); - swig generates two files, the XXX_wrap.c file which is turned into a _XXX.so file, and a XXX.py file. distutils only deals with the XXX_wrap.c file. I have no suggested fix for these problems, but problems they are. (Python from CVS HEAD on Fedora Core 2). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016626&group_id=5470 From noreply at sourceforge.net Thu Aug 26 13:26:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 13:26:31 2004 Subject: [ python-Bugs-1015937 ] os.system segmentation fault Message-ID: Bugs item #1015937, was opened at 2004-08-25 09:25 Message generated for change (Comment added) made by kowaltowski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tomasz Kowaltowski (kowaltowski) Assigned to: Nobody/Anonymous (nobody) Summary: os.system segmentation fault Initial Comment: System used: Linux Fedora Core 2. Python version: Python 2.3.3 (#1, May 7 2004, 10:31:40) ------------------------------------------------ Depending on the build used for Java, its invocation through os.system within a thread causes a segmentation fault. The attached short program illustrates this problem. Any Java class 'DoNothing.class' (also attached) in the current directory will do. Notice that only the second one of the two builds 04 and 05 causes this problem. It migh be a Java problem but I tried the same thing with pthreads in C, and no problems occured. -- Tomasz Kowaltowski ---------------------------------------------------------------------- >Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-26 08:26 Message: Logged In: YES user_id=185428 I did not find the file 'thread_pthread.h' under my installation :-(. My program in C is: ---------------------------------------------------------- #include #include #include void *ExecuteCommand( void *ptr ) { char *command = ptr; int result = system(command); printf("Tested the command: %s; result = %d\n",command,result); return NULL; } int main() { pthread_t thread; pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_04/bin/java -cp . DoNothing"); pthread_join(thread,NULL); pthread_create(&thread,NULL,ExecuteCommand, (void*)"/usr/java/j2sdk1.4.2_05/bin/java -cp . DoNothing"); pthread_join(thread,NULL); return 0; } ---------------------------------------------------------- It correctly prints 0 for both threads. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-26 01:37 Message: Logged In: YES user_id=33168 There's another possibility, but I'm not sure if it would affect your build or not. It's possible to set a smaller stack size when creating a thread. This would mean that THREAD_STACK_SIZE is set. If you look in ./Python/thread_pthread.h you will see the references. THREAD_STACK_SIZE is not set on my box. In your C test, did you pass NULL for the attributes or did you do pthread_attr_init(). It's possible that is the difference between your C test and python. You might try mucking in ./Python/thread_pthread.h to see if you can determine what is happening. ---------------------------------------------------------------------- Comment By: Tomasz Kowaltowski (kowaltowski) Date: 2004-08-25 21:04 Message: Logged In: YES user_id=185428 I tried all these things. Adding 'strace' to the command line to be executed reports a segmentation fault which was already expected because of the error code 11 printed by the Python test program. 'ulimit -a' reports everything that counts unlimited. I also tried Java memory options without any success. You are right -- it is the java that is dying not Python, but it only happens under this unusual circumstance. It seems to me that if it were an environment problem it would happen within any call of os.system. It happens however only within Python threads: I tested both packages 'thread' and 'threading' and they both had the same behavior. It does not happen if no threads are envolved, or if threads are programmed in C. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-25 19:02 Message: Logged In: YES user_id=33168 This sounds like an environment problem. I'm guessing that the stack is being blown and the kernel is killing the process. It's java that's dying, not python, correct? I don't have _05. _04 works fine for me one Fedora 1. Can you use strace or gdb to try to determine what's happening? I'm not sure if anyone will be able to reproduce this problem. Can you also try starting java with options to lower the the memory consumption, e.g., -Xss -Xmx. >From your shell you can also try raising stack size, etc with ulimit. This may get java to run ok. -s changes the stack size. BTW, what does ulimit -a report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015937&group_id=5470 From noreply at sourceforge.net Thu Aug 26 15:58:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 15:58:17 2004 Subject: [ python-Bugs-1016880 ] urllib.urlretrieve silently truncates downloads Message-ID: Bugs item #1016880, was opened at 2004-08-26 08:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlretrieve silently truncates downloads Initial Comment: The following script appears to be unreliable on all versions of Python we can find. The file being downloaded is approximately 34 MB. Browsers such as IE and Mozilla have no problem downloading the whole thing. ---- import urllib import os os.chdir('/tmp') urllib.urlretrieve ('http://cvs.sourceforge.net/cvstarballs/boost- cvsroot.tar.bz2', 'boost-cvsroot.tar.bz2') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 From noreply at sourceforge.net Thu Aug 26 18:49:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 18:50:20 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 05:21 Message generated for change (Comment added) made by squeen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 12:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 15:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 12:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 12:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 12:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 02:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 14:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 06:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 03:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 01:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 00:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 14:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 14:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 13:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 12:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 12:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 04:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 11:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 11:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 13:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 13:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 10:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 12:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 22:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 15:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 06:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 22:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 14:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 07:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 08:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 03:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 14:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 20:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 18:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 10:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 02:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 19:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 13:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 14:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 08:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Aug 26 18:50:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 18:51:09 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 05:21 Message generated for change (Comment added) made by squeen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 12:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 12:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 16:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 15:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 12:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 12:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 12:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 02:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 14:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 06:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 03:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 01:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-27 00:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 14:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 14:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 13:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 12:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 12:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 04:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 11:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 11:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 13:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 13:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 10:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 12:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 22:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 15:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 06:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 22:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 14:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 07:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 08:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 03:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 14:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 20:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 18:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 10:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 02:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 19:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 13:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 14:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 08:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Aug 26 19:03:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 19:04:46 2004 Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Trent Mick (tmick) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-26 10:03 Message: Logged In: YES user_id=71407 > I still see compile errors in bsddbmodule.c and _ssl.c > during to missing types for u_short, u_int, u_long, etc. Yesterday I noticed that bsddbmodule.c compiles correctly with the latest Python CVS. Maybe this is because the latest pyconfig.h defines this: #define _BSD_TYPES You could try adding this to the top of bsddbmodule.c in Python 2.3.4. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:50 Message: Logged In: YES user_id=883896 Oops, previous message should have read: ... applied your patch and socketmodule is NOW working in Python 2.3.4 for me. Sorry. ---------------------------------------------------------------------- Comment By: Steven Queen (squeen) Date: 2004-08-26 09:49 Message: Logged In: YES user_id=883896 I just ran into this same problem using the MIPSpro 7.4.2 compiler under IRIX 6.5.23. I applied your patch and socketmodule is not working in Python 2.3.4 for me. THANK YOU. I still see compile errors in bsddbmodule.c and _ssl.c during to missing types for u_short, u_int, u_long, etc. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=71407 I forgot to mention that the patch and the patched file are also available here, along with the original code: http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_c http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atch http://cci.lbl.gov/~rwgk/bugs/python/socketmodule_r1_303_p atched_c ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 13:30 Message: Logged In: YES user_id=71407 I will attach a complete patch for SGI, based on Trent's work. I've tested on these platforms: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.25 with MIPRpro 7.3.1.3 RedHat 8.0, gcc 3.2 Comments: - Trent's fragment has a small error: __SS_ALIGNSIZE, should be _SS_ALIGNSIZE. Other than that it was fine. - I guess the Python 2.3 maintenance branch should also be patched to correct my flaw. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-25 12:45 Message: Logged In: YES user_id=21627 tmick, from inspection only, your last patch seems clear and correct - especially as it has comments in it :-) I would leave the OS/2 part out - I somewhat doubt that any compiler on that platform provides EAI_*, and even if it would: addrinfo.h typically ends up empty if the system has "proper" getaddrinfo support, so including it should not hurt even on systems where it isn't used. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 10:30 Message: Logged In: YES user_id=34892 Would ifdef'ery like the following be a little bit more clear and still work? /* include Python's addrinfo.h unless it causes trouble */ #if defined(__sgi) && _COMPILER_VERSION>700 && defined(__SS_ALIGNSIZE) /* Do not include addinfo.h on some newer IRIX versions. * __SS_ALIGNSIZE is defined in sys/socket.h by 6.5.21, * for example, but not by 6.5.10. */ #elif defined(_MSC_VER) && _MSC_VER>1200 /* Do not include addrinfo.h for MSVC7 or greater. * addrinfo and EAI_* constants are defined in ws2tcpip.h */ #else # include "addrinfo.h" #endif ...an additional #elif block might be necessary for OS/2 EMX (but let's figure that out later). Ralf, Would you be able to try a Python build with the latest Python CVS and replace the bare #include "addrinfo.h" on line 260 of socketmodule.c with the above block. Does that work for you? If so then I think this should be a basis for a corrected patch for socketmodule.c. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-08-25 09:59 Message: Logged In: YES user_id=71407 Mick is right. Unfortunately my patch from May had a flaw. It should have been something along the lines of #if !defined(__sgi) || (_COMPILER_VERSION>700 && !defined (_SS_ALIGNSIZE)) # include "addrinfo.h" #endif Sorry for the oversight. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:26 Message: Logged In: YES user_id=34892 I am using this block in my builds. I *think* that this preserves the intentions of the IRIX and MSVC6 patches and am less sure about the OS/2 EMX-related part (see the python-dev thread for a reference). #if defined(__sgi) # if _COMPILER_VERSION>700 && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #elif defined(PYOS_OS2) # if defined(PYCC_GCC) # include "addrinfo.h" # endif #elif defined(_MSC_VER) # if _MSC_VER == 1200 # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2004-08-25 09:09 Message: Logged In: YES user_id=34892 Related thread on python-dev: http://mail.python.org/pipermail/python-dev/2004-August/048341.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-24 23:26 Message: Logged In: YES user_id=21627 Indeed, this broke a number of platforms, so I backed it out. ---------------------------------------------------------------------- Comment By: John Ehresman (jpe) Date: 2004-07-10 11:41 Message: Logged In: YES user_id=22785 This seems to break the building of CVS HEAD sources on windows with VC++ 6 because addrinfo.h is not included and HAVE_GETADDRINFO is not defined in my build. It also may break on other platforms where HAVE_GETADDRINFO is not defined. Maybe addrinfo.h should be included if not on sgi. I know that VC++ 6 isn't the primary compiler for Python 2.4, but it works otherwise and it presumably will be the primary compiler for 2.3.5. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-27 03:28 Message: Logged In: YES user_id=6656 Closing! ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-27 00:17 Message: Logged In: YES user_id=29957 There's a note on the 2.3.4 bugs page pointing at this bug. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-05-26 22:41 Message: Logged In: YES user_id=29957 If the patch is good, I'll make sure it's included in the 2.3.4 'bugs' page. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 21:14 Message: Logged In: YES user_id=71407 > Can you try gmake? Yes, it works with gmake. I've verified that the socket module on the CVS head builds and runs correctly on the three platforms mentioned in my message from 2004-05- 22 01:23. There are not even warnings. > Is IRIX make particularly braindead? I don't think so. It works with most auto-configured packages incl. all earlier versions of Python. But I'll save this for another day when the first 2.4 beta release is out. Thank you for your help! I think this tracker issue should be closed. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 11:19 Message: Logged In: YES user_id=6656 Uh, that's odd. Is IRIX make particularly braindead? Can you try gmake? Maybe we've let something non-portable slip in. At any rate, I think this should be done in a separate report... ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 11:14 Message: Logged In: YES user_id=71407 I checked out the python cvs head from scratch and ran configure in the usual way, with the usual result. However, make doesn't work: % make don't know how to make Parser/printgrammar.o (bu42). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 10:07 Message: Logged In: YES user_id=6656 OK, so I've commited revision 1.289 of Modules/socketmodule.c. Can you check if CVS HEAD works for you now? ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-26 09:59 Message: Logged In: YES user_id=71407 > Is there any chance of the Right Thing actually happening? The experience of the last 13 months suggests "No." SGI's freeware team has not responded to my report for more than a year. I am absolutely not a SGI or socket expert. I only worked on the patch because I was desperate enough and because Maik had already done the groundwork. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-05-26 09:27 Message: Logged In: YES user_id=6656 Is this really The Right Thing? I still see /* XXX Using _SGIAPI is the wrong thing, but I don't know what the right thing is. */ Is there any chance of the Right Thing actually happening? If not, I'll check this into HEAD, and if that seems to work, move it to release23-maint in time for 2.3.5. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-05-22 01:23 Message: Logged In: YES user_id=71407 Based on Maik's posting from 2004-03-08 08:53 I've worked out a small bug-fix patch relative to Python-2.3.4c1 that leads to successful creation of _socket.so under three different versions of IRIX: 6.5.10 with MIPSpro 7.3.1.2 6.5.21 with MIPSpro 7.41 6.5.23 with MIPRpro 7.3.1.3 I've consistently used #if defined(__sgi) && _COMPILER_VERSION>700 to restrict the changes to IRIX. However, to be sure I've also verified that the Python installation is still OK under Redhat 8 and Tru64 Unix 5.1. I will upload the patch. It is also available here: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patch For completeness I've also posted these files: http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_patched_c http://cci.lbl.gov/~rwgk/bugs/python/py234c1_socketmod ule_original_c I've made an effort to keep the patch minimally intrusive, but it is certainly not "clean." However, the status quo is so bad that it can only get better. We have not been able to switch to Python 2.3 because of the problems with the socket module. It would be fantastic if the bug-fix patch could be included in the 2.3.4 final distribution. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2004-03-08 08:53 Message: Logged In: YES user_id=768223 I got Python 2.3.3 compiled with MipsPro Compilers: Version 7.3.1.3m. The following changes were made to satisfy all needs. Line 206 in Modules/socketmodule.c #define _SGIAPI 1 NEW: #undef _XOPEN_SOURCE NEW: #define HAVE_GETADDRINFO 1 NEW: #define HAVE_GETNAMEINFO 1 #define HAVE_INET_PTON NEW: #include NEW: #include NEW: #include #include Line 269: /* #include "addrinfo.h" */ In addition to this I extend the CFLAGS with -D_BSD_TYPES to satisfy the u_short and friends definition. --maik./ ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-03-03 08:20 Message: Logged In: YES user_id=892601 Got it down to one error: % > ./python Lib/test/test_socket.py Traceback (most recent call last): File "Lib/test/test_socket.py", line 6, in ? import socket File "/usr/local/spider/lib/python2.3/socket.py", line 44, in ? import _socket ImportError: 210454:./python: rld: Fatal Error: unresolvable symbol in /usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so: _xpg5_accept xpg5_accept does appear in any library on our SGI's that are only 1-2 years old. It does appear in libc in very recent revisions of Irix (> 6.5.19?) Does anyone know how to get Python 2.3 to avoid the use of xpg5_accept? Thanks ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2004-01-12 10:59 Message: Logged In: YES user_id=892601 Has anyone encountered problems with different versions of IRIX 6.5? I finally got sockets to work in Python2.3.3, but only on the most up-to-date version of IRIX (uname -v = 01100304). On any other machine with a lower version (archetecture doesn't seem to matter), I get messages which all seem to be related to sockets: 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_vsnprintf 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recv 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_connect 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_bind 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_sendto 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_setsockopt 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_accept 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_recvfrom 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_socket 152272:python2.3: rld: Error: unresolvable symbol in python2.3: _xpg5_getsockname Upgrading all of our SGIs is not something I have control over. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-22 10:52 Message: Logged In: YES user_id=768223 Sorry if there is something unclear. Redefine means: Set a value which is required to satisfy ifdef-statements in the header files. As you see in the definitions, given in the comment, the value for _NO_XOPEN4 is set as a result of some dependencies automatically defined. A redefinition of _SGIAPI in the socketmodule.c is not sufficient alone. Therefore to satisfy all requirements in the header files, you should set the values for _NO_XOPEN4 and _NO_XOPEN5 also manually. Howto do in socketmodule.c? ... #define _SGIAPI 1 #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 ... If you are familiar with regular expressions, then you will know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4, _NO_XOPEN5. Sorry if there was something wrong in my comment. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-12-22 07:49 Message: Logged In: YES user_id=892601 Can someone please clarify mherta's comment from 2003-12-16? How should we "redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition"? Should those lines of code be added to socketmodule.c, or are they the source of the problem? Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5] or are they all different? Thanks. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-12-16 09:27 Message: Logged In: YES user_id=768223 I've tested the latest Python 2.3.3c1 to compile. The problem reported is still present. To avoid the error messages, about the incompatible types of several netdb-functions (like inet_pton), you should redefine _NO_XOPEN[45] in the socketmodule.c at the same position like the _SGIAPI redefinition. If there are error messages that types like u_short and u_char are not defined, please add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay). If anybody don't need a executable compiled with MipsPro, gcc from the freeware.sgi.com could be a choice. The problem for this seems in /usr/include/standards.h: #define _NO_XOPEN4 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 >= 500))) #define _NO_XOPEN5 (!defined(_XOPEN_SOURCE) || (defined(_XOPEN_SOURCE) && (_XOPEN_SOURCE+0 < 500))) As the first option is true (_XOPEN_SOURCE is set to 600 in pyconfig.h) the second option will be false. The constant #define NI_NUMERICHOST 0x00000002 /* return numeric form of hostname */ is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5 (/usr/include/netdb.h) which is always false. In the manual pages there is a example which uses the constant NI_NUMERICHOST and compiles without error message. I'm not sure to cut off the file pyconfig.h from compiling the socketmodule.c? Any comments? ---------------------------------------------------------------------- Comment By: Hans Nowak (zephyrfalcon) Date: 2003-10-30 19:04 Message: Logged In: YES user_id=173607 My $0.02... Yesterday I successfully compiled Python 2.3.2, with socket module. I'm using an O2 running IRIX 6.5.11f. I didn't encounter any of the problems described before, and had no problems with _SGIAPI or anything. The reason it didn't compile was that u_long and u_char were not defined in some places; /usr/include/netinet/tcp.h to be precise, and a Python file (getaddrinfo.c). I'm using gcc 3.3 (the one downloaded from freeware.sgi.com). If anyone is interested, drop me a mail at hans at zephyrfalcon.org and I'll put the binary online somewhere. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-24 12:59 Message: Logged In: YES user_id=892601 Here's the output from 'gmake', using MIPSpro Compiler 7.30 on IRIX 6.5 Sorry, I don't know how to attach something using the "Add a Comment" box. Is there another way to post? The patch at www.python.org/2.3.2/patches/sgi-socketmodule.patch was edited into socketmodule.c : #include <netdb.h> #endif /* GCC 3.2 on Irix 6.5 fails to define this variable at all. Based on the above code, I'd say that the SGI headers are just horked. */ #if defined(__sgi) && !defined(INET_ADDRSTRLEN) #define INET_ADDRSTRLEN 16 #endif /* Generic includes */ #include <sys/types.h> #include <signal.h> --------------------------------------------------------------------------- cc -OPT:Olimit=0 -DNDEBUG -n32 -O -I. -I./Include -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line = 195 Macro "_SGIAPI" (declared at line 210 of "/usr/include/standards.h") has an incompatible redefinition. #define _SGIAPI 1 ^ cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198 The identifier "socklen_t" is undefined. extern int iruserok_sa(const void *, socklen_t, int, const char *, ^ cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145 Macro "_SS_ALIGNSIZE" (declared at line 246 of "/usr/include/sys/socket.h") has an incompatible redefinition. #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG)) ^ cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line = 822 The identifier "NI_NUMERICHOST" is undefined. NI_NUMERICHOST); ^ cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line = 3054 A value of type "int" cannot be assigned to an entity of type "const char *". retval = inet_ntop(af, packed, ip, sizeof(ip)); ^ 3 errors detected in the compilation of "./Modules/socketmodule.c". gmake: *** [Modules/socketmodule.o] Error 2 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-23 03:25 Message: Logged In: YES user_id=6656 Just to be clear, please "attach" the build rather than pasting it inline. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 19:19 Message: Logged In: YES user_id=29957 Did you try 2.3.2 with the patch from the 2.3.2 build bugs page? If it failed, please post the build log of the failing bit to this bug. ---------------------------------------------------------------------- Comment By: Bill Baxter (billbaxter26) Date: 2003-10-22 11:26 Message: Logged In: YES user_id=892601 Has there been any progress since August on getting Python-2.3 to compile on IRIX 6.5? I really need to have sockets working to use python. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 04:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include <sys/types> #include <sys/socket> #include <netinet/in.h> #include <netdb.h> So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 05:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" <bcasavan@sgi.com> To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include <optional_sym.h> #include <header_file_for_some_new_symbol.h> . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include <standards.h> in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Aug 26 19:10:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 19:10:50 2004 Subject: [ python-Bugs-1016880 ] urllib.urlretrieve silently truncates downloads Message-ID: Bugs item #1016880, was opened at 2004-08-26 08:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None >Priority: 6 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlretrieve silently truncates downloads Initial Comment: The following script appears to be unreliable on all versions of Python we can find. The file being downloaded is approximately 34 MB. Browsers such as IE and Mozilla have no problem downloading the whole thing. ---- import urllib import os os.chdir('/tmp') urllib.urlretrieve ('http://cvs.sourceforge.net/cvstarballs/boost- cvsroot.tar.bz2', 'boost-cvsroot.tar.bz2') ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-26 12:09 Message: Logged In: YES user_id=80475 Confirmed. On Py2.4 (current CVS), I got 12.7 Mb before the connection closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 From noreply at sourceforge.net Thu Aug 26 20:52:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 20:53:07 2004 Subject: [ python-Bugs-1016880 ] urllib.urlretrieve silently truncates downloads Message-ID: Bugs item #1016880, was opened at 2004-08-26 09:58 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 6 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlretrieve silently truncates downloads Initial Comment: The following script appears to be unreliable on all versions of Python we can find. The file being downloaded is approximately 34 MB. Browsers such as IE and Mozilla have no problem downloading the whole thing. ---- import urllib import os os.chdir('/tmp') urllib.urlretrieve ('http://cvs.sourceforge.net/cvstarballs/boost- cvsroot.tar.bz2', 'boost-cvsroot.tar.bz2') ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-26 14:52 Message: Logged In: YES user_id=31435 Hmm. I don't know anything about this, but thought I'd just try it. Didn't chdir(), did add a reporthook: def hook(*args): print args WinXP Pro SP1, current CVS Python, cable modem over a wireless router. Output looked like this: (0, 8192, 34520156) (1, 8192, 34520156) (2, 8192, 34520156) ... (4213, 8192, 34520156) (4214, 8192, 34520156) (4215, 8192, 34520156) Had the whole file when it ended: > wc boost-cvsroot.tar.bz2 125368 765656 34520156 boost-cvsroot.tar.bz2 *Maybe* adding the reporthook changed timing in some crucial way. Don't know. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-26 13:09 Message: Logged In: YES user_id=80475 Confirmed. On Py2.4 (current CVS), I got 12.7 Mb before the connection closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 From noreply at sourceforge.net Thu Aug 26 21:05:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 21:06:14 2004 Subject: [ python-Bugs-1005113 ] test__locale fails on MacOS X Message-ID: Bugs item #1005113, was opened at 2004-08-07 06:23 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: test__locale fails on MacOS X Initial Comment: test__locale fails on MacOS X. It didn't with Python 2.3. I've written a small C program that can reproduce the problem: ------------ testme.c ------- #include #include int main(void) { char* s; struct lconv* conv; s = setlocale(LC_NUMERIC, "it_IT"); printf("setlocale returned: %s\n", s); conv = localeconv(); printf("conv->decimal_point == %s", conv->decimal_point); return 0; } --------------- Compile this with 'cc -o testme testme.c' and it prints the right anwser. Compile this with 'cc -o testme testme.c -framework Foundation' or 'cc -o testme testme.c -framework CoreServices' and it fails' Python is linked with both frameworks.... ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2004-08-26 12:05 Message: Logged In: YES user_id=357491 Started a thread to discuss trying to deal with this before 2.4.a3 . Can be found at http://mail.python.org/pipermail/python-dev/2004-August/ 048395.html . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-13 10:38 Message: Logged In: YES user_id=357491 They must have removed it between the Tiger test release and now since my friend has checkin rights on that part of the tree at Apple. Regardless, I am leaning towards having setlocale() raise an exception under OS X until we can possibly wrap CF stuff since __setonlyClocaleconv() is obviously not a public function and thus not meant for us to play with. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-12 22:43 Message: Logged In: YES user_id=580910 According to Bob the "feature" is present in the Tiger DP. I haven't checked this myself yet. I also haven't check older versions of the OS. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-12 15:32 Message: Logged In: YES user_id=357491 I just talked to a friend of mine and it looks like the function is gone from Tiger so this might not be a problem in the future. Plus, I don't know if we should be trying to work around this. Perhaps we should try to do this the proper way using CF for locale support? Don't know. At worst we should at least raise an exception for setlocale() . This is getting OS X specific enough to need input from Jack, so assigning to him. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-12 15:19 Message: Logged In: YES user_id=357491 I think modifying configure.in to detect the function is unnecessary; Darwin will be the only platform with it (Googling shows the CVS commit for Darwin that added the call to _CFInitialize() that probably set this whole problem off, so just blanket settting it (unless it is somehow new to OS X 10.3 or something) based on an ``#ifdef __APPLE__`` will probably be fine. But knowing that function was explicitly added in a version would lead to requiring a configure.in check. The next question becomes whether setting that value is a permanent settting in CoreFoundation until it is unloaded, or if it is just per run of an app. If it is the former, then setting it period might be bad since that would affect other running apps. But if Python is loaded against its own copy of CoreFoundation and it is local to Python then who cares; set the thing before any locale code is used and be done with it. And as for accepting a patch, I know I would be happy with accepting it, but I would want Martin v. Lowis' input first to make sure this is the best thing to do. Otherwise setlocale() should be changed to make it always raise an exception when __setonlyClocaleconv() is around. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-12 12:40 Message: Logged In: YES user_id=580910 Many thanks to Bob Ippolito for finding what's going on... It turns out that CoreFoundation.framework calls __setonlyClocaleconv when it is loaded. As the name suggests this breaks the locale API's. I don't know what whoever added this "functionality" was smoking, but at least he had enough sense to make it possible to restore functionality. The prototype for __setonlyClocaleconv is: extern int __setonlyClocaleconv(int val); Experimentation shows that setting val to a non-zero value breaks setlocale and setting it to 0 re-enables setlocale. The function returns the previous setting. This means it is possible to create a workaround for this issue: 1) Add configure and/or weak-linking magic to detect the function 2) Call oldValue = __setonlyClocaleconv(0) before using a locale API 3) Call __setonlyClocaleconv(oldValue) after doing so. Would such a patch be accepted? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-07 12:14 Message: Logged In: YES user_id=357491 Ah! Nick Bastin and I were trying to solve this and noticed that in a straight C program it worked but under Python, no matter where you were, it was incorrect! Thanks for the insight! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2004-08-07 08:10 Message: Logged In: YES user_id=580910 Because this seems to be a bug in OSX I've filed a bug at bugreport.apple.com (radar#3754835) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1005113&group_id=5470 From noreply at sourceforge.net Thu Aug 26 22:04:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 26 22:04:49 2004 Subject: [ python-Bugs-1016880 ] urllib.urlretrieve silently truncates downloads Message-ID: Bugs item #1016880, was opened at 2004-08-26 08:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 6 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlretrieve silently truncates downloads Initial Comment: The following script appears to be unreliable on all versions of Python we can find. The file being downloaded is approximately 34 MB. Browsers such as IE and Mozilla have no problem downloading the whole thing. ---- import urllib import os os.chdir('/tmp') urllib.urlretrieve ('http://cvs.sourceforge.net/cvstarballs/boost- cvsroot.tar.bz2', 'boost-cvsroot.tar.bz2') ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-26 15:04 Message: Logged In: YES user_id=80475 Followed the same procedure (no chdir, add a hook) but bombed out at 9.1Mb: . . . (1117, 8192, 34520156) ('boost-cvsroot.tar.bz2', ) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-26 13:52 Message: Logged In: YES user_id=31435 Hmm. I don't know anything about this, but thought I'd just try it. Didn't chdir(), did add a reporthook: def hook(*args): print args WinXP Pro SP1, current CVS Python, cable modem over a wireless router. Output looked like this: (0, 8192, 34520156) (1, 8192, 34520156) (2, 8192, 34520156) ... (4213, 8192, 34520156) (4214, 8192, 34520156) (4215, 8192, 34520156) Had the whole file when it ended: > wc boost-cvsroot.tar.bz2 125368 765656 34520156 boost-cvsroot.tar.bz2 *Maybe* adding the reporthook changed timing in some crucial way. Don't know. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-26 12:09 Message: Logged In: YES user_id=80475 Confirmed. On Py2.4 (current CVS), I got 12.7 Mb before the connection closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1016880&group_id=5470 From noreply at sourceforge.net Fri Aug 27 04:11:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 04:11:07 2004 Subject: [ python-Bugs-1017329 ] email.Message does not allow iteration Message-ID: Bugs item #1017329, was opened at 2004-08-26 21:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017329&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul McGuire (ptmcg) Assigned to: Nobody/Anonymous (nobody) Summary: email.Message does not allow iteration Initial Comment: >From comp.lang.python: "Roman Suzi" wrote in message news:mailman.2348.1093434827.5135.python- list@python.org... > > In Python2.3.4: > > >>> em = email.message_from_file(open ('MAILMESSAGE')) > >>> for i in em: > ... print i > ... > Traceback (most recent call last): > File "", line 1, in ? > File "/usr/lib/python2.3/email/Message.py", > line > 304, in __getitem__ > File "/usr/lib/python2.3/email/Message.py", > line > 370, in get > AttributeError: 'int' object has no attribute 'lower' In this example, em is an email.Message object. The Message acts as a pseudo-dictionary, containing a list of e-mail fields, organized by name and contents. The problem occurs because __getitem__ assumes that the provided index is a name into a dictionary. For programmer convenience, keys in the Message are case- insensitive, so __getitem__ starts by calling lower() on the provided name. Apparently, the attempt to iterate over Message successively calls __getitem__ with integers from 0 to len(em). Integers don't like having lower() called, though. To fix this problem: - have __getitem__ use the input arg as a name if it is of type string; otherwise, just use the provided arg as an index to the underlying self.headers list (arg could be either an integer or a slice, so don't just test for integer!) - make a similar change to __delitem__ - it too assumes that the incoming arg is a string, naming a header field to be deleted; must test first to see if arg is an integer or slice - add __iter__ method, which returns iter(self.headers) -- Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017329&group_id=5470 From noreply at sourceforge.net Fri Aug 27 10:07:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 10:07:16 2004 Subject: [ python-Bugs-933670 ] pty.fork() leaves slave fd's open on Solaris Message-ID: Bugs item #933670, was opened at 2004-04-12 23:21 Message generated for change (Comment added) made by k5r2a You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933670&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Scott Lowrey (slowrey) Assigned to: Nobody/Anonymous (nobody) Summary: pty.fork() leaves slave fd's open on Solaris Initial Comment: On a Solaris 2.8 system, slave file descriptors are left open after the child process is gone and the master has been closed. The pty.fork() function attempts to use os.forkpty() first. When that fails (apparently the os module does not provide forkpty() on Solaris?), it uses openpty() and os.fork(). openpty() returns master and slave file descriptors. Since pty.fork() only returns the master_fd, it is not clear to me how the slave would ever be closed since the caller doesn't have access to it. Perhaps pty.fork is supposed to take care of this? I am using pexpect to control my pty's, so I don't have much expertise in this area other than what I've gleaned from the code. At any rate, on a long running process used to test other programs, the open file descriptors pile up until the ulimit is reached. I've worked around this by modifying pexpect.close() to use os.close(self.child_fd + 1). A hack, I'm sure... :) ---------------------------------------------------------------------- Comment By: HyunKook Kim (k5r2a) Date: 2004-08-27 17:07 Message: Logged In: YES user_id=604333 Thank you very much for your comments My Case is same to yours. -platform : Solaris 5.8 -Python : 2.3.3 -pyexpect: 0.99 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=933670&group_id=5470 From noreply at sourceforge.net Fri Aug 27 10:43:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 10:43:47 2004 Subject: [ python-Bugs-1017450 ] including Python.h redefines _POSIX_C_SOURCE Message-ID: Bugs item #1017450, was opened at 2004-08-27 10:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017450&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon K?re Hellan (jhellan) Assigned to: Nobody/Anonymous (nobody) Summary: including Python.h redefines _POSIX_C_SOURCE Initial Comment: Consider this program: #include #include int main (int arg, char **argv) { return 0; } We compile it like this cc -Wall -I/usr/include/python2.3 -c aa.c And get In file included from /usr/include/python2.3/Python.h:8, from aa.c:3: /usr/include/python2.3/pyconfig.h:853:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/limits.h:26, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:122, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:11, from aa.c:2: /usr/include/features.h:171:1: warning: this is the location of the previous definition Python.h has redefind a symbol which got defined by including limits.h. This is unfriendly to programs which embed Python. I suspect that there are definitions in pyconfig.h which are only relevant when building the Python distribution. Such definitions should not be exposed to embedders or builders of 3rd party modules. I can make the warning go away by including Python.h first. But my application has its own config.h - strange that Python's has to go in front of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017450&group_id=5470 From noreply at sourceforge.net Fri Aug 27 10:54:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 10:54:35 2004 Subject: [ python-Bugs-1017455 ] including Python.h redefines _POSIX_C_SOURCE Message-ID: Bugs item #1017455, was opened at 2004-08-27 10:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017455&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon K?re Hellan (jhellan) Assigned to: Nobody/Anonymous (nobody) Summary: including Python.h redefines _POSIX_C_SOURCE Initial Comment: Consider this program: #include #include int main (int arg, char **argv) { return 0; } We compile it like this cc -Wall -I/usr/include/python2.3 -c aa.c And get In file included from /usr/include/python2.3/Python.h:8, from aa.c:3: /usr/include/python2.3/pyconfig.h:853:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/limits.h:26, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:122, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:11, from aa.c:2: /usr/include/features.h:171:1: warning: this is the location of the previous definition Python.h has redefind a symbol which got defined by including limits.h. This is unfriendly to programs which embed Python. I suspect that there are definitions in pyconfig.h which are only relevant when building the Python distribution. Such definitions should not be exposed to embedders or builders of 3rd party modules. I can make the warning go away by including Python.h first. But my application has its own config.h - strange that Python's has to go in front of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017455&group_id=5470 From noreply at sourceforge.net Fri Aug 27 10:56:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 10:56:48 2004 Subject: [ python-Bugs-1017450 ] including Python.h redefines _POSIX_C_SOURCE Message-ID: Bugs item #1017450, was opened at 2004-08-27 10:43 Message generated for change (Comment added) made by jhellan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017450&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon K?re Hellan (jhellan) Assigned to: Nobody/Anonymous (nobody) Summary: including Python.h redefines _POSIX_C_SOURCE Initial Comment: Consider this program: #include #include int main (int arg, char **argv) { return 0; } We compile it like this cc -Wall -I/usr/include/python2.3 -c aa.c And get In file included from /usr/include/python2.3/Python.h:8, from aa.c:3: /usr/include/python2.3/pyconfig.h:853:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/limits.h:26, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:122, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:11, from aa.c:2: /usr/include/features.h:171:1: warning: this is the location of the previous definition Python.h has redefind a symbol which got defined by including limits.h. This is unfriendly to programs which embed Python. I suspect that there are definitions in pyconfig.h which are only relevant when building the Python distribution. Such definitions should not be exposed to embedders or builders of 3rd party modules. I can make the warning go away by including Python.h first. But my application has its own config.h - strange that Python's has to go in front of it. ---------------------------------------------------------------------- >Comment By: Jon K?re Hellan (jhellan) Date: 2004-08-27 10:56 Message: Logged In: YES user_id=268898 Sorry about the duplicate. That was my browser's "back" button. Platform is Debian sid (soon to be sarge), and Python version is 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017450&group_id=5470 From noreply at sourceforge.net Fri Aug 27 10:57:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 10:57:35 2004 Subject: [ python-Bugs-1017455 ] including Python.h redefines _POSIX_C_SOURCE Message-ID: Bugs item #1017455, was opened at 2004-08-27 10:54 Message generated for change (Comment added) made by jhellan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017455&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon K?re Hellan (jhellan) Assigned to: Nobody/Anonymous (nobody) Summary: including Python.h redefines _POSIX_C_SOURCE Initial Comment: Consider this program: #include #include int main (int arg, char **argv) { return 0; } We compile it like this cc -Wall -I/usr/include/python2.3 -c aa.c And get In file included from /usr/include/python2.3/Python.h:8, from aa.c:3: /usr/include/python2.3/pyconfig.h:853:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/limits.h:26, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:122, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:11, from aa.c:2: /usr/include/features.h:171:1: warning: this is the location of the previous definition Python.h has redefind a symbol which got defined by including limits.h. This is unfriendly to programs which embed Python. I suspect that there are definitions in pyconfig.h which are only relevant when building the Python distribution. Such definitions should not be exposed to embedders or builders of 3rd party modules. I can make the warning go away by including Python.h first. But my application has its own config.h - strange that Python's has to go in front of it. ---------------------------------------------------------------------- >Comment By: Jon K?re Hellan (jhellan) Date: 2004-08-27 10:57 Message: Logged In: YES user_id=268898 I accidentally made this dupe by pressing the browser's "Back" button. Please disregard. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017455&group_id=5470 From noreply at sourceforge.net Fri Aug 27 14:20:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 14:21:01 2004 Subject: [ python-Bugs-1017546 ] test_inspect.py fails to clean up upon failure Message-ID: Bugs item #1017546, was opened at 2004-08-27 13:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017546&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael (ms_) Assigned to: Nobody/Anonymous (nobody) Summary: test_inspect.py fails to clean up upon failure Initial Comment: When test_inspect.py encounters a failure in the code it's testing it fails to clean up its temporary files upon exit. This causes spurious errors for other tests when debugging. eg: force a test to fail by changing test_inspect.py such that this: test(inspect.getsource(mod2.wrapped) == sourcerange(13, 16), "inspect.getsource(mod.wrapped)") Is replaced with: test(inspect.getsource(mod2.wrapped) != sourcerange(13, 16), "inspect.getsource(mod.wrapped)") Clearly this should only cause test_inspect.py to fail, however: # ./python Lib/test/regrtest.py test_inspect test_posixpath test_inspect test test_inspect failed -- inspect.getsource(mod.wrapped) test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/home/michaels/Python/Cvs/python/dist/src/Lib/test/test_posixpath.py", line 148, in test_islink os.symlink(test_support.TESTFN + "1", test_support.TESTFN + "2") OSError: [Errno 17] File exists 2 tests failed: test_inspect test_posixpath In this example the reason why test_posixpath failed is due to the temporary files left behind by the failed test_inspect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017546&group_id=5470 From noreply at sourceforge.net Fri Aug 27 14:27:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 14:28:05 2004 Subject: [ python-Bugs-1017546 ] test_inspect.py fails to clean up upon failure Message-ID: Bugs item #1017546, was opened at 2004-08-27 13:20 Message generated for change (Comment added) made by ms_ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017546&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael (ms_) Assigned to: Nobody/Anonymous (nobody) Summary: test_inspect.py fails to clean up upon failure Initial Comment: When test_inspect.py encounters a failure in the code it's testing it fails to clean up its temporary files upon exit. This causes spurious errors for other tests when debugging. eg: force a test to fail by changing test_inspect.py such that this: test(inspect.getsource(mod2.wrapped) == sourcerange(13, 16), "inspect.getsource(mod.wrapped)") Is replaced with: test(inspect.getsource(mod2.wrapped) != sourcerange(13, 16), "inspect.getsource(mod.wrapped)") Clearly this should only cause test_inspect.py to fail, however: # ./python Lib/test/regrtest.py test_inspect test_posixpath test_inspect test test_inspect failed -- inspect.getsource(mod.wrapped) test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/home/michaels/Python/Cvs/python/dist/src/Lib/test/test_posixpath.py", line 148, in test_islink os.symlink(test_support.TESTFN + "1", test_support.TESTFN + "2") OSError: [Errno 17] File exists 2 tests failed: test_inspect test_posixpath In this example the reason why test_posixpath failed is due to the temporary files left behind by the failed test_inspect. ---------------------------------------------------------------------- >Comment By: Michael (ms_) Date: 2004-08-27 13:27 Message: Logged In: YES user_id=994316 Patch against current Anon CVS can be found here: * http://www.python.org/sf/1017550 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017546&group_id=5470 From noreply at sourceforge.net Fri Aug 27 14:29:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 14:29:16 2004 Subject: [ python-Bugs-1017553 ] filemode() in tarfile.py makes wrong file mode strings Message-ID: Bugs item #1017553, was opened at 2004-08-27 14:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017553&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Loje Hansen (pingupeter) Assigned to: Nobody/Anonymous (nobody) Summary: filemode() in tarfile.py makes wrong file mode strings Initial Comment: filemode(07111) produces the string "---x--x--x" in stead of the correct output "---s--s--t" This small test script provides a correct filemode function: ======================================== #!/usr/bin/env python #--------------------------------------------------------- # Bits used in the mode field, values in octal. #--------------------------------------------------------- S_IFLNK = 0120000 # symbolic link S_IFREG = 0100000 # regular file S_IFBLK = 0060000 # block device S_IFDIR = 0040000 # directory S_IFCHR = 0020000 # character device S_IFIFO = 0010000 # fifo TSUID = 04000 # set UID on execution TSGID = 02000 # set GID on execution TSVTX = 01000 # reserved TUREAD = 0400 # read by owner TUWRITE = 0200 # write by owner TUEXEC = 0100 # execute/search by owner TGREAD = 0040 # read by group TGWRITE = 0020 # write by group TGEXEC = 0010 # execute/search by group TOREAD = 0004 # read by other TOWRITE = 0002 # write by other TOEXEC = 0001 # execute/search by other filemode_table = ( (S_IFLNK, "l", S_IFREG, "-", S_IFBLK, "b", S_IFDIR, "d", S_IFCHR, "c", S_IFIFO, "p"), (TUREAD, "r"), (TUWRITE, "w"), (TUEXEC, "x", TSUID, "S", TUEXEC|TSUID, "s"), (TGREAD, "r"), (TGWRITE, "w"), (TGEXEC, "x", TSGID, "S", TGEXEC|TSGID, "s"), (TOREAD, "r"), (TOWRITE, "w"), (TOEXEC, "x", TSVTX, "T", TOEXEC|TSVTX, "t")) def filemode(mode): """Convert a file's mode to a string of the form -rwxrwxrwx. Used by TarFile.list() """ s = "" for t in filemode_table: p = "-" for i in range(0, len(t), 2): if mode & t[i] == t[i]: p = t[i+1] s += p return s def filemode_old(mode): """Convert a file's mode to a string of the form -rwxrwxrwx. Used by TarFile.list() """ s = "" for t in filemode_table: while True: if mode & t[0] == t[0]: s += t[1] elif len(t) > 2: t = t[2:] continue else: s += "-" break return s def main(): print "filemode_old:\tfilemode:" for p in ( 00777 | 00000, 00777 | 01000, 00777 | 04000, 00777 | 07000, 00000 | 07000, 00111 | 07000 ): print "%s\t%s" % (filemode_old(p), filemode(p)) if __name__ == "__main__": main() ======================================== Regards Peter Loje Hansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017553&group_id=5470 From noreply at sourceforge.net Fri Aug 27 14:40:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 14:40:33 2004 Subject: [ python-Bugs-1017553 ] filemode() in tarfile.py makes wrong file mode strings Message-ID: Bugs item #1017553, was opened at 2004-08-27 14:29 Message generated for change (Comment added) made by pingupeter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017553&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Loje Hansen (pingupeter) Assigned to: Nobody/Anonymous (nobody) Summary: filemode() in tarfile.py makes wrong file mode strings Initial Comment: filemode(07111) produces the string "---x--x--x" in stead of the correct output "---s--s--t" This small test script provides a correct filemode function: ======================================== #!/usr/bin/env python #--------------------------------------------------------- # Bits used in the mode field, values in octal. #--------------------------------------------------------- S_IFLNK = 0120000 # symbolic link S_IFREG = 0100000 # regular file S_IFBLK = 0060000 # block device S_IFDIR = 0040000 # directory S_IFCHR = 0020000 # character device S_IFIFO = 0010000 # fifo TSUID = 04000 # set UID on execution TSGID = 02000 # set GID on execution TSVTX = 01000 # reserved TUREAD = 0400 # read by owner TUWRITE = 0200 # write by owner TUEXEC = 0100 # execute/search by owner TGREAD = 0040 # read by group TGWRITE = 0020 # write by group TGEXEC = 0010 # execute/search by group TOREAD = 0004 # read by other TOWRITE = 0002 # write by other TOEXEC = 0001 # execute/search by other filemode_table = ( (S_IFLNK, "l", S_IFREG, "-", S_IFBLK, "b", S_IFDIR, "d", S_IFCHR, "c", S_IFIFO, "p"), (TUREAD, "r"), (TUWRITE, "w"), (TUEXEC, "x", TSUID, "S", TUEXEC|TSUID, "s"), (TGREAD, "r"), (TGWRITE, "w"), (TGEXEC, "x", TSGID, "S", TGEXEC|TSGID, "s"), (TOREAD, "r"), (TOWRITE, "w"), (TOEXEC, "x", TSVTX, "T", TOEXEC|TSVTX, "t")) def filemode(mode): """Convert a file's mode to a string of the form -rwxrwxrwx. Used by TarFile.list() """ s = "" for t in filemode_table: p = "-" for i in range(0, len(t), 2): if mode & t[i] == t[i]: p = t[i+1] s += p return s def filemode_old(mode): """Convert a file's mode to a string of the form -rwxrwxrwx. Used by TarFile.list() """ s = "" for t in filemode_table: while True: if mode & t[0] == t[0]: s += t[1] elif len(t) > 2: t = t[2:] continue else: s += "-" break return s def main(): print "filemode_old:\tfilemode:" for p in ( 00777 | 00000, 00777 | 01000, 00777 | 04000, 00777 | 07000, 00000 | 07000, 00111 | 07000 ): print "%s\t%s" % (filemode_old(p), filemode(p)) if __name__ == "__main__": main() ======================================== Regards Peter Loje Hansen ---------------------------------------------------------------------- >Comment By: Peter Loje Hansen (pingupeter) Date: 2004-08-27 14:40 Message: Logged In: YES user_id=1112055 Sorry for the broken formatting. I have uploaded the test script in stead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017553&group_id=5470 From noreply at sourceforge.net Fri Aug 27 22:24:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 22:24:09 2004 Subject: [ python-Bugs-1017455 ] including Python.h redefines _POSIX_C_SOURCE Message-ID: Bugs item #1017455, was opened at 2004-08-27 04:54 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017455&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jon K?re Hellan (jhellan) Assigned to: Nobody/Anonymous (nobody) Summary: including Python.h redefines _POSIX_C_SOURCE Initial Comment: Consider this program: #include #include int main (int arg, char **argv) { return 0; } We compile it like this cc -Wall -I/usr/include/python2.3 -c aa.c And get In file included from /usr/include/python2.3/Python.h:8, from aa.c:3: /usr/include/python2.3/pyconfig.h:853:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/limits.h:26, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:122, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/syslimits.h:7, from /usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h:11, from aa.c:2: /usr/include/features.h:171:1: warning: this is the location of the previous definition Python.h has redefind a symbol which got defined by including limits.h. This is unfriendly to programs which embed Python. I suspect that there are definitions in pyconfig.h which are only relevant when building the Python distribution. Such definitions should not be exposed to embedders or builders of 3rd party modules. I can make the warning go away by including Python.h first. But my application has its own config.h - strange that Python's has to go in front of it. ---------------------------------------------------------------------- Comment By: Jon K?re Hellan (jhellan) Date: 2004-08-27 04:57 Message: Logged In: YES user_id=268898 I accidentally made this dupe by pressing the browser's "Back" button. Please disregard. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017455&group_id=5470 From noreply at sourceforge.net Fri Aug 27 22:26:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 27 22:26:57 2004 Subject: [ python-Bugs-1017864 ] Case sensitivity bug in ConfigParser Message-ID: Bugs item #1017864, was opened at 2004-08-27 20:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017864&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: Case sensitivity bug in ConfigParser Initial Comment: (Assume an instantiated ConfigParser, c, with a loaded file) >>> c.get("DEFAULT", "foo", False, {"foo": "Bar"}) 'Bar' >>> c.get("DEFAULT", "Foo", False, {"Foo": "Bar"}) Traceback (most recent call last): File "", line 1, in ? c.get("DEFAULT", "Foo", False, {"Foo": "Bar"}) File "C:\Python23\lib\ConfigParser.py", line 513, in get raise NoOptionError(option, section) NoOptionError: No option 'foo' in section: 'DEFAULT' The offending code appears to be as follows (in ConfigParser.py): def get(self, section, option): opt = self.optionxform(option) if section not in self._sections: if section != DEFAULTSECT: raise NoSectionError(section) if opt in self._defaults: return self._defaults[opt] else: raise NoOptionError(option, section) elif opt in self._sections[section]: return self._sections[section][opt] elif opt in self._defaults: return self._defaults[opt] else: raise NoOptionError(option, section) It uses optionxform on the supplied option, but not on the one in the defaults dictionary. If you're going to impose a transform then you have to do it consistently, imho... >>> c.get("DEFAULT", "Foo", False, {"foo": "Bar"}) 'Bar' The supplied "Foo" gets transformed to "foo" and matches the one in the defaults dictionary. Seems a bit counterintuitive to expect that you supply any defaults as pre-transformed according to your specified optionxform. I'm not sure if this is also a problem when reading a file, but there seems to be a related post about this (with no replies!) dating back to 2000: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=8suc1f%24mf9%241%40nnrp1.deja.com I don't have time to look into it now but I'd guess this problem was resolved in the more obvious location (when reading a file) but patching of the defaults dictionary case was omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017864&group_id=5470 From noreply at sourceforge.net Sat Aug 28 02:23:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 28 02:23:13 2004 Subject: [ python-Bugs-1017978 ] IDLE DOES NOT START ON WinXP Pro Message-ID: Bugs item #1017978, was opened at 2004-08-27 17:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017978&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Snake (gj_carman) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE DOES NOT START ON WinXP Pro Initial Comment: Installed Python 2.3.4 on WinXP Pro on Dell Inspiron. Command line interpreter works fine, but the IDLE GUI will not start. Only occurs on Dell Inspiron; cannot reproduce this on other machines. McAffee firewall software is disabled. Any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017978&group_id=5470 From noreply at sourceforge.net Sat Aug 28 22:59:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 28 22:59:50 2004 Subject: [ python-Bugs-1018315 ] __new__ not defined? Message-ID: Bugs item #1018315, was opened at 2004-08-28 15:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: __new__ not defined? Initial Comment: I can't find __new__ in the index for either the Language Reference Manual or Library Reference Manual. Poking around I did find it mentioned in ext/newtypes.tex, but without any details. I'd submit something, but I don't know at this point how to use it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018315&group_id=5470 From noreply at sourceforge.net Sun Aug 29 02:22:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 02:22:41 2004 Subject: [ python-Bugs-776311 ] Regular expression failure of the sre engine Message-ID: Bugs item #776311, was opened at 2003-07-23 10:15 Message generated for change (Comment added) made by mkc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776311&group_id=5470 Category: Regular Expressions Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Grafen (grafen) Assigned to: Fredrik Lundh (effbot) Summary: Regular expression failure of the sre engine Initial Comment: Don't depreciate pre as we all will loose a useful verification tool for sre! >From time to time I have situations where I wonder why re(sre) doesn't match its input. Then I change to pre (import pre as re) and several times it happened that pre worked fine while sre did not. Sorry that I didn't track down the error but if you are interested in the testcase I attached the test case for you. (This failure is in a regular expression which maches a complete pattern of a VHDL Architecture to apply a patch on it so it was quick hack but a large regex. The other failures I cannot remember what it was, sorry) Regards Wolfgang Grafen --------------------------------------- I will be absent until 5 September 2003 --------------------------------------- ---------------------------------------------------------------------- Comment By: Mike Coleman (mkc) Date: 2004-08-28 19:22 Message: Logged In: YES user_id=555 The particular problem with your test case turned out to be an infinite loop in the sre parser. This is fixed in patch #1018386. If you are aware of or encounter any other cases where sre's behavior deviates from pre, please post a bug for them. Pending that, I'd suggest this bug be closed. Thanks for your excellent bug report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776311&group_id=5470 From noreply at sourceforge.net Sun Aug 29 03:52:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 03:52:23 2004 Subject: [ python-Feature Requests-992967 ] array.array objects should support sequences Message-ID: Feature Requests item #992967, was opened at 2004-07-17 14:30 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) >Assigned to: Raymond Hettinger (rhettinger) Summary: array.array objects should support sequences Initial Comment: array objects from the array module have an extend method that only takes arrays. The implementation would be more useful if it accepted arbitrary sequences (generators, lists, strings, etc). Similarly, the initializer currently only accepts lists and strings, but it should also support arbitrary sequences. >>> from array import array >>> array('c', iter('1234')) Traceback (most recent call last): File "", line 1, in ? TypeError: array initializer must be list or string >>> array('c').extend('1234') Traceback (most recent call last): File "", line 1, in ? TypeError: can only extend array with array (not "str") ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-08-28 21:52 Message: Logged In: YES user_id=6380 Hm, I don't see the array module as a performance hack for operations within Python. I see it as a storage savings hack (occasionally) and as a way to create arrays that can be directly manipulated by C code (mostly). Although the new numeric module promises a much better solution for the latter. I'd say that both the constructor and extend() should support arbitrary iterables -- that's the Pythonic API style these days. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-21 15:11 Message: Logged In: YES user_id=80475 Guido, do you have an opinion on this? If you want the constructor to accept general iterables, that is not hard to do. The question is whether the change is desirable. On the plus side, it better matches the list API. On the minus side, it allows array construction to invisibly slip into a lower performance mode for both speed and space (with a list style over allocation scheme). I find that to be at odds with the performance oriented use cases for the module. So, I'm -0 on the feature request since general iterables can already be handled explicitly with array.extend(it) or array.array(code, list(it)). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-21 09:02 Message: Logged In: YES user_id=6656 Interesting how intuitions differ :-) It's just a call to PySequence_FAST, hardly an intrusive patch (which didn't you use that for array_extend?). The error message is wrong, btw: tuples are accepted too. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-07-21 08:21 Message: Logged In: YES user_id=139309 One can construct an empty list and extend it too, but for some reason they let you make them out of arbitrary iterables. I wonder why! :) ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-07-21 08:13 Message: Logged In: YES user_id=99874 I'll just chime in to agree with Raymond's analysis... the constructor doesn't need to take general iterables. One can always construct an empty array and extend it if that's what's needed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 15:23 Message: Logged In: YES user_id=80475 In Py2.4, I already made extend() take a general iterable. The goal was to simplify code doing repeated appends. By calling array_extend, it should be easy to do the same for the constructor. The question is whether there are use cases to warrant a further API change. Most needs can already be met with extend() or with array.array(code, list(it)). My preference is to leave the constructor for cases with a known sequence length. With a single pre-allocation and copy step, the performance is optimal. I don't think it would be obvious that using a general iterable would be much slower and consume more memory than expected. That's okay for lists, but people use array when they are tight for space or have other performance goals. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-19 11:56 Message: Logged In: YES user_id=6656 I agree with your first point. Should be easy, too. I'm /slightly/ less enthusiastic about the latter point. sequence- >array conversion is sufficiently complex that I'm not sure I want it happening automatically. This is the sort of report that a patch would help immensely, btw :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470 From noreply at sourceforge.net Sun Aug 29 09:51:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 09:51:12 2004 Subject: [ python-Feature Requests-992967 ] array.array objects should support sequences Message-ID: Feature Requests item #992967, was opened at 2004-07-17 13:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Raymond Hettinger (rhettinger) Summary: array.array objects should support sequences Initial Comment: array objects from the array module have an extend method that only takes arrays. The implementation would be more useful if it accepted arbitrary sequences (generators, lists, strings, etc). Similarly, the initializer currently only accepts lists and strings, but it should also support arbitrary sequences. >>> from array import array >>> array('c', iter('1234')) Traceback (most recent call last): File "", line 1, in ? TypeError: array initializer must be list or string >>> array('c').extend('1234') Traceback (most recent call last): File "", line 1, in ? TypeError: can only extend array with array (not "str") ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-29 02:51 Message: Logged In: YES user_id=80475 Wish granted. See Modules/arraymodule.c 2.97 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-08-28 20:52 Message: Logged In: YES user_id=6380 Hm, I don't see the array module as a performance hack for operations within Python. I see it as a storage savings hack (occasionally) and as a way to create arrays that can be directly manipulated by C code (mostly). Although the new numeric module promises a much better solution for the latter. I'd say that both the constructor and extend() should support arbitrary iterables -- that's the Pythonic API style these days. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-21 14:11 Message: Logged In: YES user_id=80475 Guido, do you have an opinion on this? If you want the constructor to accept general iterables, that is not hard to do. The question is whether the change is desirable. On the plus side, it better matches the list API. On the minus side, it allows array construction to invisibly slip into a lower performance mode for both speed and space (with a list style over allocation scheme). I find that to be at odds with the performance oriented use cases for the module. So, I'm -0 on the feature request since general iterables can already be handled explicitly with array.extend(it) or array.array(code, list(it)). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-21 08:02 Message: Logged In: YES user_id=6656 Interesting how intuitions differ :-) It's just a call to PySequence_FAST, hardly an intrusive patch (which didn't you use that for array_extend?). The error message is wrong, btw: tuples are accepted too. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-07-21 07:21 Message: Logged In: YES user_id=139309 One can construct an empty list and extend it too, but for some reason they let you make them out of arbitrary iterables. I wonder why! :) ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-07-21 07:13 Message: Logged In: YES user_id=99874 I'll just chime in to agree with Raymond's analysis... the constructor doesn't need to take general iterables. One can always construct an empty array and extend it if that's what's needed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-19 14:23 Message: Logged In: YES user_id=80475 In Py2.4, I already made extend() take a general iterable. The goal was to simplify code doing repeated appends. By calling array_extend, it should be easy to do the same for the constructor. The question is whether there are use cases to warrant a further API change. Most needs can already be met with extend() or with array.array(code, list(it)). My preference is to leave the constructor for cases with a known sequence length. With a single pre-allocation and copy step, the performance is optimal. I don't think it would be obvious that using a general iterable would be much slower and consume more memory than expected. That's okay for lists, but people use array when they are tight for space or have other performance goals. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-07-19 10:56 Message: Logged In: YES user_id=6656 I agree with your first point. Should be easy, too. I'm /slightly/ less enthusiastic about the latter point. sequence- >array conversion is sufficiently complex that I'm not sure I want it happening automatically. This is the sort of report that a patch would help immensely, btw :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=992967&group_id=5470 From noreply at sourceforge.net Sun Aug 29 10:00:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 10:00:23 2004 Subject: [ python-Bugs-1012952 ] Standard exceptions are hostile to Unicode Message-ID: Bugs item #1012952, was opened at 2004-08-20 10:09 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012952&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marius Gedminas (mgedmin) Assigned to: Nobody/Anonymous (nobody) Summary: Standard exceptions are hostile to Unicode Initial Comment: >>> e = ValueError(u"\u2639") >>> str(e) ... UnicodeEncodeError: 'ascii' codec can't encode character u'\u2639' in position 0: ordinal not in range(128) >>> unicode(e) ... UnicodeEncodeError: 'ascii' codec can't encode character u'\u2639' in position 0: ordinal not in range(128) Please add a __unicode__ method to Exception. I suggest the following semantics: class UnicodeAwareException(Exception): def __unicode__(self): return u" ".join(map(unicode, self.args)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1012952&group_id=5470 From noreply at sourceforge.net Sun Aug 29 10:11:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 10:11:47 2004 Subject: [ python-Bugs-1015140 ] "article id" in description of NNTP objects Message-ID: Bugs item #1015140, was opened at 2004-08-24 12:26 Message generated for change (Comment added) made by felixwiemann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: "article id" in description of NNTP objects Initial Comment: lib/nntp-objects.html uses the term "article id" several times. This term is ambiguous though. Either "article number" or "message id" should be used. ---------------------------------------------------------------------- >Comment By: Felix Wiemann (felixwiemann) Date: 2004-08-29 10:11 Message: Logged In: YES user_id=1014490 Same problem for the docstrings in the source file Lib/nntplib.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 From noreply at sourceforge.net Sun Aug 29 10:20:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 10:20:22 2004 Subject: [ python-Bugs-1015140 ] "article id" in description of NNTP objects Message-ID: Bugs item #1015140, was opened at 2004-08-24 05:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: "article id" in description of NNTP objects Initial Comment: lib/nntp-objects.html uses the term "article id" several times. This term is ambiguous though. Either "article number" or "message id" should be used. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-29 03:20 Message: Logged In: YES user_id=80475 Patches are welcome. If you have a link to authoritive guidance, that would be nice also. ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-08-29 03:11 Message: Logged In: YES user_id=1014490 Same problem for the docstrings in the source file Lib/nntplib.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 From noreply at sourceforge.net Sun Aug 29 12:18:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 12:18:27 2004 Subject: [ python-Bugs-1018492 ] Solaris: reentrancy issues Message-ID: Bugs item #1018492, was opened at 2004-08-29 10:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 Category: None Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Simon Harrison (ssmmhh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris: reentrancy issues Initial Comment: Version: 2.3.4 Platform: Solaris (possibly other non-Linux). In some cases reentrant API functions (ctime_r etc) are used, but many cases not. It's unlikely that this would cause problems on single-processor machines. Run the attached script giving Python source tree location as argument. A file report.html will be generated detailing where there could be problems. NB: The script isn't foolproof and will come up with matches to text inside comments as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018492&group_id=5470 From noreply at sourceforge.net Sun Aug 29 12:30:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 12:30:21 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 15:18 Message generated for change (Comment added) made by jiba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 10:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-19 22:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 15:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Sun Aug 29 13:17:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 13:17:18 2004 Subject: [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 15:18 Message generated for change (Comment added) made by jiba You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 11:17 Message: Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. ---------------------------------------------------------------------- Comment By: Jiba (jiba) Date: 2004-08-29 10:30 Message: Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-19 22:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: SomeOne (regenkind) Date: 2003-10-18 15:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Sun Aug 29 15:02:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 15:03:01 2004 Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur Message-ID: Bugs item #570300, was opened at 2002-06-18 04:24 Message generated for change (Comment added) made by amitar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 3 Submitted By: Amit Aronovitch (amitar) Assigned to: Brett Cannon (bcannon) Summary: inspect.getmodule symlink-related failur Initial Comment: news:ae3e29$pib$1@news.netvision.net.il Description: -------------- On a unix python2.2.1 installation I noticed that the documentations generated for modules by pydoc (in any mode - even the help command) did NOT contain any docs for functions. After some digging, I found out the reason for that, and now I believe it indicates a deeper problem with the "inspect" module, concerning file identification in the presence of symbolic or hard links, which I'll explain below, and also suggest solutions. Analysis: ----------- The reason the functions were dropped from the doc was pydoc's attempt to remove functions which were imported from other modules. This is done by something like "inspect.getmodule(my_func) is my_module". I found out that inspect.getmodule() returned "None" for these functions! Now, inspect.getmodule works by getting the function's filename, and then searching it in a dictionary containing the filenames for all the modules that were loaded ("modulesbyfile"). Unfortunately, the filename that getabsfile() returns for the function is not the same STRING as the one it returns for the module, but rather an equivalent unix path pointing to the same FILE (the reason for this fact is that the filename for a function is extracted from the code-object, which holds the path the module was referred to at the time it was COMPILED to .pyc, whereas the one for the module is taken from it's __file__, which holds the path it was referred to when it was IMPORTED - these two might differ even if it's the same file). So, the function's file is not found on the dictionary, and getmodule() returns None... Discussion: -------------- We see that the root cause of the problem is that "inspect" uses the "absolute path" (os.path.abspath()) for representing the file's identity. In unix systems, this might cause a problem, since this string is NOT unique (it is a unique path, but different paths may refer to the same file). If we only considered symbolic links, this could be resolved by scanning the path elements and "unfolding" any symlinks, but we must recall that unix can also has "hard links" which are equivalent references to the same inode, and can't be discriminated. So, if we want to resolve the problem in a portable way, we need an immutable (platform-dependant) object that will be unique to a FILE. This object could then be used for comparing files and as keys for dictionaries. A reasonable way to get it would be by means of a new function in the os module. e.g. : id = os.get_fileid(filename) def samefile(f1,f2): return os.get_fileid(f1) is os.get_fileid(f2) This function could be implemented by the inode number (os.stat(f).st_ino) on unix systems, and by the absolute path (os.path.abspath) on systems which do not support links (such as windows), or by anything else, as long as it would be immutable and unique for each file. Please let me know your opinion about this suggestion, Amit Aronovitch ---------------------------------------------------------------------- >Comment By: Amit Aronovitch (amitar) Date: 2004-08-29 16:02 Message: Logged In: YES user_id=564711 Pls see attached files. Note that jlgijsbers' patch does not resolve the full scope of the problem as described in my original post (see the "discussion" part) - namely: it only works for symbolic links. bcannon (re 12/7 msg): Sorry. I wrote the long explanations in hope it would save you time, but it seems they were not clear enough. To avoid trouble repeating the problem, this time I'll provide a shell script for testing it. Also provided is a proposed patch (against cvs snapshot from 29 Aug 2004). About the patch ----------------- I added a "fileid" function to os.path (as suggested in my original post). This means macpath os2emxpath and ntpath had to be touched as well as posixpath. (libposixpath.tex would also need an update if you decide to adopt this patch) Question about inspect.getabsfile ----------------------------------- I'm not sure if this function is ment to be an "internal use" or "interface" function. It does not appear in the module's documentation (libinspect.tex), but the pydoc module still uses it (and as far as I could see - it's the only module that uses it). After my patch, getabsfile is not used internally by inspect anymore, so should be deleted if "internal use". The use of this function in pydoc is for human readable output, so I don't think it's really necessary there (I think there's no need to do "normcase" there). tks for yr attention ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-13 21:47 Message: Logged In: YES user_id=357491 Checked in as rev. 1.52 for 'inspect'. Not going to backport since it is a semantic change. Thanks for the patch, Johannes. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 20:08 Message: Logged In: YES user_id=469548 I can reproduce the problem using the steps outlined below. Replacing the line (it's not even worth creating a new patch item): modulesbyfile[getabsfile(module)] = module.__name__ with modulesbyfile[os.path.realpath(getabsfile(module))] = module.__name__ fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-13 03:26 Message: Logged In: YES user_id=357491 Well, when a bug gets old and you don't have a test to make sure it has been fixed, yes, things just do "go away" in the stdlib. The amount of code change in the stdlib can easily lead to some other bug being fixed. And I did read it. But when the problem stopped presenting itself to me (and I don't know why; I spent a good amount of time on this on the July 10 Bug Day)?I figured it was gone. If I can't reproduce it I can't try to fix it. But if you can come up with a patch to fix this feel free to assign it to me. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-07-13 01:08 Message: Logged In: YES user_id=564711 In my experience, problems don't just "go away" by themselves. Someone needs to actually fix them. So, I tested on 2.4a - and results are EXACTLY THE SAME (attached printout). It seems that no-one got to actually READ this lengthy description, so I'll have to send patches. Sorry I did not do that already, and sorry again but it seems I'm not going to get to that soon enough. I'll try to get it done by the end of July. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-10 21:23 Message: Logged In: YES user_id=357491 Well, looks like this problem has gone away, at least in 2.4. Closing out outdated. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2003-05-18 23:10 Message: Logged In: YES user_id=564711 Sorry - seems like I forgot most basic step in prob- reporting - the "howtorepeat" :-) - so here it comes: How to repeat: ---------------------- (as I said - you need unix & symlinks to see this happening): ~> mkdir test ~> setenv PYTHONPATH ~/test ~> cat >test/test_mod.py "module doc" def blah(): "hello" pass ^D ~> python >> import test_mod >> help(test_mod) >> ^D [ Prints help - so far so good - no problem - but see now] ~> ln -s test test2 ~> setenv PYTHONPATH test2 ~> python >> import test_mod >> help(test_mod) [ Now the help shows up without the help of the blah function] Relating the example to my explanations above: ------------------------------------------------------------------------ The help of the blah() function is filtered out, because "inspect" takes "~/test/test_mod.pyc" as it's filename, and "~/test1/test_mod.pyc" as the module's filename. It can't tell that these are the same file (see details in my "Analysis" section above). True, this messing up with symlinks and PYTHONPATH is a bit ugly, but this is just to demonstrate the problem. The system where I noticed it is quite complex, with disks shared (automounted) across several platforms, and it needs a few symlinks to make things easyer to maintain. As I explained, I think that few little changes in modules such as "inspect" and "os" can make them identify files better in the presence of links. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 05:34 Message: Logged In: YES user_id=357491 Just tested under 2.2.2 and 2.3b1 using a module containing just:: def blah(): """Hello"""" pass Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the name of the function and its docstring. Am I missing something here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 From noreply at sourceforge.net Sun Aug 29 15:06:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 29 15:07:03 2004 Subject: [ python-Bugs-570300 ] inspect.getmodule symlink-related failur Message-ID: Bugs item #570300, was opened at 2002-06-18 04:24 Message generated for change (Settings changed) made by amitar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 Category: Python Library Group: None >Status: Open Resolution: Fixed Priority: 3 Submitted By: Amit Aronovitch (amitar) Assigned to: Brett Cannon (bcannon) Summary: inspect.getmodule symlink-related failur Initial Comment: news:ae3e29$pib$1@news.netvision.net.il Description: -------------- On a unix python2.2.1 installation I noticed that the documentations generated for modules by pydoc (in any mode - even the help command) did NOT contain any docs for functions. After some digging, I found out the reason for that, and now I believe it indicates a deeper problem with the "inspect" module, concerning file identification in the presence of symbolic or hard links, which I'll explain below, and also suggest solutions. Analysis: ----------- The reason the functions were dropped from the doc was pydoc's attempt to remove functions which were imported from other modules. This is done by something like "inspect.getmodule(my_func) is my_module". I found out that inspect.getmodule() returned "None" for these functions! Now, inspect.getmodule works by getting the function's filename, and then searching it in a dictionary containing the filenames for all the modules that were loaded ("modulesbyfile"). Unfortunately, the filename that getabsfile() returns for the function is not the same STRING as the one it returns for the module, but rather an equivalent unix path pointing to the same FILE (the reason for this fact is that the filename for a function is extracted from the code-object, which holds the path the module was referred to at the time it was COMPILED to .pyc, whereas the one for the module is taken from it's __file__, which holds the path it was referred to when it was IMPORTED - these two might differ even if it's the same file). So, the function's file is not found on the dictionary, and getmodule() returns None... Discussion: -------------- We see that the root cause of the problem is that "inspect" uses the "absolute path" (os.path.abspath()) for representing the file's identity. In unix systems, this might cause a problem, since this string is NOT unique (it is a unique path, but different paths may refer to the same file). If we only considered symbolic links, this could be resolved by scanning the path elements and "unfolding" any symlinks, but we must recall that unix can also has "hard links" which are equivalent references to the same inode, and can't be discriminated. So, if we want to resolve the problem in a portable way, we need an immutable (platform-dependant) object that will be unique to a FILE. This object could then be used for comparing files and as keys for dictionaries. A reasonable way to get it would be by means of a new function in the os module. e.g. : id = os.get_fileid(filename) def samefile(f1,f2): return os.get_fileid(f1) is os.get_fileid(f2) This function could be implemented by the inode number (os.stat(f).st_ino) on unix systems, and by the absolute path (os.path.abspath) on systems which do not support links (such as windows), or by anything else, as long as it would be immutable and unique for each file. Please let me know your opinion about this suggestion, Amit Aronovitch ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-08-29 16:02 Message: Logged In: YES user_id=564711 Pls see attached files. Note that jlgijsbers' patch does not resolve the full scope of the problem as described in my original post (see the "discussion" part) - namely: it only works for symbolic links. bcannon (re 12/7 msg): Sorry. I wrote the long explanations in hope it would save you time, but it seems they were not clear enough. To avoid trouble repeating the problem, this time I'll provide a shell script for testing it. Also provided is a proposed patch (against cvs snapshot from 29 Aug 2004). About the patch ----------------- I added a "fileid" function to os.path (as suggested in my original post). This means macpath os2emxpath and ntpath had to be touched as well as posixpath. (libposixpath.tex would also need an update if you decide to adopt this patch) Question about inspect.getabsfile ----------------------------------- I'm not sure if this function is ment to be an "internal use" or "interface" function. It does not appear in the module's documentation (libinspect.tex), but the pydoc module still uses it (and as far as I could see - it's the only module that uses it). After my patch, getabsfile is not used internally by inspect anymore, so should be deleted if "internal use". The use of this function in pydoc is for human readable output, so I don't think it's really necessary there (I think there's no need to do "normcase" there). tks for yr attention ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-13 21:47 Message: Logged In: YES user_id=357491 Checked in as rev. 1.52 for 'inspect'. Not going to backport since it is a semantic change. Thanks for the patch, Johannes. ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-13 20:08 Message: Logged In: YES user_id=469548 I can reproduce the problem using the steps outlined below. Replacing the line (it's not even worth creating a new patch item): modulesbyfile[getabsfile(module)] = module.__name__ with modulesbyfile[os.path.realpath(getabsfile(module))] = module.__name__ fixes the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-13 03:26 Message: Logged In: YES user_id=357491 Well, when a bug gets old and you don't have a test to make sure it has been fixed, yes, things just do "go away" in the stdlib. The amount of code change in the stdlib can easily lead to some other bug being fixed. And I did read it. But when the problem stopped presenting itself to me (and I don't know why; I spent a good amount of time on this on the July 10 Bug Day)?I figured it was gone. If I can't reproduce it I can't try to fix it. But if you can come up with a patch to fix this feel free to assign it to me. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2004-07-13 01:08 Message: Logged In: YES user_id=564711 In my experience, problems don't just "go away" by themselves. Someone needs to actually fix them. So, I tested on 2.4a - and results are EXACTLY THE SAME (attached printout). It seems that no-one got to actually READ this lengthy description, so I'll have to send patches. Sorry I did not do that already, and sorry again but it seems I'm not going to get to that soon enough. I'll try to get it done by the end of July. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-10 21:23 Message: Logged In: YES user_id=357491 Well, looks like this problem has gone away, at least in 2.4. Closing out outdated. ---------------------------------------------------------------------- Comment By: Amit Aronovitch (amitar) Date: 2003-05-18 23:10 Message: Logged In: YES user_id=564711 Sorry - seems like I forgot most basic step in prob- reporting - the "howtorepeat" :-) - so here it comes: How to repeat: ---------------------- (as I said - you need unix & symlinks to see this happening): ~> mkdir test ~> setenv PYTHONPATH ~/test ~> cat >test/test_mod.py "module doc" def blah(): "hello" pass ^D ~> python >> import test_mod >> help(test_mod) >> ^D [ Prints help - so far so good - no problem - but see now] ~> ln -s test test2 ~> setenv PYTHONPATH test2 ~> python >> import test_mod >> help(test_mod) [ Now the help shows up without the help of the blah function] Relating the example to my explanations above: ------------------------------------------------------------------------ The help of the blah() function is filtered out, because "inspect" takes "~/test/test_mod.pyc" as it's filename, and "~/test1/test_mod.pyc" as the module's filename. It can't tell that these are the same file (see details in my "Analysis" section above). True, this messing up with symlinks and PYTHONPATH is a bit ugly, but this is just to demonstrate the problem. The system where I noticed it is quite complex, with disks shared (automounted) across several platforms, and it needs a few symlinks to make things easyer to maintain. As I explained, I think that few little changes in modules such as "inspect" and "os" can make them identify files better in the presence of links. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-17 05:34 Message: Logged In: YES user_id=357491 Just tested under 2.2.2 and 2.3b1 using a module containing just:: def blah(): """Hello"""" pass Ran ```help(test_mod)``` and had it spit out a FUNCTIONS section with the name of the function and its docstring. Am I missing something here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=570300&group_id=5470 From noreply at sourceforge.net Mon Aug 30 00:18:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 00:18:49 2004 Subject: [ python-Bugs-1017978 ] IDLE DOES NOT START ON WinXP Pro Message-ID: Bugs item #1017978, was opened at 2004-08-27 19:23 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017978&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Snake (gj_carman) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE DOES NOT START ON WinXP Pro Initial Comment: Installed Python 2.3.4 on WinXP Pro on Dell Inspiron. Command line interpreter works fine, but the IDLE GUI will not start. Only occurs on Dell Inspiron; cannot reproduce this on other machines. McAffee firewall software is disabled. Any ideas? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-29 17:18 Message: Logged In: YES user_id=149084 More information is needed, what does "will not start" mean? Open a command window, cd to \python23\Lib\idlelib and run ..\..\python .\PyShell.py Post all error message in command window or in the IDLE GUI here. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1017978&group_id=5470 From noreply at sourceforge.net Mon Aug 30 00:21:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 00:21:44 2004 Subject: [ python-Bugs-1001869 ] IDLE hangs when inactive more than 2 hours Message-ID: Bugs item #1001869, was opened at 2004-08-02 03:41 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open >Resolution: Works For Me >Priority: 2 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when inactive more than 2 hours Initial Comment: When IDLE is left inactive for more than 2 hours it hangs. The window does not refresh and I can't enter any commands. This is Python 2.3.4, but started to happen after I installed python 2.4a1 (also happens there) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-29 17:21 Message: Logged In: YES user_id=149084 I can't reproduce this on WinXP Pro SP1. I suspect it's your hardware or Win installation. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-17 02:23 Message: Logged In: YES user_id=358087 Same thing, it hangs after about 2 hours. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-17 01:40 Message: Logged In: YES user_id=149084 um, run win32 IDLE and cygwin IDLE at the same time? What happens when you run win32 IDLE without cygwin IDLE? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-16 04:24 Message: Logged In: YES user_id=358087 It hangs even if I don't do anything and even without screen saver. Seems to be a problem in Tk since if I run both win32 IDLE and cygwin IDLE both hang. If I run only cygwin IDLE it's OK. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-10 20:55 Message: Logged In: YES user_id=149084 If you just start IDLE (shell window only) and don't do anything, does it always hang in two hours? If so, /please/ try this without your screen saver. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-08 02:58 Message: Logged In: YES user_id=358087 Hangs means the window content does not refresh. I can move it, resize it ... It is killable and task manager show it as "active". ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-08-04 15:17 Message: Logged In: YES user_id=593130 By 'hangs' do you mean when viewing the TasKManager Applications list, and killable with its End Task button? or something more evil, like locks the computer and prevents rebooting? Even Outlook Express and Internet Explore, with MS's billions, still do the former. With Win95, 98, and XP home and pro, I have had several problems, often intermittent, and maybe hardware specific, with bad interactions between programs, screen savers, and stand-by. On LCDs (and, I believe, modern CRTs) 'screen savers' save nothing except the boredom of a constant picture. I would turn it off and also check screen properites/screensaver/power button and the bios to see if anything is scheduled to happen at 2 hours. The timing, if consistent, is definitely suspicious. A major change for Windows between 2.3.4 and 2.4 is the compiler 'upgrade' which could change a program's interaction with Windows and its vulnerability to bugs within. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-04 03:11 Message: Logged In: YES user_id=358087 1. "Pure" Python (without IDLE) don't hang after 2 hours 2. I didn't try this time but I'm pretty sure it hanged without screen saver as well. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2004-08-03 20:57 Message: Logged In: YES user_id=149084 1. What happens if you run Python without running IDLE? 2. Have you tried turning off the screensaver? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2004-08-02 04:05 Message: Logged In: YES user_id=358087 I'm using winXP pro. I don't recall anything funny with power management. This is IBMT40 (laptop) but it is in the docking station all the time. Only screen saver (slideshow) is running when computer is idle for long time, not sleep/hibernate ... I don't have time to check not but IIRC "idle -n" also hangs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-02 03:45 Message: Logged In: YES user_id=80475 Miki, what operatiing system are you using? Also, have you checked to see if something odd is going on with power management or a screen saver? One other thought is that it make have to do with the socket server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1001869&group_id=5470 From noreply at sourceforge.net Mon Aug 30 03:36:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 03:36:06 2004 Subject: [ python-Bugs-1018815 ] re.sub: two-digit group-reference hangs Message-ID: Bugs item #1018815, was opened at 2004-08-29 18:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Dyck (jmdyck) Assigned to: Fredrik Lundh (effbot) Summary: re.sub: two-digit group-reference hangs Initial Comment: Python 2.3.3 (#2, Feb 17 2004, 11:45:40) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 I think this affects 2.4 as well. If you invoke re.sub(), and the replacement contains a two-digit group-reference, it hangs. E.g. try print re.sub( r'(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)', r'\10', 'abcdefghijklm' ) Problem is infinite loop in sre_parse.py. I've attached a change that I think fixes it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 From noreply at sourceforge.net Mon Aug 30 03:45:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 03:45:12 2004 Subject: [ python-Bugs-1018815 ] re.sub: two-digit group-reference hangs Message-ID: Bugs item #1018815, was opened at 2004-08-29 18:36 Message generated for change (Comment added) made by jmdyck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Dyck (jmdyck) Assigned to: Fredrik Lundh (effbot) Summary: re.sub: two-digit group-reference hangs Initial Comment: Python 2.3.3 (#2, Feb 17 2004, 11:45:40) [GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 I think this affects 2.4 as well. If you invoke re.sub(), and the replacement contains a two-digit group-reference, it hangs. E.g. try print re.sub( r'(.)(.)(.)(.)(.)(.)(.)(.)(.)(.)', r'\10', 'abcdefghijklm' ) Problem is infinite loop in sre_parse.py. I've attached a change that I think fixes it. ---------------------------------------------------------------------- >Comment By: Michael Dyck (jmdyck) Date: 2004-08-29 18:45 Message: Logged In: YES user_id=663727 It sounds like this bug was fixed by patch 1018386 just yesterday! (Please check.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1018815&group_id=5470 From noreply at sourceforge.net Mon Aug 30 12:23:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 12:24:02 2004 Subject: [ python-Bugs-940578 ] glob.glob inconsistent about broken symlinks Message-ID: Bugs item #940578, was opened at 2004-04-23 11:07 Message generated for change (Settings changed) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Cherniavsky Beni (cben) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: glob.glob inconsistent about broken symlinks Initial Comment: `glob.glob()` uses `os.listdir()`, which includes borken symlinks in the listing if the pattern contains shell metacharacters but uses `os.path.exists()` which is False for broken symlinks if the pattern is a fixed name. Thus: >>> os.symlink('broken', 'sym1') >>> os.symlink('broken', 'sym2') >>> import glob >>> glob.glob('sym*') ['sym1', 'sym2'] >>> glob.glob('sym1') [] >>> glob.glob('sym2') [] ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 12:23 Message: Logged In: YES user_id=469548 Fixed by applying patch #941486. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-20 20:42 Message: Logged In: YES user_id=80475 Sorry, my question was meant for Johannes who recently committed something symlink related. If his patch did not fix your issue, he is still the one who will need to review and apply the patch (I'm on Windows and don't have symlinks). ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-20 17:39 Message: Logged In: YES user_id=469548 I think that question was directed at me (Raymond assigned the bug to me). Well, I didn't... yet. I've added a comment to #941486. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-08-20 13:35 Message: Logged In: YES user_id=36166 What do you mean? Patch 941486 is there a long time already. Commit it (choose between the minimal fix and the more proper introduction of `os.path.lexists()`) and it'll be fixed. Then you could add patch 943206 if you like ;-). And I've refreshed both to apply cleanly against current trunk. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-19 19:45 Message: Logged In: YES user_id=80475 Did you already fix this one? ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2004-04-24 22:32 Message: Logged In: YES user_id=36166 This bug exists in all versions of the module since its creation up to 2.4. The correct behaviour (judging by the shell's behaviour - that's the model for the module, isn't it), is to always include broken symlinks in the results. Several fixes for this bug are provided by patch 941486 (http://python.org/sf/941486). [They all include the testcase attached here.] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=940578&group_id=5470 From noreply at sourceforge.net Mon Aug 30 13:12:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 13:12:40 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 13:19 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 07:12 Message: Logged In: YES user_id=11375 The attached patch restores the behaviour that fds are only checked if they're readable or writable. However, even with the patch the ZODB/ZEO tests still fail for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Mon Aug 30 14:52:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 14:52:33 2004 Subject: [ python-Bugs-1019048 ] __metaclass__ in locals is ignored Message-ID: Bugs item #1019048, was opened at 2004-08-30 07:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: __metaclass__ in locals is ignored Initial Comment: The local namespace is not checked for a __metaclass__ when constructing a new class. This may be consistent with a strict reading of the language standard [http://docs.python.org/ref/metaclasses.html#l2h-216] but it's surprising. I think that the lookup for __metaclass__ should proceed in the same way as any other name lookup (after it is not found in the namespace of the class-to-be), which would include a lookup in the local namespace. The attached file should print "metaclass called with ..." and "C constructed as None..." but it doesn't in the "local case" If this behavior is not a bug, would a doc patch emphasizing the non-lookup in locals be accepted? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019048&group_id=5470 From noreply at sourceforge.net Mon Aug 30 15:32:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 15:32:38 2004 Subject: [ python-Bugs-976878 ] PDB: unreliable breakpoints on functions Message-ID: Bugs item #976878, was opened at 2004-06-21 18:56 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=976878&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dieter Maurer (dmaurer) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: PDB: unreliable breakpoints on functions Initial Comment: Breakpoints set on functions are unreliable because "pdb.Pdb.checkline" thinks lines inside a multi-column docstring were adequate lines for breakpoints. Of course, such breakpoints are ignored during execution. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 15:32 Message: Logged In: YES user_id=469548 Fixed by checking in patch 1003640. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-05 01:24 Message: Logged In: YES user_id=971153 Patch 1003640 should fix this problem ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-07-16 00:59 Message: Logged In: YES user_id=971153 I'd like to add that this bug is probably related (but not identical) to: bug#926369 & bug#875404 which are also caused by pdb.checkline() it might be a good idea to fix all three bugs at once... ---------------------------------------------------------------------- Comment By: Dieter Maurer (dmaurer) Date: 2004-06-21 18:58 Message: Logged In: YES user_id=265829 Patch attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=976878&group_id=5470 From noreply at sourceforge.net Mon Aug 30 15:32:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 15:32:51 2004 Subject: [ python-Bugs-875404 ] global stmt causes breakpoints to be ignored Message-ID: Bugs item #875404, was opened at 2004-01-12 15:52 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875404&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Maciej Kalisiak (mackal) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: global stmt causes breakpoints to be ignored Initial Comment: It seems that having a "global" statement in "main()" (perhaps elsewhere too) causes pdb to ignore breakpoints in the whole application. See the attached example small program. Procedure: - pdb python_bug.py # the attached program - 's', and then 'n' once or twice to make sure prog loaded - 'break main' - 'c' If the "global foo" statement is present, pdb will not stop at the breakpoint. If it is commented out (and "foo = 1" as well, of course), the breakpoint is obeyed. I'm using Python 2.3 (from the Debian "sid" distribution) Tried under Linux 2.2.20, as well as 2.4.*. Maciej Kalisiak mac at dgp dot toronto dot edu ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 15:32 Message: Logged In: YES user_id=469548 Fixed by checking in patch 1003640. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-05 01:26 Message: Logged In: YES user_id=971153 Patch 1003640 should fix this problem ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-03-10 23:22 Message: Logged In: YES user_id=971153 The same behaviour exists in the CVS version of python Here is what (I think) happens: 1. When you try to set a break on a function: e.g "b main" pdb sets a breakpoint not at "def main", but at the next non comment/non-blank line of code 2. Sample code has "global " as a first non-comment/non-blank line of code, so that's where pdb sets the breakpoint 3. But global is a compile-time statement, the line with global is never reached at run time, so pdb never stops there Workaround for the original submitter: put any other executable stmt as the first line of your main(), or set a bkpt via line number However, this behaviour is still wrong...The bug could be probably fixed by adding more logic to pdb.checkline().... Are there any other compile-time only statements? I think I could submit a patch for this problem, but does anyone look at pdb related patches?? My previous pdb patch #896011 has been sitting in the queue for a month now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875404&group_id=5470 From noreply at sourceforge.net Mon Aug 30 15:38:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 15:38:07 2004 Subject: [ python-Bugs-926369 ] pdb sometimes sets breakpoints in the wrong location Message-ID: Bugs item #926369, was opened at 2004-03-31 02:22 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926369&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ilya Sandler (isandler) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: pdb sometimes sets breakpoints in the wrong location Initial Comment: If one attempts to set a breakpoint in one line function: e.g for this code: def f(x): return x*x z=23 pdb silently sets a breakpoint on the line right after the function definition (i.e. outside the function body!): ../python pdb.py.v1.66 pdb_one_line_func > (1)?() (Pdb) b f Breakpoint 1 /src/Lib/pdb_one_line_func:3 (Pdb) c > /src/Lib/pdb_one_line_func(3)?() -> z=23 It's probably acceptable to limit pdb breakpoints to multiline functions, but i don't think, it's acceptable to create wrong breakpoints. Note: that anyone attempting to fix this should also take a look at bug 875404 (global statment causes breakpoints..), as both bugs are caused by pdb.checkline() logic ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 15:38 Message: Logged In: YES user_id=469548 Fixed by checking in patch 1003640. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-05 01:25 Message: Logged In: YES user_id=971153 Patch 1003640 should fix this problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926369&group_id=5470 From noreply at sourceforge.net Mon Aug 30 16:15:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 16:15:38 2004 Subject: [ python-Bugs-925628 ] help does not help with imported objects Message-ID: Bugs item #925628, was opened at 2004-03-29 23:34 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925628&group_id=5470 >Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Johannes Gijsbers (jlgijsbers) Summary: help does not help with imported objects Initial Comment: help(re) just says it is a wrapper for sre. To get actually help, you need to explicitly import sre as well. re.__doc__ = re.__doc__ + sre.__doc__ helps, but still does not list information on classes or exported functions. Specific requests, such as help(re.subn) do work; it is only the module-level help that is lacking when a module reexports imported objects. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 16:15 Message: Logged In: YES user_id=469548 Fixed by applying patch #934356. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-04-13 20:15 Message: Logged In: YES user_id=764593 Patch 934356 changes help(module) to document objects in __all__, if __all__ is defined. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-04-09 02:39 Message: Logged In: YES user_id=593130 My non-expert suggestions: 1. For this item, suggest a short addition to re.__doc__, something like I suggested before, and reclassify this to category documentation. Doc gurus should then get an email. Or just close. 2. For pydoc, maybe submit a separate patch or RFE (requiest for enhancement). Or, if currently behavior is arguably at odds with either lib ref or its doc string, a bug. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-04-08 19:58 Message: Logged In: YES user_id=764593 I've dug a bit deeper. The problem seems to be that when pydoc is documenting a module, it explicitly ignores classes and functions that are defined outside that module. (For data, it does not.) If the module itself reexports these classes, they should be included in help. Example from class TextDoc.docmodule: classes = [] for key, value in inspect.getmembers(object, inspect. isclass): if (inspect.getmodule(value) or object) is object: if visiblename(key): classes.append((key, value)) funcs = [] for key, value in inspect.getmembers(object, inspect. isroutine): if inspect.isbuiltin(value) or inspect.getmodule(value) is object: if visiblename(key): funcs.append((key, value)) ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-03-30 19:50 Message: Logged In: YES user_id=593130 I am not sure a see a bug here (as opposed to enhancement request). re.__all__ and dir(re) list exported names. help (re.engine) gets the multipage doc from the wrapped engine without importing it. The re doc string could be enhanced by adding a FOR MORE section that says so. Automatically adding sre would have been wrong when there were multiple engines in the distribution. Not sure if are or will be in 2.4, but there could be in the future again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925628&group_id=5470 From noreply at sourceforge.net Mon Aug 30 16:28:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 16:28:17 2004 Subject: [ python-Bugs-1014770 ] Misc/NEWS no valid reStructuredText Message-ID: Bugs item #1014770, was opened at 2004-08-24 00:26 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014770&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: Misc/NEWS no valid reStructuredText Initial Comment: Misc/NEWS (in both Python 2.4a1 and 2.4a2) is not valid reStructuredText, but NEWS.help says it should be. Processing it with Docutils gives several errors. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 16:28 Message: Logged In: YES user_id=469548 Fixed in rev 1.1124 of Misc/NEWS. There's one warning left, but that one's clearer in plain text without escaping. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014770&group_id=5470 From noreply at sourceforge.net Mon Aug 30 16:34:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 16:34:46 2004 Subject: [ python-Bugs-1014775 ] Misc/NEWS.help Message-ID: Bugs item #1014775, was opened at 2004-08-24 00:35 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014775&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: Misc/NEWS.help Initial Comment: Misc/NEWS.help needs to be updated because of changes in Docutils. Attached an updated version. ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 16:34 Message: Logged In: YES user_id=469548 Checked in as rev 1.5 of NEWS.help, thanks! Please provide a patch instead of the full file the next time though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014775&group_id=5470 From noreply at sourceforge.net Mon Aug 30 16:47:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 16:48:00 2004 Subject: [ python-Bugs-1015249 ] cgi.FieldStorage.__len__ eventually throws TypeError Message-ID: Bugs item #1015249, was opened at 2004-08-24 15:32 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015249&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Ames (yxcv) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage.__len__ eventually throws TypeError Initial Comment: This makes it hazardous to do the following: fs = cgi.FieldStorage(...) if fs: ... Suggestions: 1) Fix __len__; sorry, but I don't know how. 2) Create FieldStorage.__nonzero__; a hack. 3) ? ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 16:47 Message: Logged In: YES user_id=469548 As far as I can tell, cgi.FieldStorage.__len__ only raises a TypeError if the FieldStorage is not indexable. It's reasonable not to support len() on an unindexable FieldStorage. I'm just wondering why you would want to do: fs = cgi.FieldStorage(...) if fs: ... Defining __nonzero__ seems reasonable if there's a reason for testing a FieldStorage for truth value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015249&group_id=5470 From noreply at sourceforge.net Mon Aug 30 17:01:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 17:01:12 2004 Subject: [ python-Bugs-1019129 ] "rich comparison'' methods hide stack overflow Message-ID: Bugs item #1019129, was opened at 2004-08-30 17:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019129&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: boyanb (boyanb) Assigned to: Nobody/Anonymous (nobody) Summary: "rich comparison'' methods hide stack overflow Initial Comment: I've tried the code below for both 2.2.2 and 2.3.2 >>> class DontCare(str): ... def __eq__(self, other): ... # stack overflow expected! ... return self == other ... ... >>> print (DontCare("1") == "2") 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019129&group_id=5470 From noreply at sourceforge.net Mon Aug 30 17:07:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 17:09:12 2004 Subject: [ python-Bugs-1000841 ] "make pdf" failure w/ 2.4 docs Message-ID: Bugs item #1000841, was opened at 2004-07-30 20:01 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mat Martineau (martineau) Assigned to: Nobody/Anonymous (nobody) Summary: "make pdf" failure w/ 2.4 docs Initial Comment: When attempting to build the pdf version of the documentation from CVS, I get the following error: (/.../python/dist/src/Doc/lib/libxmlrpclib.tex ... ! TeX capacity exceeded, sorry [input stack size=1500]. \font@name -> \OT1/phv/m/n/10 l.259 ...//www.xmlrpc.com/discuss/msgReader\208} , an approach ! ==> Fatal error occurred, the output PDF file is not finished! The '$' in line 259 of libxmlrpclib.tex seems to trip up pdflatex. If '%24' is substituted for '$', the link still works, and lib.pdf will build. Info about my version of pdflatex & linux: $ pdflatex --version pdfTeX (Web2C 7.4.5) 3.14159-1.10b kpathsea version 3.4.5 ... $ cat /proc/version Linux version 2.6.5-7.95-default (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 Thu Jul 1 15:23:45 UTC 2004 ---------------------------------------------------------------------- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-30 17:07 Message: Logged In: YES user_id=469548 The patch jepler pointed to has been checked in, and make pdf is working for me, so: closing. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-08-09 13:55 Message: Logged In: YES user_id=2772 mwh: for a fix for the "dist" problem, see python.org/sf/1005913 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 19:41 Message: Logged In: YES user_id=6656 Confirmed, and fixed in the suggested way in Doc/lib/ libxmlrpclib.tex revision 1.17. "make pdf" still chokes, but on dist now. Haven't had a look to see why. aisaac0: you should *really* file another bug for that. ---------------------------------------------------------------------- Comment By: Alan (aisaac0) Date: 2004-07-31 17:02 Message: Logged In: YES user_id=1025672 Hopefully a bug from the 2.3 docs can be fixed at the same time. The PDF production tries to set the vertical bar '|' in textmode rather than math mode. An example of this problem is the documentation for set union, which looks like s--t instead of s|t. Should I submit this as a separate bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000841&group_id=5470 From noreply at sourceforge.net Mon Aug 30 18:18:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 18:18:38 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 22:30 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-31 02:18 Message: Logged In: YES user_id=29957 I can live with David's last solution (moving the type check to CP.set). RCP isn't in __all__, and isn't documented, so I don't think it matters so much if it has internally inconsistent results - we can also put a type check in the output code to make sure it gets picked up there... ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-25 13:34 Message: Logged In: YES user_id=7733 [rhettinger] > Perhaps, the set() method should coerce to a string rather > than test for it. Perhaps. But regardless of whether it's a test or coercion, if it's in RawConfigParser.set, it prevents non-string use. Perhaps ConfigParser.set should extend RawConfigParser.set with the string test or coercion, leaving RawConfigParser.set as it was before rev 1.65. That may be the best solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-25 02:10 Message: Logged In: YES user_id=80475 Perhaps, the set() method should coerce to a string rather than test for it. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-25 01:14 Message: Logged In: YES user_id=7733 I strongly feel that the 2.3 behavior should be restored, and documented, before 2.4b1. I will do the doc change. I have updated the bug report with links and discussions. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-25 01:10 Message: Logged In: YES user_id=7733 Also see the python-dev thread at . The third message in the thread was garbled due to a GPG problem; reproduced below. [Fred L. Drake, Jr.] > David has (properly) been asking me to look into this, and i've > managed not to have enough time. Sorry, David! I thought a python-dev nudge might get you off your keister ;-) > The ConfigParser documentation was certainly too vague, but the > problem, as I see it, is that the module was never intended to store > non-string values. BUT ConfigParser *did* allow non-strings to be stored, for internal use only (can't write them out, of course). And changing it *did* break code. I think a doc change acknowledging that ability but qualifying it ("for internal use only, can't be used to write out config files or interpolate values") would have been a better fix. The change in rev. 1.65 makes ConfigParser.py *less* useful. When I used ConfigParser in Docutils, I wasn't being especially clever when I used it to set non-string values. It will take a lot more cleverness post-rev-1.65 to enable that functionality. Of course, the fix to Docutils is pretty simple: just override ConfigParser.set with the older version. But that depends on private implementation details (self._defaults, self._sections). This is *much* more dangerous and impossible to future-proof against. > I think allowing them is just asking for still more trouble from > that module down the road. Has there been any trouble until now? Why "fix" something that wasn't really broke? The original bug report (http://www.python.org/sf/810843) was really only asking for clarification. It ends with: Nonetheless, I was shocked to see what I thought was a straightforward use of ConfigParser throw off errors. Imagine developers' shock now that we can't do what we want at all! Docutils is not the only project using ConfigParser to store non-strings. I wouldn't be surprised to see other code breaking, which we probably wouldn't find out about until after 2.4-final. > Sure, the module could be made happy by reverting the patch you > cite, but happy-by-accident is a very fragile state to be in. So let's remove the accident, and make the happiness official! >> The comment for bug 810843 says "This is documented behavior", but >> I couldn't find any such documentation pre-dating this change. > > This may have been a bug in my memory. Now that the memory bug is fixed, how about reconsidering the resultant decision? I'll write a doc patch ASAP. -- David Goodger ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-25 01:04 Message: Logged In: YES user_id=7733 The alternative is the following change in Docutils. Unfortunately, it requires access to internal implementation details marked with single leading underscores. diff -u -r1.64 frontend.py --- docutils/frontend.py 24 Jul 2004 14:13:38 -0000 1.64 +++ docutils/frontend.py 24 Aug 2004 15:01:32 -0000 @@ -637,6 +637,22 @@ section_dict[option] = self.get(section, option, raw=1) return section_dict + def set(self, section, option, value): + """ + Set an option. + + Overrides stdlib ConfigParser's set() method to allow non-string + values. Required for compatibility with Python 2.4. + """ + if not section or section == CP.DEFAULTSECT: + sectdict = self._defaults + else: + try: + sectdict = self._sections[section] + except KeyError: + raise CP.NoSectionError(section) + sectdict[self.optionxform(option)] = value + class ConfigDeprecationWarning(DeprecationWarning): """Warning for deprecated configuration file features.""" ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-25 01:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Mon Aug 30 18:36:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 18:36:10 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 13:19 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:36 Message: Logged In: YES user_id=31435 No patched is attached (you have to check the box, etc). I was running Zope3 tests, and testManyClients specifically is what fails now (plus some irrelvant failures caused by the testManyClients failure). testManyClients isn't a ZODB/ZEO test, BTW. I didn't see any failures in ZODB/ZEO tests due to the asyncore change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 07:12 Message: Logged In: YES user_id=11375 The attached patch restores the behaviour that fds are only checked if they're readable or writable. However, even with the patch the ZODB/ZEO tests still fail for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Mon Aug 30 18:40:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 18:40:43 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 13:19 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 12:40 Message: Logged In: YES user_id=11375 Attaching patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:36 Message: Logged In: YES user_id=31435 No patched is attached (you have to check the box, etc). I was running Zope3 tests, and testManyClients specifically is what fails now (plus some irrelvant failures caused by the testManyClients failure). testManyClients isn't a ZODB/ZEO test, BTW. I didn't see any failures in ZODB/ZEO tests due to the asyncore change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 07:12 Message: Logged In: YES user_id=11375 The attached patch restores the behaviour that fds are only checked if they're readable or writable. However, even with the patch the ZODB/ZEO tests still fail for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Mon Aug 30 18:49:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 18:49:35 2004 Subject: [ python-Bugs-1011606 ] 2.4 asyncore breaks Zope Message-ID: Bugs item #1011606, was opened at 2004-08-18 13:19 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: A.M. Kuchling (akuchling) Summary: 2.4 asyncore breaks Zope Initial Comment: Bug 629097 describes a thread race involving asyncore.pool(), and was closed with "so don't do that". Polling exception sets is new in 2.4, though, and opens the same race to formerly safe uses: leaving indeterminate junk in the socket map, provided that junk doesn't call itself readable or writable. Such junk never got passed to select() before 2.4, but always gets passed to select() in 2.4. This is incompatible behavior, albeit in a grey area. More discussion starting at http://mail.python.org/pipermail/python-dev/2004- August/047817.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:49 Message: Logged In: YES user_id=31435 Logic similar to the logic in the patch worked for me when I tried it. Suggest it would be faster and clearer to just add e = r + w to the 2.3 asyncore poll(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 12:40 Message: Logged In: YES user_id=11375 Attaching patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-08-30 12:36 Message: Logged In: YES user_id=31435 No patched is attached (you have to check the box, etc). I was running Zope3 tests, and testManyClients specifically is what fails now (plus some irrelvant failures caused by the testManyClients failure). testManyClients isn't a ZODB/ZEO test, BTW. I didn't see any failures in ZODB/ZEO tests due to the asyncore change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-30 07:12 Message: Logged In: YES user_id=11375 The attached patch restores the behaviour that fds are only checked if they're readable or writable. However, even with the patch the ZODB/ZEO tests still fail for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1011606&group_id=5470 From noreply at sourceforge.net Mon Aug 30 19:26:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 19:26:14 2004 Subject: [ python-Bugs-997050 ] ConfigParser behavior change Message-ID: Bugs item #997050, was opened at 2004-07-24 08:30 Message generated for change (Comment added) made by goodger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: David Goodger (goodger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser behavior change Initial Comment: ConfigParser.set() doesn't allow non-string arguments for 'value' any more. This breaks Docutils code. I submit that the behavior should not have been changed, rather that the documentation needed updating. I volunteer to undo the change and update the documentation. ConfigParser.py rev. 1.65 implements the fix detailed in bug report 810843 (http://python.org/sf/810843): Fixed using methods (2) and (3): ConfigParser.set() now checks that the value is some flavor of string, and raises TypeError if it isn't. This is documented behavior; regression tests have been added. "This is documented behavior": where was this behavior documented before the bug fix? I couldn't find it. If it wasn't documented, wouldn't method 4 (from the bug report, below) have been more appropriate? (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). IOW, perhaps it wasn't a code bug but rather an omission in the docs. By adding the restriction and raising TypeError, it breaks Docutils, which subclasses ConfigParser. If the string-only restriction *was* documented and I just missed it, I'll accept that the Docutils code was at fault (it's not the first time ;-) and rework it. But if that restriction wasn't documented, I don't think ConfigParser's behavior should change. See also . ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2004-08-30 13:26 Message: Logged In: YES user_id=7733 [anthonybaxter] > RCP isn't in __all__, Perhaps it should be, because: > and isn't documented, Actually, it is documented: http://www.python.org/dev/doc/devel/lib/RawConfigParser-objects.html > we can also put a type check in the > output code to make sure it gets picked up there... It gets more and more complicated, doesn't it? I still think that the code itself wasn't broken so there was no need to fix it. The simplest solution would be to revert the rev 1.65 code changes, and just add some documentation. Something along the lines of: "Output only works with string values. If used for non-string values, you're on your own." We shouldn't be *removing* functionality without a darned good reason. I don't see such a reason here. And since this change broke preexisting code that relied on that functionality, it seems obvious that it should be reverted. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-08-30 12:18 Message: Logged In: YES user_id=29957 I can live with David's last solution (moving the type check to CP.set). RCP isn't in __all__, and isn't documented, so I don't think it matters so much if it has internally inconsistent results - we can also put a type check in the output code to make sure it gets picked up there... ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 23:34 Message: Logged In: YES user_id=7733 [rhettinger] > Perhaps, the set() method should coerce to a string rather > than test for it. Perhaps. But regardless of whether it's a test or coercion, if it's in RawConfigParser.set, it prevents non-string use. Perhaps ConfigParser.set should extend RawConfigParser.set with the string test or coercion, leaving RawConfigParser.set as it was before rev 1.65. That may be the best solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-24 12:10 Message: Logged In: YES user_id=80475 Perhaps, the set() method should coerce to a string rather than test for it. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:14 Message: Logged In: YES user_id=7733 I strongly feel that the 2.3 behavior should be restored, and documented, before 2.4b1. I will do the doc change. I have updated the bug report with links and discussions. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:10 Message: Logged In: YES user_id=7733 Also see the python-dev thread at . The third message in the thread was garbled due to a GPG problem; reproduced below. [Fred L. Drake, Jr.] > David has (properly) been asking me to look into this, and i've > managed not to have enough time. Sorry, David! I thought a python-dev nudge might get you off your keister ;-) > The ConfigParser documentation was certainly too vague, but the > problem, as I see it, is that the module was never intended to store > non-string values. BUT ConfigParser *did* allow non-strings to be stored, for internal use only (can't write them out, of course). And changing it *did* break code. I think a doc change acknowledging that ability but qualifying it ("for internal use only, can't be used to write out config files or interpolate values") would have been a better fix. The change in rev. 1.65 makes ConfigParser.py *less* useful. When I used ConfigParser in Docutils, I wasn't being especially clever when I used it to set non-string values. It will take a lot more cleverness post-rev-1.65 to enable that functionality. Of course, the fix to Docutils is pretty simple: just override ConfigParser.set with the older version. But that depends on private implementation details (self._defaults, self._sections). This is *much* more dangerous and impossible to future-proof against. > I think allowing them is just asking for still more trouble from > that module down the road. Has there been any trouble until now? Why "fix" something that wasn't really broke? The original bug report (http://www.python.org/sf/810843) was really only asking for clarification. It ends with: Nonetheless, I was shocked to see what I thought was a straightforward use of ConfigParser throw off errors. Imagine developers' shock now that we can't do what we want at all! Docutils is not the only project using ConfigParser to store non-strings. I wouldn't be surprised to see other code breaking, which we probably wouldn't find out about until after 2.4-final. > Sure, the module could be made happy by reverting the patch you > cite, but happy-by-accident is a very fragile state to be in. So let's remove the accident, and make the happiness official! >> The comment for bug 810843 says "This is documented behavior", but >> I couldn't find any such documentation pre-dating this change. > > This may have been a bug in my memory. Now that the memory bug is fixed, how about reconsidering the resultant decision? I'll write a doc patch ASAP. -- David Goodger ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:04 Message: Logged In: YES user_id=7733 The alternative is the following change in Docutils. Unfortunately, it requires access to internal implementation details marked with single leading underscores. diff -u -r1.64 frontend.py --- docutils/frontend.py 24 Jul 2004 14:13:38 -0000 1.64 +++ docutils/frontend.py 24 Aug 2004 15:01:32 -0000 @@ -637,6 +637,22 @@ section_dict[option] = self.get(section, option, raw=1) return section_dict + def set(self, section, option, value): + """ + Set an option. + + Overrides stdlib ConfigParser's set() method to allow non-string + values. Required for compatibility with Python 2.4. + """ + if not section or section == CP.DEFAULTSECT: + sectdict = self._defaults + else: + try: + sectdict = self._sections[section] + except KeyError: + raise CP.NoSectionError(section) + sectdict[self.optionxform(option)] = value + class ConfigDeprecationWarning(DeprecationWarning): """Warning for deprecated configuration file features.""" ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2004-08-24 11:00 Message: Logged In: YES user_id=7733 The change that I'm proposing to revert: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ConfigParser.py?r1=1.64&r2=1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=997050&group_id=5470 From noreply at sourceforge.net Mon Aug 30 22:13:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 30 22:13:32 2004 Subject: [ python-Bugs-1015140 ] "article id" in description of NNTP objects Message-ID: Bugs item #1015140, was opened at 2004-08-24 12:26 Message generated for change (Comment added) made by felixwiemann You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Wiemann (felixwiemann) Assigned to: Nobody/Anonymous (nobody) Summary: "article id" in description of NNTP objects Initial Comment: lib/nntp-objects.html uses the term "article id" several times. This term is ambiguous though. Either "article number" or "message id" should be used. ---------------------------------------------------------------------- >Comment By: Felix Wiemann (felixwiemann) Date: 2004-08-30 22:13 Message: Logged In: YES user_id=1014490 > Patches are welcome. I don't have enough time (and I don't care enough) to write a patch for this, currently. > If you have a link to authoritive > guidance, that would be nice also. The only occurence of the case-insensitive regex 'article.id' in all RFCs is in RFC 977, which says: 223 n a article retrieved - request text separately (n = article number, a = unique article id) (Here, it probably means message-id.) There are frequent occurences of 'article number' and 'message-id' in the NNTP related RFCs 977 and 2980. So 'article id' probably should be avoided, as it is ambiguous. (The docs sometimes use it in the sense of 'message-id' and sometimes as 'article number', from what I could see.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-08-29 10:20 Message: Logged In: YES user_id=80475 Patches are welcome. If you have a link to authoritive guidance, that would be nice also. ---------------------------------------------------------------------- Comment By: Felix Wiemann (felixwiemann) Date: 2004-08-29 10:11 Message: Logged In: YES user_id=1014490 Same problem for the docstrings in the source file Lib/nntplib.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1015140&group_id=5470 From noreply at sourceforge.net Tue Aug 31 18:18:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 31 18:18:05 2004 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 13:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Tue Aug 31 18:22:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 31 18:22:17 2004 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 13:18 Message generated for change (Comment added) made by fgsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 13:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Tue Aug 31 16:37:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 31 19:02:22 2004 Subject: [ python-Bugs-1019715 ] distutils ignores configure's --includedir Message-ID: Bugs item #1019715, was opened at 2004-08-31 09:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019715&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joseph Winston (josephwinston) Assigned to: Nobody/Anonymous (nobody) Summary: distutils ignores configure's --includedir Initial Comment: 1. configure and build python using the --includedir option. For example: $ configure --prefix=/TANGO/3/rel --includedir=/TANGO/3/rel/inc 2. Run $ make install 3. Notice that the include files are placed in /TANGO/3/rel/include not /TANGO/3/rel/inc. 4. Verify with $ python -c 'from distutils.sysconfig import *;print get_python_inc() 5. The problem is that get_python_inc() hard codes the include file path to use the name "include" 6. Other programs using distutils will fail since the INSTALL_SCHEMES found in install.py also have the name "include" hard coded. 7. Suggested fix would be to use --includedir to calculate the include path used by distutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019715&group_id=5470 From noreply at sourceforge.net Tue Aug 31 20:06:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 31 20:06:44 2004 Subject: [ python-Bugs-1019882 ] hotshot start / stop stats bug Message-ID: Bugs item #1019882, was opened at 2004-08-31 14:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019882&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: hotshot start / stop stats bug Initial Comment: Hotshot has a bug that manifests when using start/stop instead of run(), however it appears to only occur in the interactive interpreter or in an embedded application. If you run the attached program like "python hotshotbug.py" it works just fine. However, if you start an interactive session and paste each line one by one into the shell, you get the following exception: Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/hotshot/stats.py", line 12, in load return StatsLoader(filename).load() File "/usr/local/lib/python2.3/hotshot/stats.py", line 29, in load for event in log: File "/usr/local/lib/python2.3/hotshot/log.py", line 110, in next return what, self._pop(), tdelta IndexError: pop from empty list We discovered this when trying to profile an embedded application which doesn't have a single entrypoint suitable for run(). Unfortunately, I can't provide that application, but it shouldn't matter, since the interpreter crash is the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019882&group_id=5470 From noreply at sourceforge.net Tue Aug 31 22:01:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 31 22:01:03 2004 Subject: [ python-Bugs-1019956 ] httplib.HTTPConnection sends extra blank line Message-ID: Bugs item #1019956, was opened at 2004-08-31 15:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Antonio Rodriguez (antrod) Assigned to: Nobody/Anonymous (nobody) Summary: httplib.HTTPConnection sends extra blank line Initial Comment: It seems that line 594 of httplib.py: self._buffer.extend(("", "")) Causes the insertion of an extra \r\n so that at the end of the headers an extra blank line is submitted. This can create problems when PUTting files because the extra line gets treated as part of the payload and can thus cause the truncation of the end of the file on servers that are listening to the Content-Length header. I think that: self._buffer.extend(("", )) fixes the issue but I am not quite sure whether this is there for some other reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019956&group_id=5470 From noreply at sourceforge.net Tue Aug 31 23:41:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 31 23:41:16 2004 Subject: [ python-Bugs-417833 ] pydoc HTTP reload failure Message-ID: Bugs item #417833, was opened at 2001-04-21 07:10 Message generated for change (Comment added) made by eparker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Ka-Ping Yee (ping) Summary: pydoc HTTP reload failure Initial Comment: pydoc, when run as a web server, can't cope with reloads of modules which use 'from Package import Module' syntax for imports. To reproduce: * extract the attached DemonstratePydocBug tarchive into your Python 2.1 directory * python -c Lib\pydoc.py -p 8192 * visit http://localhost:8192/DemonstratePydocBug.html The rest of the instructions are there. Demonstrated on Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32. Funnily enough, there's no problem with trying the following under Python interactively: Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails I'm dropping additional debugging code into pydoc.py to see if I can figure out what's going on. ---------------------------------------------------------------------- Comment By: Eddie Parker (eparker) Date: 2004-08-31 14:41 Message: Logged In: YES user_id=991512 This is still current, as of 08/31/2004. Rather annoying, too. :( ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:43 Message: Logged In: YES user_id=357491 Just as an update, this still seeems to be an issue in Python 2.3b1 w/ version 1.82 of pydoc ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 09:15 Message: Logged In: YES user_id=59803 Using pydoc in the interpreter doesn't tickle any of these bugs, so hopefully I can narrow my focus down to the difference in handling between serve() and help(). Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> pydoc.help Welcome to Python 2.1! This is the online help utility. [...] help> modules Please wait a moment while I gather a list of all available modules... [list of modules] Enter any module name to get more help. Or, type "modules spam" to search for modules whose descriptions contain the word "spam". help> DemonstratePydocBug.ReloadFails Help on module DemonstratePydocBug.ReloadFails in DemonstratePydocBug: NAME DemonstratePydocBug.ReloadFails FILE c:\python21\lib\demonstratepydocbug\reloadfails.py [...] help> DemonstratePydocBug.TryThis Help on module DemonstratePydocBug.TryThis in DemonstratePydocBug: NAME DemonstratePydocBug.TryThis [...] ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 08:09 Message: Logged In: YES user_id=59803 Yet another demonstration case: DemonstratePydocBug/TryThis.py: import DemonstratePydocBug.Target Target = DemonstratePydocBug.Target This gives us a local Target variable, same as 'from DemonstratePydocBug import Target'. Pydoc barfs on this on the very first load. The traceback I hacked into pydoc claims: Traceback (most recent call last): File "C:\Python21\Lib\pydoc.py", line 223, in safeimport module = __import__(path) File "c:\python21\lib\DemonstratePydocBug\TryThis.py", line 9, in ? Target = DemonstratePydocBug.Target AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' In the interpreter, everything's fine with both techniques for getting Target: C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.Target >>> Target = DemonstratePydocBug.Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:58 Message: Logged In: YES user_id=59803 WHOA. Belay that. I screwed up trying to run too many tests in a row without shutting down the interpreter. Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> DemonstratePydocBug.Target Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' >>> import DemonstratePydocBug.Target >>> DemonstratePydocBug.Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target FILE c:\python21\lib\demonstratepydocbug\target.py DESCRIPTION Target: module to help demonstrate the pydoc reload bug. See the docstring in __init__.py for full details. Reloading the description of this module in pydoc should work, but that's hardly unusual because it doesn't import *anything*. Try ReloadWorks and ReloadFails, instead. DATA __file__ = r'c:\python21 \lib\DemonstratePydocBug\Target.pyc' __name__ = 'DemonstratePydocBug.Target' >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target ... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:55 Message: Logged In: YES user_id=59803 >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) ... we get good stuff... >>> print DemonstratePydocBug.ReloadFails2 <module 'DemonstratePydocBug.ReloadFails2' from 'DemonstratePydocBug\ReloadFails2.py'> >>> pydoc.help(DemonstratePydocBug.ReloadFails2) ... we get good stuff... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:43 Message: Logged In: YES user_id=59803 I've found another demonstration case. Noting that from package import module gives you a variable called 'module', whilst import package.module gives you a variable called 'package', I thought I'd try out another import syntax which wouldn't break code that was trying out the first option: import package.module as module This also works under the Python 2.1 interpreter but breaks pydoc 1.38. I've attached an updated demonstration tarchive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470